用現代技術重新打造的關聯式資料庫會有什麼不一樣？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％的運算資源處理資料讀取。