AWS發布云關系型數據庫Aurora 六問技術細節
亞馬遜發布了Aurora系統,并允諾其會有許多引人注目的特性。讓我們深入了解一下Aurora系統,并探索一下其分支結構。
結構:
Aurora的整體設計是這樣的，利用一個master節點提供寫服務，Slave節點展開在master節點周圍，用于讀,，這聽起來像MySQL-讀操作是可擴展的。亞馬遜還撰寫了很多關于Aurora存儲功能的說明,但是關于其結構細節的內容卻少的可憐。也許他們將使用了SSDs的AWS DynamoDB作為對數據引擎透明的后端存儲。因為擴展讀操作需要用到AWS基礎設施中的共享磁盤,所以Aurora只能工作在AWS上。
擴展：
通過允許15副本（Slave讀操作節點），Aurora在多種工作負載情況都具有良好的可擴展性。然而，對于寫操作的擴展細節是不明確的。最終系統性能會受到主節點寫操作性能的制約。這里還沒有提及內存中寫入的處理，因此寫入操作將限制于存儲基礎架構，其通常建議使用SSD，但橫跨多個Availability Groups，又回到那個延遲的問題。
可用性：
亞馬遜承諾同時提供多個“ 副本 ”（Slave讀操作節點）和“基于恢復時間點的增量備份。” 但是，沒有規定副本推送至寫操作Master節點的延遲; 所以，如果丟失了寫操作Master節點，將會產生一個（應用程序）的延遲，之后才能繼續寫操作。相應地，基于時間點的恢復也有顯著延時：“......重建數據庫到你保存的任意時刻直到***5分鐘前。“因此，如果您的實例掛掉，所有***五分鐘的事務都將丟失？Aurora試圖通過將故障轉移到其他副本，以緩解這種巨大的延時，即“Reserved Instance” “熱插拔”硬件已經在云技術中出現了!
復制：
延遲是一個有趣的問題。亞馬遜已經表示，他們的復制是異步的。這并不奇怪，因為如果不這么做，他們將在Master節點上看到巨大的寫入延遲。他們聲稱復制是毫秒級的-但是具體是如何處理的并不為人所知。如果DynamoDB對他們來說是一個共享的磁盤存儲，他們是如何處理Slave節點上緩存一致性的？這是另一個還未解決的有趣問題。
性能：
亞馬遜承諾“Aurora性能是同等硬件條件下MySQL V5.6速度的五倍。”這聽起來十分不錯，但我們真的能看到實際的數字么？在特定平臺運行測試的細節呢？大家都知道“可達到”是有一點回旋余地的。不幸的是，目前，Aurora是“有限預覽，”所以我們都必須等待。
事務延遲：
如果需要多個“規定數量”的寫操作和讀操作（Slave節點）保持同步，Slave節點完全同步的延遲是多少？例如，如果應用程序是從Slave節點副本讀取，然后Master節點被更新，這次事務是如何完成的？顧客添加一個電子商務網站上某個商品到購物車，一旦他們查詢其購物車（例如，在Slave讀操作節點上），他們可以選擇更改所購商品數量或顏色。如果此時有customer2剛剛購買了某一個顏色的全部商品，customer1會話中是否會反映出***的可用數量？或者應用程序有個機制來處理此類問題。這些是電子商務網站部署要解決的關鍵問題。
總體而言，亞馬遜的Aurora發布時給出了很多的承諾，比如“速度與高端數據庫的可靠性，”但對于系統內部細節描述不多。具體來說，可能出現的各種延遲是否會影響到事務并發和應用程序的可用性？作為參考，NoSQL數據庫可以提供驚人的速度和高可用性; 他們只需要'丟掉'事務支持，就能做到這一點。
Aurora是采用SQL語法的加強版NoSQL數據庫引擎？或者它是一個具有完全ACID屬性、兼容MPP事務和MVCC功能的NewSQL數據庫引擎？
只有時間才能給我們答案，但至少可以肯定一點，那就是ClustrixDB是一個完全對ACID兼容，支持MVCC功能的數據庫，在云計算的AWS，Rackspace和其他數百個全球實例上已經部署成功，每月處理萬億級的事務。
