壹
早在2000年代中期，H-Store第一次在M.I.T.被我們提出來，VoltDB是H-Store的商業化產品，它表示結構相似的資料會被連續存放到一起。在本文的後續描述中，我們將使用V-H來縮寫。
V-H的設計（始於2004年）強調了在每秒可觀的低延遲（以毫秒為單位）的情況下，以每秒大規模事務（TPS）的方式實現最大效能。 這樣做的理由是，隨著更快的輔助儲存（例如SSD和NVRAM）的出現，基於磁碟的DBMS的效能將會提高。
綜上，必須設計基於RAM的DBMS，這樣相對於傳統的DBMS系統而言，才具有明顯的效能優勢。
貳
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的工業物聯網大資料低延遲方案、全生命週期的實時資料平臺管理等感興趣，歡迎私信，進入到我們的官方交流群。