關於做者 John Ryan是經驗豐富的數據倉庫架構師、開發人員和數據庫管理員。他專門從事多太字節Oracle系統上的Kimball維度設計，在移動電話和投資銀行等多個不一樣的行業積累了超過30年的IT經驗。 本文首次發表是做爲有關數據庫和大數據的系列文章中的一篇。數據庫
01 世界已經變了
在過去的20年，世界發生了翻天覆地的變化。在2000年的時候，上網的人不過寥寥數百萬，仍是用臺式機連56k的貓來上網，那時候亞馬遜還只賣書。今天，數十億人用智能電話或平板電腦每週7天、天天24小時上 網，幾乎什麼都在網上買，另外還使用 Facebook、Twitter和Instagram 這些社交應用與人互動。勢不可擋。 人們的心理預期也變了。若是網頁幾秒鐘未法完成刷新，咱們立即失去耐心，換個別的網站。若是某個網站沒法訪問，咱們擔憂那就是咱們所知文明的終結。若是某個大型網站沒法訪問，它會成爲全球性的大新聞。 即刻知足都還不夠！ (Instant gratification takes too long!) — Ladawn Clare-Panton 注：若是您不是經驗豐富的數據庫架構師，則您可能須要先閱讀我之前關於可擴展性和數據庫架構的文章。緩存
02 哪些變了？
由上可得出下列幾個結論：安全
- 可擴展性 — 流量可能出現爆炸性的增加，IT系統須要迅速擴大規模， 以處理指數化增加的事務
- 高可用性 — IT系統必須每週7天、天天24小時運行，而且必須具備故障容錯性。（美國銀行2011年發生一次故障，對2900萬客戶形成持續六天的影響）。
- 高性能 —隨着可擴展性的不斷加強，性能也必須跟上，保持穩定和快速。據亞馬遜估算，在極端狀況下，頁面加載時間每增長一秒，該公司每一年要損失16億美圓。
- 速度 — 設備自帶的聯網傳感器愈來愈多（遠的不說，智能電話就自帶聯網傳感器），每秒可能會有數以百萬計的事務須要處理。
- 實時分析 —夜間進行批處理和業務智能化已通過時。分析與操做處理之間的界限變得模糊，對實時決策的需求愈來愈多。
物聯網(Internet of Things)讓速度急劇加快！ — Stonebraker博士(MIT) . 上述需求催生極爲精彩的營銷術語Translytical數據庫，意思是採用混合解決方案，即同一個解決方案既可處理海量事務，也可完成實時分析。服務器
03 問題是什麼？
在下降成本的同時提供高性能（可能還要使用廉價服務器），是全部數據庫廠商都面對的挑戰。可是，需求之間相互衝突：網絡
- 性能—最大限度地縮短延遲，在毫秒級時間內完成事務處理。
- 可用性—即便系統的一個或多個節點發生故障或與網絡斷開，也能保持運行的能力。
- 可擴展性—可以不斷地擴大規模，以知足海量數據和事務速度的要求。
- 一致性—提供一致、準確的結果 — 特別是在發生網絡故障時。
- 耐久性—確保修改一旦實施後不會丟失。
- 靈活性—提供通用的數據庫解決方案，以支撐事務及分析方面的工做負荷。
要具有海量漸進擴展能力，惟一現實的辦法就是部署橫向擴展的分佈式系統。一般狀況下，爲最大地限度提升可用性，對某個節點實施的修改會被當即複製至兩個或更多個其餘節點。可是，一旦將數據分配給多個服務 器，則面臨利弊權衡。 例如：數據結構
3.1 性能與可用性和耐久性架構
許多NoSQL數據庫將數據複製至集羣內的其餘節點，以提升可用性。若是 數據庫節點在在寫入操做後當即崩潰，則數據在其餘機器上有備份，所以修改是持久的。可是，也可放鬆這個要求，不備份就當即返回。這可實現性能的最大化，但有丟失修改的風險。修改可能根本沒法持久。 
▲ 地理分散式系統異步
3.2 一致性與可用性分佈式
NoSQL數據庫支持最終一致性。例如，在上圖中，若是與紐約之間的網絡 鏈接臨時斷掉，則有兩個選擇：oop
- 中止處理 — 可是紐約的可用性就受到了影響
- 接受讀取/寫入操做 —在恢復網絡鏈接後消除差別。可是這麼作的風險是提供過時或錯誤的結果，可能須要解決寫
顯然，NoSQL數據庫是用一致性來換取可用性方面的能力。
3.3 靈活性與可擴展性 與Oracle和DB2等通用型關係數據庫相比，NoSQL數據庫的靈活性相對較 差，（例如）不支持Join（鏈接）操做。除了許多不支持SQL語言的數據庫，有些數據庫（例如Neo4J和MongoDB）是專爲支持特定問題而設計的—圖處理和JSON數據結構。 即便像HBase、Cassandra和Redis這樣的數據庫，也放棄關係鏈接操做， 但許多還限制訪問單一主鍵，而且不支持輔助索引。 許多數據庫都聲稱100%支持ACID事務， 實際上提供正式ACID保證者寥寥無幾。 — Peter Bailis 博士（斯坦福大學）
04 ACID與最終一致性
數據庫解決方案的擴展方面，主要挑戰之一就是維持ACID一致性。亞馬遜採用DynamoDB數據庫，放鬆一致性約束，以換取速度，從而解決了性能問題，由此催生了大量NoSQL數據庫。 另外，最成功的數據庫（包括Oracle）也沒法提供真正的ACID隔離性。本文研究了18個數據庫，默認支持SerializabilITy（可串行性）的數據庫只有三個（VoltDB、Ingres和Berkeley DB）。主要緣由是難以在保持性能的同時支持可串行性。 最終一致性是特別弱的一種模式。
系統可返回任何數據，依然能夠作到最終一致。 — Peter Bailis 博士（斯坦福） 另外一方面，最終一致性幾乎不提供一致性保證。下圖說明了最終一致性所存在的問題。一個用戶從銀行帳戶上扣款100萬美圓，可是在帳戶修改獲得複製以前，又有一個別的用戶檢查這個帳戶的餘額。惟一的保證是，只要沒有進一步的寫入操做，系統最終會提供一致的結果。這又有什麼用處呢？讓人接受就更談不上了。
▲ Cassandra — 最終一致性
05 從新設想OLTP數據庫
十年前，Michael Stonebraker博士撰寫了《架構時代的終結》(The End of an ArchITectural Era)這篇文章，認爲Oracle、微軟和IBM提出的1970年代的數據庫架構已通過時。 他提出OLTP數據庫應具有下列特色：
- 專門用於解決某一個問題 — 快速執行短暫的預約義（非即席的）事務，查詢計劃相對簡單。簡而言之，就是專用的OLTP平臺。
- 符合ACID規範 — 全部事務均爲單線程運行，默認提供所有可串行性。 老是可用 — 利用數據複製（而非熱備）來提供高可用性，幾乎不增長成本。
- 地理分散 —在由分散多處的機器組成的網格上無縫運行（進一步提升韌性，並局部地提升性能）
- 無共享架構 —多臺機器經過對等網格聯網，分擔負荷。添加機器是不會形成停機的無縫操做，而且失去一個節點僅會形成性能略微降低，而不是全系統中止運行。
- 基於內存 — 所有在內存中運行，以提升絕對速度，經過向其餘節點進行內存中數據複製來保證耐久度。
- 消除瓶頸 —完全從新設計數據庫的內部構件，實現單線程運行，同時消除重作(Redo)日誌以及鎖定和鎖存的必要性—這些都是數據庫性能最爲重大的制約。
爲證實上述各項的可能性，他建了一個原型，即H-Store數據庫，並證實使用相同的硬件， TPC-C基準性能是某商業競爭對手的82倍。H-Store原型成績優異，實現了每秒處理70,000個事務，而儘管數據庫管理員付出了大量努力進行調優，某商業競爭對手每秒僅850個。
06 世上無難事！
Stonebraker博士的成就使人側目。此前的TCP-C世界紀錄爲每一個 CPU 核心大約1,000個事務，但H-Store採用雙核2.8GHz臺式機，速度是原世界紀錄的35倍。他在2008年的文章《細探 OLTP 》(OLTP through the Looking Glass)中解釋了爲何商業數據庫（包括Oracle）的性能爲何如此差勁。
▲ 關係數據庫的處理資源消耗
上圖顯示，有93%的系統開銷是用於傳統（歷史遺留）的數據庫系統，包括鎖定、鎖存和緩存管理。合計只有7%的機器資源是專門用於手頭的任務。 H-Store只是經過消除上述瓶頸，使用基於內存的處理來代替基於磁盤的處理，就得以實現看似不可能的任務，即全面的ACID事務一致性，使速度提高了幾個數量級。
07 NewSQL數據庫技術
VoltDB最先發佈於2010年，是H-Store原型的商業化產品，屬於專用的OLTP平臺，用於Web級的事務處理和實時分析。如這張信息圖所示，目前有250種商業化數據庫解決方案，其中只有13種被納入NewSQL技術的行列。
08 VoltDB
與其餘NewSQL數據庫同樣，VoltDB旨在徹底在內存中運行，提供按期拍攝磁盤快照的選擇。它可在本地運行於64位Linux，也可以使用AWS、谷歌和Azure的雲服務來運行，採用橫向可擴展的架構。 傳統的關係數據庫將數據寫入基於磁盤的日誌文件。VoltDB則否則，是同時對內存內的多臺機器進行修改。例如，即便兩臺機器發生故障， K-Safety係數爲2時便可保證不會形成數據損失，由於數據至少存入三個內存節點。 事務做爲Java存儲過程(stored procedure)提交，可在數據庫中異步執行，而且數據自動分區（分片），分配至系統內的節點，儘管可複製基準數據以最大限度地提升鏈接性能。VoltDB有一點不一樣尋常，就是還以JSON數據結構的形式，支持半結構化數據。 就性能而言，2015年進行的一次基準測試顯示，VoltDB的處理速度至少是NoSQL數據庫Cassandra的兩倍，但成本只有AWS雲處理成本的六分之 一。 最後，VoltDB 6 .4版經過了極爲苛刻的 Jepsen分佈式安全性測試。 相比之下，此前對NoSQL數據庫Riak進行的測試代表，即便採用最強的一 致性設置，寫入也會降低30-70%。與此同時，採用輕量級事務時，Cas- sandra 最多損失5%的寫入。
09 MemSQL
與VoltDB相同的是，MemSQL是橫向擴展的內存型分佈式數據庫，專爲快速獲取數據和實時分析而設計。另外，既可在本地運行，也可在雲上運行，並可在不一樣節點之間自動分片，在每一個CPU核心上並行執行查詢。
▲ 關係數據庫的處理資源消耗 儘管與VoltDB有許多類似點，但上圖代表了一個重要的差別。MemSQL 試圖在實時事務與數據倉庫式歷史數據處理這兩種相互衝突的需求之間尋求平衡。爲此，MemSQL以行存儲(row store)的方式在內存中存儲數據， 並用面向列的磁盤存儲做爲備份，從而將實時（最近）數據與歷史結果結合在一塊兒。 這使其在OLTP和數據倉庫(Data Warehouse)領域得到了穩固的位置，儘管這兩種解決方案都是瞄準實時數據獲取和分析市場。
10 哪些應用須要NewSQL技術？
要求採集速度和響應速度很是快（平均1-2毫秒），同時要求ACID保證所提供的事務準確性的任何應用—例如客戶計費。 典型的應用包括：
- 實時受權 — 例如，爲了分析和計費而驗證、記錄和受權移動電話呼叫。一般，99 .999%的數據庫操做都必須在50毫秒內完成。
- 實時欺詐偵測— 用於完成複雜的分析查詢，以在交易受權以前，準確地肯定欺詐的可能性。
- 遊戲分析 —用於根據玩家的能力和玩家的典型行爲，實時動態修改遊戲難度。目標是留住現有玩家，以及將免費客戶轉化爲付費玩家。在速度、可用性和準確性要求很高的狀況下，某客戶經過運用這些手段，將玩家的遊戲支出提升了40%。
- 個性化Web廣告 — 實時動態地選擇基於 Web 的個性化廣告，記錄廣告呈現事件以用於計費，同時記錄廣告結果以用於後續分析。
與絕大多數OLTP應用相比，這些起初看來都不起眼，可是在每週7天、天天24小時聯網的世界，這些爲實時分析提供了新的疆域，而且隨着物聯網的興起，也帶來了巨大的機會。
11 結論
雖然Hadoop與大數據的關聯更爲密切，而且近來得到巨大的關注，但數據庫技術是任何IT系統的基石。 相似地，NoSQL數據庫爲替代關係數據庫提供了一個快速、可擴展的選 擇，可是儘管有免許可開源數據庫的誘惑，事實上仍是一分錢一分貨。另外，正如VoltDB所顯示的那樣，實際上長期來看，可能比NoSQL類的選擇更爲便宜。 總的說來，若是有Web規模、OLTP和（或）實時分析的要求，則須要認真考慮NewSQL類數據庫。
若是您對VoltDB的工業物聯網大數據低延遲方案、全生命週期的實時數據平臺管理等感興趣，歡迎私信，進入到咱們的官方交流羣。