01 總 體 概 述

VoltDB受到全球電信軟體解決方案提供商的信賴，後者將其作為首選記憶體資料庫來驅動他們部署在全球100多家運營商處的任務關鍵型應用。VoltDB受到青睞的原因在於其效能和功能不僅能夠解決當前挑戰，而且還能支援業內各種系統的快速發展。

我們的下述基準測試展示了VoltDB的效能如何滿足或超越電信系統的要求，展示了 VoltDB具備的驅動諸如5G 之類的行業革命所需要的高效能、低延遲和線性擴充套件。

在這個基準測試中，我們在雲中測試了VoltDB v8.3，然後觀察到了可以隨伺服器數量線性擴充套件的效能以及超過300萬次運算/秒的速度，並且自始至終只有個位數的延遲。

1.VoltDB和5G發展

5G的出現給電信軟體解決方案提供商帶來了一些重要挑戰。除了新的硬體標準，這種網路進化也需要OSS和BSS的支援IT功能發生轉變。透過新服務建立創造額外收入的機會要求OSS和BSS功能具有靈活性和可擴充套件性， 以便在不斷增加的負載下實現新的用例。
這種對系統的要求提升了支援資料庫的重要性，其功能不再是簡單地儲存資料，而是充當一個活躍的實時決策系統。

簡而言之，VoltDB是一個電信級資料庫，它完全滿足主動實時決策系統的要求，例如支援 5G 可能所需要的系統。VoltDB是一個記憶體關聯式資料庫，具有極其重要和毫不折衷的可擴充套件性、可程式設計性和一致性。基於VoltDB構建的應用，無論是在電信、金融還是在零售領域，均具有水平可擴充套件性，經得起復雜性演變的檢驗，並且在一致性和正常執行時間方面十分可靠。

理論上，解決方案可由多個用於流、叢集管理、資料庫儲存和記憶體快取的開源工具來拼湊，但實際上，這些解決方案達不到要求。它們通常會增加系統間的延遲，在大量伺服器上管理多個軟體堆疊時的運營成本很高，並且在檢測和管理一致性和正確性時會產生客戶端程式設計負擔。

VoltDB不僅是高效能資料庫，它還提供驅動任務關鍵型實時電信應用所需的核心架構元素：

• 嚴格符合ACID要求
• 物化檢視、預存程式和使用者定義的函式
• 內在高可用性、災難恢復和多站點跨資料中心複製
• 雲/容器準備就緒
• 匯入/匯出流

當涉及到嵌入正確的資料庫來驅動5G應用時，沒有任何折衷空間。擁有成熟的企業級資料庫（不只是特性和功能，也包括全天候支援和嫻熟的專業服務）對於5G的成功至關重要。

02 基 準 測 試

2.1 線上計費系統

線上計費功能是瞭解5G在系統層面帶來的挑戰的理想示例。對於不斷增加的裝置多樣性，解決方案不僅必須應對來自數十億臺新連線的裝置的連線負載，而且還必須應對執行不同策略的複雜性。

因此，5G網路中的線上計費必須能夠隨負載和功能複雜性擴充套件，同時不在一致性或效能方面做出妥協。

2.2 為什麼我們需要ACID ?

這些應用的系統架構採用不同的方法來處理這些挑戰的影響。大多數應用使用鍵值儲存來獲得他們所謂的無限可擴充套件性的好處，但是這些應用被迫使用自定義機制來實現事務，從而產生一個複雜的系統，這種系統無法兌現關於簡單性和可擴充套件性的最初承諾。

即使最快的鍵值儲存也需要額外的客戶端-伺服器通訊及定製封鎖和一致性檢查，所有這些都將增加延遲和網路負擔。

另一方面，使用傳統資料庫進行擴充套件的問題眾所周知。我們認為VoltDB 在當今的資料庫市場中佔據一個獨特的位置，它不僅可以解決可擴充套件性和複雜性的挑戰，同時能夠保證最高一致性的、嚴格序列化的ACID事務。

2.3 實現細節

我們測試了由Google Cloud Platform提供的3、9、18 和27節點叢集構建的VoltDB 資料庫例項，工作負載模擬了一個簡化的線上計費應用，預載資料之後，基準測試應用執行10分鐘。

