Amazon
用現代技術重新打造的關聯式資料庫會有什麼不一樣?Amazon亞太區技術首席傳教士Markku Lepisto近日來臺揭露,剛在7月上線的AWS新關聯式資料庫服務Aurora更多的架構細節。
為雲端服務而生的關聯式資料庫
他表示,Aurora採用了服務導向思維(Service-Oriented)來設計關聯式資料庫,改由雲端儲存服務來取代資料庫底層所需的儲存系統,包括SQL、Transaction、Caching與Logging層等都搬上雲端,來實現高可用性的目標。為了銜接現有使用者,Amazon讓Aurora能和MySQL相容。根據Amazon比較Aurora和自家雲端MySQL服務的結果,Markku Lepisto表示,Aurora新架構的效能是MySQL的5倍。
由於四十多年前資料庫問世時,叢集與雲端技術尚不成熟,因此採單一機器(Monolithic)的主從式架構設計,但是隨著需要服務的人數越來越多,傳統關聯式資料庫在雲端時代遇到了橫向擴充的問題。儲存的資料量也跟著暴增,效能與容量的極限都受到挑戰,光擴充單臺伺服器運算能力的縱向擴充方式,需要投入的成本已經不敷經濟效益,因此有了增加多臺伺服器橫向擴充的方法。
傳統關聯式資料庫橫向擴展障礙重重
其中一種關聯式資料庫常用的橫向擴充方式便是Sharding,將儲存的資料依照規則拆分到多個資料庫中,像是會員資料庫就能以會員身分證字號開頭字母當作切分Chunk的條件,從A開始,連續13個英文字母為1組,把整個會員資料庫一分為二,而這樣應用程式存取請求的流量也就能被分散到2臺機器上。
但是傳統關聯式資料庫的Sharding對於程式開發人員是個噩夢,不只是程式的設計邏輯會變得很複雜,而且當資料庫需要再次擴充時,根據不同的Sharding演算法,為了與新Shard重新分配資料,會有密集的資料讀取以及寫入,不過,這樣動作將會對資料庫效能造成沈重的負擔。
由於Sharding切分資料太過複雜,Markku Lepisto表示,許多人選擇另一種比較直覺的橫向擴充方式,便是鏡像複製資料庫,以同步所有資料庫內的資料,如此多臺機器就能共同分擔應用程式對資料庫存取的請求流量。雖然這樣的資料庫架構邏輯簡單,但仍會遇到諸多問題,主要發生在資料庫間的資料同步。
Markku Lepisto以Amazon RDS for MySQL為例說明,不同資料庫(Instance)間,同步所需要傳輸的資料非常多,包括Log紀錄、二進位Log、資料、二次寫入緩衝區以及FRM檔案(Metadata),再加上多臺資料庫間需要不斷的互相查詢資料的一致性,造成頻繁的網路I/O以及資料庫存取負擔,致使資料同步延遲時間過長,最終造成資料庫效能低落。
共用儲存層加速資料庫同步
Amazon設計了共用儲存層(Storage),解決資料庫鏡像複製帶來的效能負擔。所有橫向擴充的資料庫Instance可以存取同一個64TB的雲端空間。Instance間的溝通僅需要傳輸Metadata,儲存層間的多份複製,則是傳遞硬碟讀寫的修改Log紀錄,因此是容量較小的小片段資料,來減少網路傳輸的負擔。
Markku Lepisto說,Aurora會將要寫入的資料切成小塊(Chunk),再複製成6份分散儲存,比起一般雲端服務複製3份分散儲存的設計還要多1倍,來增加可用性與耐久性,也因此Aurora重度依賴雲端架構才能運作,因此未來也不會推出可獨立安裝的單機版本。
儲存層的小片段資料傳輸也帶來另一個好處,當資料庫的資料毀損需要復原時,花費的時間成本較短。因為Aurora資料檢查的層級是儲存層,每當讀取硬碟資料就會做一次資料檢查,密集的資料檢查能減少資料可能毀損的時間長度,當毀損的資料片段也較小,所需修復的時間也就較少。
而資料庫Instance共用儲存層除了橫向擴充較快外,也容易實現資料庫讀寫分離設計,Markku Lepisto表示,MySQL的Instance間因為無法避免同步資料的寫入,平均所有資料庫伺服器都需花費70%的運算成本在寫入動作,只有30%的讀取資源。而Aurora因為所有Instance共用儲存層,因此所有的寫入工作能夠集中到Master資料庫,其他的Instance能用100%的運算資源處理資料讀取。
熱門新聞
2024-10-14
2024-10-13
2024-10-13
2024-10-14
2024-10-14
2024-10-14