壹
早在2000年代中期，H-Store第一次在M.I.T.被咱們提出來，VoltDB是H-Store的商業化產品，它表示結構類似的數據會被連續存放到一塊兒。在本文的後續描述中，咱們將使用V-H來縮寫。
V-H的設計（始於2004年）強調了在每秒可觀的低延遲（以毫秒爲單位）的狀況下，以每秒大規模事務（TPS）的方式實現最大性能。 這樣作的理由是，隨着更快的輔助存儲（例如SSD和NVRAM）的出現，基於磁盤的DBMS的性能將會提升。
綜上，必須設計基於RAM的DBMS，這樣相對於傳統的DBMS系統而言，才具備明顯的性能優點。html
貳
V-H採用了3個關鍵的技術聚焦點：數據庫
2.1 聚焦單分區事務性服務器
多節點主內存DBMS必須跨各個節點對數據進行分區。多節點事務不可避免地涉及負載很大的分佈式併發控制協議。正如在[Harding]所描述，分佈式併發控制大大下降了操做執行速度。若是事務之間存在重大資源等待，吞吐量也會大大下降。爲了不這種開銷，V-H專一於優化所謂的單分區事務。
在這種狀況下，應用程序設計人員應組織其數據，以便幾乎全部事務都不會跨越多個節點上的數據。許多應用程序天然是「單個部分」，例如更新單個用戶的餘額，並檢查其受權電話呼叫權限。換句話說，將用戶賬戶劃分爲多個節點將使上述交易僅跨越一個分區。另外一方面，將資金從一個賬戶轉移到另外一個賬戶一般不能成爲單一分區，由於一般沒法將兩個賬戶都彙集在一個分區中。
總而言之，許多應用程序能夠作成單個分區，而有些則不能。另外，幾個很是大的應用程序都堅持認爲全部事務都是單個分區的。所以，他們禁止將多分區事務做爲應用程序體系結構的最佳實踐，以使性能最大化。
V-H選擇針對「單分區」事務進行優化，使其能夠達到很高的運行性能。
儘管V-H也能夠執行「多分區」事務，但它們的性能並不高。咱們應該在主要是單個分區的場景中使用VoltDB。網絡
2.2 聚焦在存儲過程架構
大多數OLTP用例主要包含重複性事務，所以，有一些大批量交易類型。由於執行單個事務須要服務器與客戶端中的屢次通訊，因此使用ODBC / JDBC執行這些操做不是最佳選擇。
NoSQL中單次訪問接口的應用程序，其中值被一對一地檢索到客戶端處理，也會有相似的通訊開銷，這不只會致使屢次客戶端-服務器通訊開銷，並且還會致使對網絡帶寬使用形成沒必要要的壓力。相反，若是使用存儲過程接口，在這種狀況下，事務執行代碼（Java和SQL的混合）被移入DBMS，能夠僅用一條通訊消息執行它。1980年代中期Sybase引入存儲過程時，相比到ODBC / JDBC接口數據訪問，大約有5倍的性能優點。
所以，V-H使存儲過程接口以得到更高的運行性能。併發
2.3 聚焦在主動-主動數據複製分佈式
基本上全部OLTP應用程序都須要高可用性（HA）。這要求每一個對象被複制屢次，而且崩潰時要求系統故障轉移到備份。在正常處理期間，V-H必須確保處理全部副本都執行相關事務，或都不處理任何事務。只有這樣，V-H纔會實現「故障轉移」而不會致使數據損壞。
執行副本更新有兩種可行的策略：性能
2.3.1 主動-主動複製測試
即：事務在全部副本上執行，並在全部節點上本地提交。
在這種狀況下，全部副本都是「活動的」，而且每一個具備副本的站點都將進行事務處理。
例如，AT＆T將讓東海岸和西海岸的客戶與最近的集羣進行對話，並在後臺進行主動複製同步。大數據
2.3.2 主動-被動複製
即將一個副本指定爲主副本，並首先在其中執行每一個事務。日誌記錄寫入此節點，而後經過網絡移至備份節點。
在每一個備份中，日誌都會前滾以使輔助數據庫與主數據庫同步。
叄
鑑於有兩種可行的策略，應選擇哪種？
幾年前，[Malvaiya]在VoltDB中實現了單副本崩潰恢復。他比較了兩種策略：
1.在恢復時編寫命令日誌並從新運行命令
2.寫入數據日誌，並在恢復時將日誌前滾。
他發現命令日誌在執行期間的開銷能夠忽略不計，所以比數據記錄方法快得多。[Yu]將此代碼擴展到了複製，並實現了主動-主動和主動-被動複製。他發現主動-主動是性能優勝者，幾乎是兩倍。
因此VoltDB專一於主動-主動複製，這須要V-H偶然使用的肯定性的併發控制策略。相反，大多數V-H競爭對手使用不肯定的併發控制策略（例如，動態鎖定，樂觀併發控制，多版本併發控制）。所以，主動-主動不是這些系統的選擇，它們也沒有兩倍速度優點。
整體而言，這三個決策使V-H能夠比其餘主要內存DBMS在事務處理上甚至能夠快到一個數量級。在基準（[Somagani]，[Acme]）測試中，V-H在合理大小的羣集上每秒運行1M事務。到目前爲止，這比咱們所知道的任何客戶工做負載都要快。所以，V-H競爭者能夠按訂單運行這些工做負載，可是須要投入更多的硬件成本。
肆
不過伴隨5G應用的興起，這種競爭格局將發生巨大變化。
5G有望提供更高的帶寬，更高的密度（每平方公里最多一百萬個設備）和毫秒級延遲。設備的這種密度迫使新的無線接入網（RAN）小區技術避免飽和現有網絡。反過來，這將成倍增長數據庫TPS的數量，以便：
更新網絡中每一個設備的狀態更改信息
對每一個新設備通訊都執行實時身份驗證和受權策略此外，網絡切片是5G要求，一部分網絡專用於每一個用例，例如：工業物聯網，視頻，VR等。每種狀況都須要即時決策，以實現負載平衡和服務質量保證，以增長用戶數量（人員+物聯網設備）。
爲了演示更高TPS的需求，讓咱們考慮一個典型的無線運營商示例：一箇中等大小的運營商可能支持1000萬部電話；較大的可能有1.5億。典型的無線運營商具備大量事務交易型的應用程序。這裏有一些例子：
計費和收費：當前的網絡以6秒爲增量計費，即每分鐘10次。若是普通電話的佔空比爲10％，則小型網絡每分鐘有600萬個計費事件，或每秒100,000個。對於較大的網絡，該數目要高得多。隨着時間的流逝，物聯網設備的數量預計至少會翻兩番。這樣，計費將是一個很是高的TPS應用程序，而且在毫秒級的延遲下不會下降一致性要求。
新服務：物聯網設備預計將繼續在5G世界中啓用新服務。這些將包括醫療警報應用程序，當人跌倒或摔倒時可鏈接到緊急人員救援。因爲足球場中的訂戶很是集中，所以動態地旋轉地理圍欄子網以應對鏈接高峯。智能計量將實現個性化的客戶體驗和溝通，並促進對電網消耗，能源需求的分析，並符合新的法規要求。在風能和太陽能農場，5G還能夠對IOT傳感器進行連續監控和預測性維護。
伍
總而言之，因爲5G的特性，讓不少應用的事務性操做需求飛速增加。
另外，大多數無線應用程序（例如計費）是單分區事務，能夠充分發揮VoltDB的架構設計優點。對於這類應用程序，即使是中等大小的無線運營商，也必須每秒支持數百萬個事務。大多數內存DBMS並不能支持這種數量的事務。
VoltDB是一個例外，咱們一些準測試也顯示了架構理念上的領先性。若是您是KTPS應用程序（每秒數千個事務），那麼有不少解決方案。但若是您期待MTPS（每秒數百萬個事務），請嘗試一下VoltDB。
做者：Michael Stonebraker
參考引用
[Harding] http://www.vldb.org/pvldb/vol10/p553-harding.pdf
[Malvaiya] http://hstore.cs.brown.edu/papers/voltdb-recovery.pdf
[Yu] http://www.cs.cmu.edu/~pavlo/blog/2013/12/fall-2013-research.html
[Somagani] https://www.voltdb.com/blog/2018/11/06/benchmarking-voltdb-on-the-cloud/
[Acme] https://www.voltdb.com/blog/2015/11/17/comparing-cloud-performance-ycsb/
若是您對VoltDB的工業物聯網大數據低延遲方案、全生命週期的實時數據平臺管理等感興趣，歡迎私信，進入到咱們的官方交流羣。