我們收集了執行期間每秒事務數(TPS) 和第99百分位延遲的效能統計資料（每個VoltDB 事務是一個單一的應用”運算“，並且術語是可交換的）。來自這些統計資訊的圖表資料證明了VoltDB具有線性可擴充套件性來應對不斷增加的工作負載，同時能夠維持可預測的低延遲。

2.4 應用

該應用主要由一個Java客戶端和一個VoltDB資料庫組成。實現每個運算的處理邏輯的預存程式同時使用Java 和 SQL 進行編碼以在資料庫上執行。
基準測試應用管理使用者的餘額，同時允許他們購買新服務和新增其他的限額， 例如分鐘、資料、訊息等。客戶端依賴資料庫來執行具有多個SQL 語句的複雜事務和能夠完全保證 ACID特性的條件邏輯。

2.4.1 架構

作為一個關聯式資料庫，VoltDB 中的資料由以下所示的表組成。每個表要麼是分割槽的，其中資料行在不同位置間分佈 (sites_per_node * node_count)，要麼是複製的，其中每個節點擁有該資料表的完整副本。不常更新的表，例如產品表，是儲存為複製表的理想示例。

然而，產品表是主要工作負載的一部分，因為它被用來獲取使用者試圖購買的產品的價格。使用者表、使用情況表和餘額表被建立為分割槽表，從而實現高併發性的讀寫訪問。

2.4.2 資料

工作負載在一個穩定的資料集上執行，該資料集根據叢集的大小進行擴充套件。不同叢集的起始資料集大小遵循以下比例：

2.4.3 工作負載

工作負載由兩個並行執行的操作組成，即分配限額和新增使用者/餘額。這些操作在Java + SQL中實現，涉及到使用條件邏輯執行多個SQL語句，這些語句提供的好處是減少網路行程和在每個邏輯事務中實現更多工作。
起始資料集載入之後，以相同的頻率並行呼叫工作負載中的兩個操作以實現目標吞吐量。兩個操作都很複雜，涉及到必須透過連線多個表的資料做出的決定。透過將每個操作實現為VoltDB 預存程式，整個操作將作為一個完整事務成功或失敗，並將狀態返回給客戶端應用：
“
分配額度 — 訪問 4 個表。僅在確認使用者的賬戶餘額充足時分配額度，並在成功分配之後減少餘額。
新增使用者/餘額 — 訪問 2 個表。新增一個新使用者到系統或增加某個使用者的餘額。

2.4.4 衡量標準

基準測試應用在不同的節點配置上執行，以證明VoltDB 在執行高度事務型工作負載時的可擴充套件性。我們在每種節點配置上捕捉延遲和吞吐量資料點，並使用它們繪製可擴充套件性曲線。
我們在執行10 分鐘後捕捉資料點。此等待期幫助我們確保系統達到中等CPU利用率（介於 55%和 60%之間）的穩定狀態，並且每臺機器的RAM利用率大致為33%。

2.5 環境

基準測試在Google Cloud例項上進行。節點配置如下：

03 基準測試結果與分析

關於基準測試結果的背景，我們想要說明的是，基於我們與電信客戶的對話，針對要求最為苛刻的5G 應用的SLA 是低於5 毫秒的可預測延遲，以及每秒處理 2~6 百萬資料行的能力和線性擴充套件的能力。我們可以在這些嚴格的SLA的背景下看待基準測試結果。

VoltDB（4 個分割槽在4 核機器上執行 ）的吞吐量和延遲

這張圖表展示了吞吐量與節點數量的近似線性擴充套件。測試的最大叢集含有27個節點。觀察到的最高吞吐量是每秒740,703次運算。

上圖還表明，對於每個測試的叢集大小，第99百分位延遲符合 SLA 所要求的5毫秒（27個節點的叢集除外，其延遲略長於5 毫秒）。考慮到5G級電信SLA是所有行業或用例中最為嚴格的，以及計費應用的複雜性，VoltDB 輕鬆超越吞吐量和延遲SLA 是一項非常了不起的成就。

VoltDB（16 個分割槽在16 核機器上執行）的吞吐量和延遲

