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