來源：https://blog.csdn.net/ransom0512/article/details/50440316
簡介
VoltDB數據庫是一個分佈式，可擴展，shared-nothing的內存數據庫。使用JAVA 寫的存儲過程來定義事務。使用標準SQL訪問數據，使用並行的單線程處理方式確保數據一致性，同時避免了傳統數據庫的鎖，插銷，資源管理開銷。
VoltDB具有如下特點：
- 高吞吐量：百萬次每秒
- 橫向拓展：可以根據需求自由拓展，性能線性增長。
- 高可用性：數據支持副本、也可以持久化保存、除此之外，還支持雙活機制。
- 實時數據分析：數據實時性高，因為都是內存計算。
- 完整ACID支持，保證事務性和可靠性。
VoltDB的設計動機來源於內存成本的大幅下降，系統對於數據的時效性要求越來越高，而傳統數據庫由於數據在本地文件保存，所以不論併發還是處理速度，都難以滿足要求。而新型的NoSQL數據庫，又缺乏SQL支持以及完整的ACID的支持，完全無法提單傳統數據庫。
VoltDB、NoSQL和傳統關係型數據庫的對比如下所示：
適用場景
VoltDB適合OLTP系統，單個事務較小，但是事務總量非常之多的應用。比如金融，零售，WEB2.0等傳統OLTP應用。不適合進行範圍查詢或者頻繁多表Join這樣的場景。
設計思路
高吞吐量、實時性
VoltDB通過對傳統數據庫進行分析，發現數據只有12%的CPU時間在做真正有意義的數據操作，而其他絕大部分時間都被緩存，併發控制等步驟消耗了。
- 索引管理(Index Management)：數據庫的索引一般是基於B樹的，這些索引會顯著消耗IO和CPU。
- 日誌(Logging)：傳統數據庫一般會寫兩次日誌，一個是數據庫數據存儲部分，一個是數據庫恢復日誌，而且這些操作都必須強制性刷到磁盤上去，這就帶來顯著的IO消耗。
- 鎖(Locking)：數據的讀寫操作都會涉及到鎖，這是一個十分頻繁的操作。
- 鎖管理器(Latching)：全局共享的數據比如索引數據，表元數據，資源信息等，都必須保障多線程環境下的可靠運行，所以這種鎖管理器無疑會消耗更多的CPU資源。
- 緩存管理(Buffer Management)：數據存儲在固定大小的磁盤頁中，緩衝池則管理著這些磁盤頁，這些都會來言密集的IO操作。
綜上，有88%的CPU時間都浪費在這些對於實際操作無意義的步驟上去了，要提升數據庫性能，只有從根本上減少這種冗餘的步驟，集中進行數據運算，才能完全利用CPU。
VoltDB通過內存存儲、數據分區和無鎖計算來實現高性能運算。
- 內存存儲
VoltDB所有數據都保存在內存中(可靠性中會有數據刷到磁盤，見VoltDB ACID中可靠性設計), 內存存取速度已經比磁盤遠遠高出幾個數量級了，這就是VoltDB高性能的重要原因。
- 數據分區
VoltDB對每個節點的內存進行管理，在每個節點上創建多個分區，所有分區表中的數據，都分散在各個分區中，然後在讀寫的時候，就可以實現多個分區併發進行，所以拓展性是線性提升的。
這種分區機制也會帶來問題，當集群需要擴容的時候，需要停止整個集群，然後再進行擴容；當集群啟動的時候，VoltDB會重新調整數據分佈，在所有數據分佈調整完畢之後，才開始提供服務。
- 無鎖計算
VoltDB數據分區存放，在執行SQL語句的時候，客戶端就會根據條件自動判斷數據在哪個分區中，然後下發至該分區執行。如果查詢條件中不包含分區列，那麼就會由客戶端進行統一控制，在每個分區上都進行查詢之後，再統一返回結果，這種場景會極大影響性能。
VoltDB的程序都是以存儲過程的方式執行的，支持使用java或者其他語言定義存儲過程。每個分區的存儲過程執行都是單線程線性執行的，這就保證了單分區的無鎖設計。當一個語句涉及到多個區分協調讀寫的時候，VoltDB會在協調，統一鎖定分區隊列，等該語句執行完畢之後，才會釋放鎖。所以多分區操作才會如此消耗性能。
VoltDB在分區管理上，建議每個物理CPU創建一個分區，這樣單個分區內的數據都在CPU的一級緩存和二級緩存上，避免在多個CPU之間的數據操作，最大限度的提升CPU利用率，避免併發鎖。所以理論上，VoltDB的CPU使用率是可以達到100%的。
橫向拓展
VoltDB多分區設計，使得數據分散在各個分區中，每個分區可以提供併發訪問，既提升了性能，也達到了無鎖的效果。所以理論上，VoltDB的橫向拓展可以使得性能得到線性提升。
高可用性
VoltDB使用K-safety、雙活、snapshot、WAL機制組合機制保證數據的高可用性。
- K-Safety
其實就是N+1的副本機制，VoltDB在寫數據操作的時候，會在每個副本中執行該語句，這樣就可以保證數據被正確插入每個副本。這N+1的副本都可以同時提供訪問，同時允許最多N個副本丟失(分區故障), 當N+1個副本都不可用的時候，VoltDB就會停止服務進行修復。
- 雙活
多集群雙活機制，兩個集群都可以提供服務，數據在多分區之間異步複製，當一個集群掛了的時候，另外一個集群提供服務，當異常集群恢復之後，會自動進行數據同步，只有數據一致的時候，才會提供服務。但是這種機制其實還是有問題，有可能導致數據不一致，因此同步複製機制還是需要的。
- Snapshot
由於數據在內存中存放，當節點掉電的時候，數據就會丟失，所以VoltDB會定期對每個分區數據做快照，以備節點掉電時候進行恢復。
- WAL
Write ahead log，VoltDB會在對數據進行插入操作的時候，預先進行寫日誌操作，這個和傳統數據庫一樣，但是由於是順序寫入，所以性能還是比傳統數據庫要好很多。
Snapshot機制和WAL機制會導致造成性能5%左右的下降，不過這個也是為了完整ACID不得不做出的犧牲。
分區表和複製表
- 分區表
創建表之後，需要手工執行分區語句為表進行分區。
PARTITION TABLE towns ON COLUMN state_num;
該語句表明使用state_numn字段為towns表進行分區。之後插入數據的時候，VoltDB會自動將數據插入指定分區。
目前VoltDB只支持Hash分區，後續可能會考慮支持範圍分區。
VoltDB的分區是一個邏輯上的概念，一個分區中可能包含多個表的多個數據分區的數據。VoltDB建議按照物理CPU的數量進行分區，每個分區獨立使用一個CPU，這樣可以避免CPU之間的鎖競爭。
- 複製表
一個表，沒有指定分區，那麼就是一個複製表。這個表的特徵就是會在每個分區保存一份全量副本，這樣在和其他表在做Join查詢的時候，就不會跨節點查詢，大大加快Join速度。
複製表適合於數據比較穩定，只有少量更新的場景。如果數據要更新，就意味著要在每個分區上都執行一次插入操作，這種操作會顯著降低系統併發度。
性能
VoltDB 宣稱具備非常高的可伸縮性，超過 120 個分區、39臺服務器，可在 300 個 CPU 核心上每秒鐘處理 160 萬的複雜事務
VoltDB在資料中有一個和數據庫進行的性能對比，結果如下：
Dell R610, 2x 2.66Ghz Quad-Core Xeon 5550 with 12x 4GB (48GB) DDR3-1333 Registered ECC DIMMs, 3x 72GB 15K RPM 2.5in Enterprise SAS 6GBPS Drives
ACID
- 原子性（Atomicity）
VoltDB通過使用存儲過程來確保原子性，一個存儲過程執行必須等待前一個存儲過程成功或因為失敗而回滾結束。
- 一致性（Consistency）
VoltDB強數據類型約定，在所有的數據庫查詢中強制schema與數據類型約束.
- 隔離性（Isolation）
VoltDB事務全局（所有被影響的分區）順序執行（沒有交叉）（任何一個分區同一時間只有一個執行，即串行的）。
- 持久性（Durability）
VoltDB提供K-safely機制以及snapshot,確保數據持久化。
License
License為AGPL，該許可比GPL要求更加嚴格，產品即使以WEB的方式發佈了，也必須公開源代碼。在使用的時候需要小心。
閱讀更多 oscube 的文章