基準測試在16核機器上執行，該機器更接近於生產系統中的配置，因此可以很好地衡量VoltDB 的效能。同樣， VoltDB展現出了線性可擴充套件性，並在27節點叢集上實現了超過每秒300萬次運算的吞吐量，因而它可以滿足或超越SLA要求。

對於各種叢集尺寸，VoltDB 的延遲遠低於SLA要求的5毫秒。對於3個節點的較小叢集，它的第99百分位延遲略長於3毫秒，而對於其他叢集配置，它的延遲低於3 毫秒！

不同VoltDB 叢集（4 個分割槽在4 核機器上執行與16 個分割槽在16 核機器上執行）的吞吐量比較

不出所料，隨著分割槽大小的增加和核心數量的增加，吞吐量顯著增加。對於4核和4個分割槽的27節點叢集，吞吐量低於75K，而對於16核和16個分割槽的27節點叢集，吞吐量超過了每秒300萬次運算！

不同 VoltDB 叢集（4 個分割槽在4 核機器上執行與16 個分割槽在16 核機器上執行）的延遲比較

吞吐量隨伺服器/分割槽數量增加而增加的趨勢也適用於延遲。擁有16 個分割槽的最強大的16 核伺服器比擁有4個分割槽的4 核伺服器具有較低的第99 百分位延遲。對於4 核機器的 27節點叢集，延遲剛剛超過5毫秒，而對於16核機器的27節點叢集，延遲低於3毫秒。

3.1 實現高擴充套件性的秘訣

“如前所述，VoltDB 專為線性擴充套件而設計。為了實現甚至超過300萬次運算/秒的吞吐量，使用者只需要簡單地新增VoltDB節點，直到獲得理想的吞吐量。”

3.2 總體擁有成本（TCO）

除了一流的效能之外，VoltDB還具有比業內任何其他解決方案低得多的TCO。雖然可能有人認為“開源解決方案是免費的”, 但天下沒有免費的午餐。

很多最初選擇開源解決方案的電信客戶在經歷眾多痛苦之後轉向了VoltDB。他們還意識到，開源工具經常在更大的硬體上執行，從而導致非常高的資本開支，並且由於這些解決方案需要代價高昂的開發工作量來進行產品構建、維護和故障檢測，運營成本遠高於提供全天候產品支援的VoltDB產品許可。

世界最大的電信軟體解決方案提供商之一從Redis轉向VoltDB，僅在硬體方面就節省了一百萬美元。

04 結 論

為了回應傳統SQL資料庫（如Oracle、IBM 和 SQL Server等等）的不靈活性，NoSQL資料庫（例如Redis、Cassandra 和MongoDB等等）已經問世。它們大肆宣稱它們能夠透過儲存和查詢非結構化資料來實現擴充套件，而無需實施關聯式資料庫的結構化概念。

儘管他們最初聲稱NoSQL資料庫不“依賴”於SQL是有好處的，但SQL的標準化、靈活性和在查詢大量資料方面的效率無法被替代的現實阻礙了它們進入高效能或任務關鍵型應用的可行性。

NoSQL廠商試圖在頂層支援 SQL 語言的嘗試仍然未能實現其目標：提供類似於當前SQL 資料庫的基礎ACID特性保證。像VoltDB這樣的下一代SQL資料庫是一個兩全其美的解決方案，具有NoSQL 解決方案的可擴充套件性，以及對5G應用至關重要的高吞吐量、低延遲、高可用性、強大的ACID 事務、實時分析和其他功能。

這項基準測試研究的結果證明，VoltDB 可以提供要求極為苛刻的5G 應用所需的線性擴充套件、低延遲和高吞吐量， 同時不犧牲一致性。VoltDB超過300萬次運算/秒的吞呈量和低於5毫秒的第99百分位延遲可以滿足針對5G系統提出的SLA，而NoSQL資料庫遠不能滿足電信應用的效能和延遲要求。如果您想要執行基準測試，我們建議您從我們的公共儲存庫下載應用原始碼，然後親自嘗試：

如果您對VoltDB的工業物聯網大資料低延遲方案感興趣，歡迎私戳，進入到我們的官方交流群。
VoltDB中國：sgao##voltdb.com （請將“##”替換成“@”）