Oracle、NoSQL和NewSQL 資料庫技術對比（一）

本文作者：約翰·瑞恩 - 瑞銀集團資料倉儲解決方案架構師

目錄

世界已經變了 . 1

哪些變了？ . 2

問題是什麼？ . 3

效能與可用性和耐久性 . . . . . . . . . . . . . . . . 3

一致性與可用性 . . . . . . . . . . . . . . . . . . . 4

靈活性與可擴充套件性 . . . . . . . . . . . . . . . . . . 5

ACID與最終一致性 . . . . . . . . . . . . . . . . 6

重新設想OLTP資料庫 . 7

世上無難事！ . 8

NewSQL 資料庫技術 . 9

VoltDB . 10

MemSQL . 11

哪些應用需要NewSQL技術？ . 12

結論 . 13

作者簡介 . 13

哪些變了？

由上可得出下列幾個結論：

• 可擴充套件性 — 流量可能出現爆炸性的增長，IT系統需要迅速擴大規模，以處理指數化增長的事務

• 高可用性 — IT系統必須每週7天、每天24小時執行，並且必須具有故障容錯性。（美國銀行2011年發生一次故障，對2900萬客戶造成持續六天的影響）。

• 高效能 — 隨著可擴充套件性的不斷增強，效能也必須跟上，保持穩定和快速。據亞馬遜估算，在極端情況下，頁面載入時間每增加一秒，該公司每年要損失16億美元。

• 速度 — 裝置自帶的聯網感測器越來越多（遠的不說，智慧電話就自帶聯網感測器），每秒可能會有數以百萬計的事務需要處理。

• 實時分析 — 夜間進行批處理和業務智慧化已經過時。分析與操作處理之間的界限變得模糊，對實時決策的需求越來越多。

• 物聯網( Internet of Things )讓速度急劇加快！ — Stonebraker博士(MIT ).

上述需求催生極為精彩的營銷術語Translytical資料庫，意思是採用混合解決方案，即同一個解決方案既可處理海量事務，也可完成實時分析。

問題是什麼？

在降低成本的同時提供高效能（可能還要使用廉價伺服器），是所有資料庫廠商都面對的挑戰。但是，需求之間相互衝突：

• 效能 — 最大限度地縮短延遲，在毫秒級時間內完成事務處理。

• 可用性 — 即使系統的一個或多個節點發生故障或與網路斷開，也能保持執行的能力。

• 可擴充套件性 — 能夠不斷地擴大規模，以滿足海量資料和事務速度的要求。

• • 一致性 — 提供一致、準確的結果 — 特別是在發生網路故障時。

• • 耐久性 — 確保修改一旦實施後不會丟失。

• • 靈活性 — 提供通用的資料庫解決方案，以支撐事務及分析方面的工作負荷。

要具備海量漸進擴充套件能力，唯一現實的辦法就是部署橫向擴充套件的分散式系統。通常情況下，為最大地限度提高可用性，對某個節點實施的修改會被立即複製至兩個或更多個其他節點。但是，一旦將資料分配給多個伺服器，則面臨利弊權衡。

例如：

效能與可用性和耐久性

許多NoSQL資料庫將資料複製至叢集內的其他節點，以提高可用性。如果資料庫節點在在寫入操作後立即崩潰，則資料在其他機器上有備份，因此修改是持久的。但是，也可放鬆這個要求，不備份就立即返回。這可實現效能的最大化，但有丟失修改的風險。修改可能根本無法持久。

地理分散式系統

一致性與可用性

NoSQL資料庫支援最終一致性。例如，在上圖中，如果與紐約之間的網路連線臨時斷掉，則有兩個選擇：

• 停止處理 — 但是紐約的可用性就受到了影響

• 接受讀取/寫入操作 — 在恢復網路連線後消除差異。但是這麼做的風險是提供過期或錯誤的結果，可能需要解決寫入操作的衝突。

顯然，NoSQL資料庫是用一致性來換取可用性方面的能力。

靈活性與可擴充套件性

與Oracle和DB2等通用型關聯式資料庫相比，NoSQL資料庫的靈活性相對較差，（例如）不支援Join（連線）操作。除了許多不支援SQL語言的資料庫，有些資料庫（例如Neo4J和MongoDB）是專為支援特定問題而設計的—圖處理和JSON資料結構。即使像HBase、Cassandra和Redis這樣的資料庫，也放棄關係連線操作，但許多還限制訪問單一主鍵，並且不支援輔助索引。

許多資料庫都聲稱100%支援ACID事務。

實際上提供正式ACID保證者寥寥無幾。

— Peter Bailis 博士（史丹佛大學）

ACID與最終一致性

資料庫解決方案的擴充套件方面，主要挑戰之一就是維持ACID一致性。亞馬遜採用DynamoDB資料庫，放鬆一致性約束，以換取速度，從而解決了效能問題，由此催生了大量NoSQL資料庫。

另外，最成功的資料庫（包括Oracle）也無法提供真正的ACID隔離性。本文研究了18個資料庫，預設支援SerializabilITy（可序列性）的資料庫只有三個（VoltDB、Ingres和Berkeley DB）。主要原因是難以在保持效能的同時支援可序列性。

最終一致性是特別弱的一種模式。

系統可返回任何資料，依然可以做到最終一致。

— Peter Bailis 博士（史丹佛）

另一方面，最終一致性幾乎不提供一致性保證。下圖說明了最終一致性所存在的問題。一個使用者從銀行賬戶上扣款100萬美元，但是在賬戶修改得到複製之前，又有一個別的使用者檢查這個賬戶的餘額。唯一的保證是，只要沒有進一步的寫入操作，系統最終會提供一致的結果。這又有什麼用處呢？讓人接受就更談不上了。

Cassandra — 最終一致性

（待續）