5G革命：如何讓「數據」實現最大性能？
壹
早在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] //www.vldb.org/pvldb/vol10/p553-harding.pdf
[Malvaiya] //hstore.cs.brown.edu/papers/voltdb-recovery.pdf
[Yu] //www.cs.cmu.edu/~pavlo/blog/2013/12/fall-2013-research.html
[Somagani] //www.voltdb.com/blog/2018/11/06/benchmarking-voltdb-on-the-cloud/
[Acme] //www.voltdb.com/blog/2015/11/17/comparing-cloud-performance-ycsb/
如果您對VoltDB的工業物聯網大數據低延遲方案、全生命周期的實時數據平台管理等感興趣，歡迎私信，進入到我們的官方交流群。
