轉自：https://blog.csdn.net/nanfeiyannan/article/details/9003009
https://blog.csdn.net/ly4983/article/details/18303547
https://blog.csdn.net/caomiao2006/article/details/52076008
https://blog.csdn.net/dh2442897094/article/details/64440130
http://www.360doc.com/content/14/0110/21/281812_344213831.shtml
https://www.cnblogs.com/tianqing/p/7429900.html
https://blog.csdn.net/sprita1/article/details/81781345
https://my.oschina.net/u/115763/blog/190962
mysql、H2插入性能對比
https://blog.csdn.net/huhai463127310/article/details/8222894
https://blog.csdn.net/yixiaoping/article/details/9801199
VoltDB內存數據庫分析
https://blog.csdn.net/olidrop/article/details/7065384
https://www.cnblogs.com/kkyycom/p/9359090.html
http://www.360doc.com/content/14/0110/21/281812_344213831.shtml
https://www.cnblogs.com/zl0372/articles/MemSQL.html
主要內存數據庫對比
|
名稱 |
開源或商業 |
主要特點 |
|
Oracle TimesTen |
不開源，商業使用付費 |
1. 符合RDBMS標準的獨立內存數據庫服務。 |
|
2.支持SQL訪問，支持ODBC&JDBC。 |
||
|
3.本身不支持與非Oracle數據庫的互操作。 |
||
|
4.高可靠性，支持完整日誌，支持鏡像複製功能。 |
||
|
5.目前不支持存儲過程和觸發器。 |
||
|
6.內存結構簡單，並沒有數據庫緩衝區、保存池或丟棄池的概念。 |
||
|
7.目前支持散列索引和T樹索引，前者僅支持餘鍵-值查找，速度非常快，執行過程與底層表的數量無關，具有較高的讀取擴展性和很好的併發性；T樹索引讀取效率很高，但是，在繁重寫操作時，併發性較差。 |
||
|
ASE-IMDB |
不開源、商業使用付費 |
1.被整合到Sysbase ASE平臺中（TimesTen則爲一個獨立的數據庫）。 |
|
2. 基於經典ASE數據庫模板創建。 |
||
|
3. 採用複製技術實現讀取其他數據源的數據。 |
||
|
4. 完全支持ASE本身的SQL語法、安全性和加密。 |
||
|
IBM SolidDB |
不開源、商業使用付費 |
1.可以提供超快的速度和超高的可用性，可以提供每秒數萬至數十萬事務的吞吐率，並且始終可以獲得微秒級的響應時間。 |
|
2.拋棄大數據塊結構，錶行和索引節點獨立地存儲在內存中，可以直接添加索引，而不必重新組織大塊結構。 |
||
|
3.放棄使用大塊索引，以精簡結構、增加索引層數、將索引節點最小化，從而避免節點內處理的成本。 |
||
|
4.使用一種稱作trie（前綴樹）的索引方式，更適合現代處理器緩存，通過有效促進緩存的使用來提高處理器的效率，從而實現性能的最大化。 |
||
|
5.使用一種獲得專利的檢查點方法來加快數據處理，查詢事務的延時通常是10到20微秒，更新事務的延時通常小於100微秒。 |
||
|
VoltDB |
開源版本免費 商業版本需付費 |
1.基於存儲過程的事務提交方式：用戶通過寫存儲過程完成應用程序的邏輯，作爲一個先置條件將存儲過程提交到VoltDB，運行時，用戶程序調用存儲過程完成事務操作，所有事務的運行邏輯是由VoltDB在服務器進程中完成。 |
|
2．基於Shared Nothing結構的數據分佈，整個數據庫的數據分散到集羣的多臺機器上。 |
||
|
3.基於哈希的數據分佈策略，好處是數據分散的均勻，沒有動態數據調整的煩惱；缺點是新增的機器需要停止服務後重新分佈數據。哈希方法打亂了數據的連續性，使得VoltDB對於範圍查詢的處理能力顯著下降。 |
||
|
4.其事務併發控制需要依賴於集羣內所有機器的時間一致，其數據分片規模是按照集羣核數來劃分，當整個系統壓力比較大時，可以使事務的時延有效降低。 |
||
|
eXtremeDB |
不開源的商業數據庫， 測試版本在功能上與正式版沒有區別，但是，對連接次數做了限制 |
1.高性能和高效的存儲效率，爲了提高性能方便程序使用，eXtremeDB中的數據未做任何壓縮。 |
|
2.不僅開源建立完全運行在主內存的內存數據庫，更可以建立磁盤/內存混合介質的數據庫。 |
||
|
3.嵌入式數據庫：其內核以鏈接庫的形式包含在應用程序之中，開銷只有50KB-130KB；避免了進程間的通信，從而剔除了進程間通信的開銷和不確定性；其獨特的數據格式方便程序直接使用，剔除了數據複製及數據翻譯的開銷，縮短了應用程序的代碼執行路徑。 |
||
|
4.由應用定製的API，應用程序對eXtremeDB數據庫的操作接口是根據應用數據庫設計而自動產生，剔除了通用接口所必不可少的動態內存分配。 |
||
|
5.其獨特的體系結構，保證了數據管理的可預測性。 |
||
|
SQLite |
開源，免費使用 商業目的的分發版免費 |
1.需要專業支持則需要購買。 |
|
2. 在併發（包括多進程和多線程）讀寫方面的性能一直不太理想。數據庫可能會被寫操作獨佔，從而導致其它讀寫操作阻塞或出錯。 |
||
|
3.32\64位主流操作系統均支持。 |
||
|
4.不支持ODBC連接，需通過第三方驅動支持JDBC連接。 |
||
|
5.支持SQL |
||
|
H2 |
開源，免費使用 商業目的的分發版免費 |
1.需要專業支持則需要購買。 |
|
2. 併發性較好（在模擬器中有使用，支持50個併發查詢沒問題），數據量少的情況，查詢速度很好。 不適合大數據量高併發的操作 |
||
|
3.32\64位主流操作系統均支持，但需Java平臺支持。 |
||
|
4.支持ODBC&JDBC |
||
|
5.支持SQL |
******************************************************************************************************
內存數據庫SQLite和H2比較
內存數據庫，顧名思義就是將數據放在內存中直接操作的數據庫。相對於磁盤，內存的數據讀寫速度要高出幾個數量級，將數據保存在內存中相比從磁盤上訪問能夠極大地提高應用的性能。
本文中主要爲大家介紹兩種內存數據庫類型，即SQLite和H2內存數據庫，將SQLite和H2內存數據庫二者進行各方面性能的比較，希望對大家那個有所幫助。
SQLite和H2內存數據庫之比較：
SQLite和H2內存數據庫都比較快。
查詢性能：查詢一條記錄 SQLite的性能要優於H2。查詢（5000或10000）條 H2的性能要好於SQLite。
插入性能：性能差不多快，SQLite略快。
更新性能：更新一條記錄 SQLite的性能好於H2。更新多條記錄（有索引），SQLite【0.04s】的性能要好於H2【0.18s】
刪除性能：刪除一條記錄.SQLite【非常小】的性能略好於H2【非常小】。刪除多條記錄，SQLite【0.078s】好於H2的【0.12s】
啓動時間：都比較快
併發性能：H2的查詢支持一定的併發性，要強於SQLite。更新和插入，基本上都沒有併發可言。
總的看來，SQLite的性能要好於H2，但併發性不如。
另外SQLite一般使用C的API接口訪問，而H2支持JDBC。
並且都可以大多數主流平臺上
對於C\C++\C#應用而言，使用SQLite是更好的選擇。對於Java應用，H2是不錯的選擇。
奇怪的兩點：
1.在無索引查詢單條數據，SQLite的性能【0.375s】要比H2【6.9s】要快非常多。(原因發現是H2使用Big Long效率差了好多，比起Int)
2.在無索引查詢多條數據，SQLite的性能甚至比有索引時還好快一些？？？？。而有索引情況下H2查詢多條數據也好於SQLite
通過上文中的介紹，相信大家現在對於SQLite和H2內存數據庫這兩種內存數據庫已經有了很好的瞭解，這樣就便於大家以後子啊工作中使用SQLite和H2內存數據庫。
**********************************************************************************************
內存數據庫主流的有哪些，並給出各自特點！
內存數據庫從範型上可以分爲關係型內存數據庫和鍵值型內存數據庫。
在實際應用中內存數據庫主要是配合oracle或mysql等大型關係數據庫使用，關注性能。
作用類似於緩存，並不注重數據完整性和數據一致性。
基於鍵值型的內存數據庫比關係型更加易於使用，性能和可擴展性更好，因此在應用上比關係型的內存數據庫使用更多。
比較FastDB、Memcached和Redis主流內存數據庫的功能特性。
FastDB的特點包括如下方面：
1、FastDB不支持client-server架構因而所有使用FastDB的應用程序必須運行在同一主機上；
2、fastdb假定整個數據庫存在於RAM中，並且依據這個假定優化了查詢算法和接口。
3、fastdb沒有數據庫緩衝管理開銷，不需要在數據庫文件和緩衝池之間傳輸數據。
4、整個fastdb的搜索算法和結構是建立在假定所有的數據都存在於內存中的，因此數據換出的效率不會很高。
5、Fastdb支持事務、在線備份以及系統崩潰後的自動恢復。
6、fastdb是一個面向應用的數據庫，數據庫表通過應用程序的類信息來構造。
FastDB不能支持Java API接口，這使得在本應用下不適合使用FastDB。
Memcached
Memcached是一種基於Key-Value開源緩存服務器系統，主要用做數據庫的數據高速緩衝，並不能完全稱爲數據庫。
memcached的API使用三十二位元的循環冗餘校驗（CRC-32）計算鍵值後，將資料分散在不同的機器上。當表格滿了以後，接下來新增的資料會以LRU機制替換掉。由於 memcached通常只是當作緩存系統使用，所以使用memcached的應用程式在寫回較慢的系統時（像是後端的數據庫）需要額外的程序更新memcached內的資料。
memcached具有多種語言的客戶端開發包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。
Redis
Redis是一個高性能的key-value數據庫。redis的出現，很大程度補償了memcached這類keyvalue存儲的不足，在部分場合可以對關係數據庫起到很好的補充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客戶端。
**********************************************************************************************
常用內存數據庫介紹
1. 內存數據庫簡介
一、什麼是內存數據庫
傳統的數據庫管理系統把所有數據都放在磁盤上進行管理，所以稱做磁盤數據庫（DRDB:Disk-Resident Database）。磁盤數據庫需要頻繁地訪問磁盤來進行數據的操作，由於對磁盤讀寫數據的操作一方面要進行磁頭的機械移動，另一方面受到系統調用（通常通過CPU中斷完成，受到CPU時鐘週期的制約）時間的影響，當數據量很大，操作頻繁且複雜時，就會暴露出很多問題。
近年來，內存容量不斷提高，價格不斷下跌，操作系統已經可以支持更大的地址空間（計算機進入了64位時代），同時對數據庫系統實時響應能力要求日益提高，充分利用內存技術提升數據庫性能成爲一個熱點。
在數據庫技術中，目前主要有兩種方法來使用大量的內存。一種是在傳統的數據庫中，增大緩衝池，將一個事務所涉及的數據都放在緩衝池中，組織成相應的數據結構來進行查詢和更新處理，也就是常說的共享內存技術，這種方法優化的主要目標是最小化磁盤訪問。另一種就是內存數據庫(MMDB:Main Memory Database，也叫主存數據庫)技術，就是乾脆重新設計一種數據庫管理系統，對查詢處理、併發控制與恢復的算法和數據結構進行重新設計，以更有效地使用CPU週期和內存，這種技術近乎把整個數據庫放進內存中，因而會產生一些根本性的變化。兩種技術的區別如下表：
內存數據庫系統帶來的優越性能不僅僅在於對內存讀寫比對磁盤讀寫快上，更重要的是，從根本上拋棄了磁盤數據管理的許多傳統方式，基於全部數據都在內存中管理進行了新的體系結構的設計，並且在數據緩存、快速算法、並行操作方面也進行了相應的改進，從而使數據處理速度一般比傳統數據庫的數據處理速度快很多，一般都在10倍以上，理想情況甚至可以達到1000倍。
而使用共享內存技術的實時系統和使用內存數據庫相比有很多不足，由於優化的目標仍然集中在最小化磁盤訪問上，很難滿足完整的數據庫管理的要求，設計的非標準化和軟件的專用性造成可伸縮性、可用性和系統的效率都非常低，對於快速部署和簡化維護都是不利的。
2. 內存數據庫歷史和發展
一、雛形期
從上個世紀60年代末到80年代初。在這個時期中，出現了主存數據庫的雛形。1969年IBM公司研製了世界上最早的數據庫管理系統------基於層次模型的數據庫管理系統IMS，並作爲商品化軟件投入市場。在設計IMS時，IBM考慮到基於內存的數據管理方法，相應推出了IMS/VS Fast Path。Fast Path是一個支持內存駐留數據的商業化數據庫，但它同時也可以很好地支持磁盤駐留數據。在這個產品中體現了主存數據庫的主要設計思想，也就是將需要頻繁訪問，要求高響應速度的數據直接存放在物理內存中訪問和管理。在這個階段中，包括網狀數據庫、關係數據庫等其他各種數據庫技術也都逐漸成型。
二、技術理論成熟期
1984年，D J DeWitt等人發表了《主存數據庫系統的實現技術》一文。第一次提出了Main Memory Database（主存數據庫）的概念。預言當時異常昂貴的計算機主存價格一定會下降，用戶有可能將大容量的數據庫全部保存在主存中，提出了AVL樹、哈希算法、主存數據庫恢復機制等主存數據庫技術的關鍵理論，爲主存數據庫的發展指出了明確的方向 。
1984年，D J DeWitt等人提出使用非易逝內存或預提交和成組提交技術作爲主存數據庫的提交處理方案，使用指針實現主存數據庫的存取訪問。
1985年，IBM推出了IBM 370上運行的OBE主存數據庫
1986年，RB Hagman提出了使用檢查點技術實現主存數據庫的恢復機制。威斯康星大學提出了按區雙向鎖定模式解決主存數據庫中的併發控制問題。並設計出MM-DBMS主存數據庫。貝爾實驗室推出了DALI主存數據庫模型。
1987年，ACM SIGMOD會議中提出了以堆文件（HEAP FILE）作爲主存數據庫的數據存儲結構。Southern Methodist大學設計出MARS主存數據庫模型。
1988年普林斯頓大學設計出TPK主存數據庫。
1990年普林斯頓大學又設計出System M主存數據庫。
三、產品發展期和市場成長期
隨着互聯網的發展，越來越多的網絡應用系統需要能夠支持大用戶量併發訪問、高響應速度的的數據庫系統，主存數據庫市場成熟
半導體技術快速發展，半導體內存大規模生產，動態隨機存取存儲器（DRAM）的容量越來越大，而價格越來越低，這無疑爲計算機內存的不斷擴大提供了硬件基礎，使得主存數據庫的技術可行性逐步成熟
1994年美國OSE公司推出了第一個商業化的，開始實際應用的主存數據庫產品Polyhedra
1998年德國SoftwareAG推出了Tamino Database。
1999年日本UBIT會社開發出XDB主存數據庫產品。韓國Altibase推出Altibase
2000年奧地利的QuiLogic公司推出了SQL-IMDB
2001年美國McObject推出eXtremeDB。加拿大Empress公司推出EmpressDB
四、幾種主存技術應用的比較
第一代：用戶定製的主存數據庫。通過應用程序來管理內存和數據；不支持SQL語句, 不提供本地存儲, 沒有數據庫恢復技術；性能好但很難維護和在別的應用中不能使用；應用在實時領域比如工廠自動化生產。
第二代：簡單功能的內存數據庫。能夠快速處理簡單的查詢；支持部分的 SQL語句和簡單的恢復技術；主要目的是能夠快速處理大量事務；針對簡單事務處理領域,尤其是交換機, 移動通信等。
第三代：通用的主存數據庫。針對傳統的商業關係型數據庫領域，能夠提供更高的性能、通用性以及穩定性；提供不同的接口來處理複雜的SQL語句和滿足不同的應用領域；可以應用在計費、電子商務、在線安全領域，幾乎包括磁盤數據庫的所有應用領域。
五、目前幾種常見的通用內存數據庫
eXtremeDB：eXtremeDB實時數據庫是McObject公司的一款特別爲實時與嵌入式系統數據管理而設計的數據庫，只有50K到130K的開銷，速度達到微秒級。eXtremeDB完全駐留在主內存中，不使用文件系統（包括內存盤）。eXtremeDB採用了新的磁盤融合技術，將內存拓展到磁盤，將磁盤當做虛擬內存來用，實時性能保持微秒級的同時，數據管理量在32BIT下能達到20G。
Oracle TimesTen：Oracle TimesTen是Oracle從TimesTen公司收購的一個內存優化的關係數據庫，它爲應用程序提供了實時企業和行業（例如電信、資本市場和國防）所需的即時響應性和非常高的吞吐量。Oracle TimesTen可作爲高速緩存或嵌入式數據庫被部署在應用程序層中，它利用標準的 SQL 接口對完全位於物理內存中的數據存儲區進行操作。
SolidDB：Solid Information Technology 成立於 1992 年，全球總部位於加州Cupertino，
Solid數據管理平臺將基於內存和磁盤的全事務處理數據庫引擎、載體級高可用性及強大的數據複製功能緊密地融爲一體。
ALTIBASE公司從1999年就一直致力於內存數據庫軟件和其應用的開發，提供高性能和高可用性的軟件解決方案。特別適合通信、網上銀行、證券交易、實時應用和嵌入式系統領域。目前佔據80%以上內存數據庫市場，可以說是當今數據庫軟件技術的領導者。目前Altibase在國內成功案例也比較多，尤其是在電信行業，已經得到了廣泛認可.
4. 常用內存數據庫
SQLite是一個小型的C程序庫，實現了獨立的，可嵌入的，零配置的SQL數據庫引擎。特性包括：
- 事務操作是原子，一致，孤立，並且持久的(ACID)，即使在系統崩潰和電源故障之後。
- 零配置——不需要安裝和管理。
- 實現了絕大多數SQL92標準。
- 整個數據庫存儲在一個單一的文件中。
- 數據庫文件可以在不同字節序的機器之間自由地共享。
- 支持最大可達2T的數據庫。 (241 字節)
- 字符串和BLOB類型的大小最大可達 2G 字節(231字節)。
- 小的代碼： 完整配置的少於250KB，忽略一些可選特性的少於150KB。
- 在大多數常見操作上比流行的客戶/服務器數據庫引擎更快。
- 簡單，易於使用的API。
- 內建TCL綁定。 另外提供可用於許多其他語言的綁定。
- 具有良好註釋的源代碼，95%經過測試。
- 獨立：沒有外部依賴。
- 源代碼位於公共域。 可用於任何用途。
SQLite發行版包含一個獨立的命令行訪問程序(sqlite)，可用於管理SQLite數據庫，並適合作爲一個如何使用SQLite庫的例子。
License: SQLite使用Public domain授權（注），對於個人使用和商業使用都是免費的。
技術上的優點和特性
SQLite是一個輕量級、跨平臺的關係型數據庫。
◇輕量級
先說它的第一個特色：輕量級。想必SQLite的作者很看重這個特性，連它的Logo都是用的“羽毛”，來顯擺它的輕飄飄。SQLite和C/S模式的數據庫軟件不同，它是進程內的數據庫引擎，因此不存在數據庫的客戶端和服務器。使用SQLite一般只需要帶上它的一個動態庫，就可以享受它的全部功能。而且那個動態庫的尺寸也挺小，以版本3.6.11爲例，Windows下487KB、Linux下347KB。
◇ 綠色軟件
SQLite的另外一個特點是綠色：它的核心引擎本身不依賴第三方的軟件，使用它也不需要“安裝”。所以在部署的時候能夠省去不少麻煩。
◇單一文件
所謂的“單一文件”，就是數據庫中所有的信息（比如表、視圖、觸發器、等）都包含在一個文件內。這個文件可以copy到其它目錄或其它機器上，也照用不誤。
★技術上的缺點和不足
◇併發訪問的鎖機制
SQLite在併發（包括多進程和多線程）讀寫方面的性能一直不太理想。數據庫可能會被寫操作獨佔，從而導致其它讀寫操作阻塞或出錯。
SQL標準支持不全
在它的官方網站上，具體列舉了不支持哪些SQL92標準。我個人感覺比較不爽的是不支持外鍵約束。
◇網絡文件系統（以下簡稱NFS）
有時候需要訪問其它機器上的SQLite數據庫文件，就會把數據庫文件放置到網絡共享目錄上。這時候你就要小心了。當SQLite文件放置於NFS時，在併發讀寫的情況下可能會出問題（比如數據損壞）。原因據說是由於某些NFS的文件鎖實現上有Bug。
★編程語言接口
SQLite支持很多種語言的編程接口。這對於我這種喜歡混用多種編程語言的人來說，是很爽的。下面我大概介紹一下。
◇C/C++
由於SQLite本身是C寫的，它自帶的API也是C接口的。所以C/C++用起來最直接了。假如你不喜歡面向過程的C API風格，可以另外找個C++的包裝庫。想重新發明輪子的同學，也可以自己包裝一個。
◇Java
如果要用Java訪問SQLite，可以通過SQLite的JDBC驅動，或者通過專門的SQLite包裝庫。我個人建議走JDBC方式，萬一將來要換數據庫，代碼就不用大改。
◇Python
pysqlite是Python操作SQLite的首選。從Python 2.5開始，它已經被整合到Python的標準庫中。看來Python社區還是蠻喜歡SQLite嘛。
◇.Net
對於喜歡.Net的同學，可以通過SQLite的ADO.NET驅動來訪問。
◇Ruby
Ruby可以通過SQLite-Ruby操作SQLite數據庫，不過我沒用過。
◇Perl
在CPAN上有DBD::SQLite，不過我也沒用過。
★一些非技術的參考因素
需要根據“如何選擇開源項目”裏面提到的幾個參考因素，再評估一下。
◇授權協議（License）
SQLite使用的是Public Domain協議，這是最爽一種，可以放心大膽地用。
◇用戶的普及程度
最近這幾年，使用SQLite的人越來越多。包括一些大公司也開始把它整合到產品中（比如Google的Gears、Apple的Safari、Adobe的AIR）。
◇開發的活躍程度
如果到SQLite的Change Log上大致瞭解一下，可以看出最近5年基本上每1-2個月都會有更新。說明開發的活躍度還是非常高的。
SQLite不同於其他大部分的SQL數據庫引擎,因爲它的首要設計目標就是簡單化:
- 易於管理
- 易於使用
- 易於嵌入其他大型程序
- 易於維護和配置
許多人喜歡SQLite因爲它的小巧和快速. 但是這些特性只是它的部分優點, 使用者還會發現SQLite是非常穩定的. 出色的穩定性源於它的簡單, 越簡單就越不容易出錯. 除了上述的簡單、小巧和穩定性外, 最重要的在於SQLite力爭做到簡單化.
簡單化在一個數據庫引擎中可以說是一個優點, 但也可能是個缺點, 主要決定於你想要做什麼. 爲了達到簡單化, SQLite省略了一些人們認爲比較有用的特性, 例如高併發性、 嚴格的存取控制、豐富的內置功能、 存儲過程、複雜的SQL語言特性、 XML以及Java的擴展, 超大的萬億級別的數據測量等等. 如果你需要使用上述的這些特性並且不介意它們的複雜性, 那麼SQLite也許就不適合你了. SQLite沒有打算作爲一個企業級的數據庫引擎, 也並不打算和Oracle或者PostgreSQL競爭.
僅憑經驗來說SQLite適用於以下場合: 當你更看中簡單的管理、使用和維護數據庫, 而不是那些企業級數據庫提供的不計其數的複雜功能的時候，使用SQLite是一個比較明智的選擇. 事實也證明, 人們在許多情況下已經清楚的認識到簡單就是最好的選擇.
· 網站
作爲數據庫引擎SQLite適用於中小規模流量的網站(也就是說, 99.9%的網站). SQLite可以處理多少網站流量在於網站的數據庫有多大的壓力. 通常來說, 如果一個網站的點擊率少於100000次/天的話, SQLite是可以正常運行的. 100000次/天是一個保守的估計, 不是一個準確的上限. 事實證明, 即使是10倍的上述流量的情況下SQLite依然可以正常運行.
· 嵌入式設備和應用軟件
因爲SQLite數據庫幾乎不需要管理, 因此對於那些無人值守運行或無人工技術支持的設備或服務, SQLite是一個很好的選擇. SQLite能很好的適用於手機, PDA, 機頂盒, 以及其他儀器. 作爲一個嵌入式數據庫它也能夠很好的應用於客戶端程序.
· 應用程序文件格式
SQLite作爲桌面應用程序的本地磁盤文件格式取得了巨大成功.例如金融分析工具、CAD 包、檔案管理程序等等. 一般的數據庫打開操作需要調用sqlite3_open()函數，並且標記一個顯式本地事務的起始點（BEGIN TRANSACTION）來保證以獨佔的方式得到文件的內容. 文件保存將執行一個提交（COMMIT）同時標記另一個顯式本地事務起始點. 這種事務處理的作用就是保證對於應用程序數據文件的更新是原子的、持久的、獨立的和一致的.
數據庫裏可以加入一些臨時的觸發器,用來把所有的改變記錄在一張臨時的取消/重做日誌表中. 當用戶按下取消/重做按鈕的時候這些改變將可以被回滾. 應用這項技術實現一個無限級的取消/重做功能只需要編寫很少的代碼.
· 替代某些特別的文件格式
許多程序使用fopen(), fread(), 或 fwrite()函數創建和管理一些自定義的文件用來保存數據. 使用SQLite替代這些自定義的文件格式將是一種很好的選擇.
· 內部的或臨時的數據庫
對於那些有大量的數據需要用不同的方式篩選分類的程序, 相對於編寫同樣功能的代碼, 如果你把數據讀入一個內存中的SQLite數據庫, 然後使用連接查詢和ORDER BY子句按一定的順序和排列提取需要的數據, 通常會更簡單和快速. 按照上述的方法使用內嵌的SQLite數據庫將會使程序更富有靈活性, 因爲添加新的列或索引不用重寫任何查詢語句.
· 命令行數據集分析工具
有經驗的SQL用戶可以使用SQLite命令行程序去分析各種混雜的數據集. 原是數據可以從CSV（逗號分隔值文件）文件中導入, 然後被切分產生無數的綜合數據報告. 可能得用法包括網站日誌分析, 運動統計分析, 編輯規劃標準, 分析試驗結果.
當然你也可以用企業級的客戶端/服務器數據庫來做同樣的事情. 在這種情況下使用SQLite的好處是: SQLite的部署更爲簡單並且結果數據庫是一個單獨的文件, 你可以把它存儲在軟盤或者優盤或者直接通過email發給同事.
· 在Demo或測試版的時候作爲企業級數據庫的替代品
如果你正在編寫一個使用企業級數據庫引擎的客戶端程序, 使用一個允許你連接不同SQL數據庫引擎的通用型數據庫後臺將是很有意義的. 其更大的意義在於將SQLite數據庫引擎靜態的連接到客戶端程序當中，從而內嵌SQLite作爲混合的數據庫支持. 這樣客戶端程序就可以使用SQLite數據庫文件做獨立的測試或者驗證.
· 數據庫教學
因爲SQLite的安裝和使用非常的簡單(安裝過程幾乎忽略不計, 只需要拷貝SQLite源代碼或sqlite.exe可執行文件到目標主機, 然後直接運行就可以) 所以它非常適合用來講解SQL語句. 同學們可以非常簡單的創建他們喜歡的數據庫, 然後通過電子郵件發給老師批註或打分. 對於那些感興趣怎樣實現一個關係型數據庫管理系統（RDBMS）的高層次的學生, 按照模塊化設計且擁有很好的註釋和文檔的SQLite源代碼, 將爲他們打下良好的基礎. 這並不是說SQLite就是如何實現其他數據庫引擎的精確模型, 但是很適合學生們瞭解SQLite是如何快速工作的, 從而掌握其他數據庫系統的設計實現原則.
· 試驗SQL語言的擴展
SQLite簡單且模塊化的設計使得它可以成爲一個用來測試數據庫語言特性或新想法的優秀的原型平臺
4.1.2 哪些場合適合使用其他的關係型數據庫管理系統（RDBMS）
· 客戶端/服務器程序
如果你有許多的客戶端程序要通過網絡訪問一個共享的數據庫, 你應當考慮用一個客戶端/服務器數據庫來替代SQLite. SQLite可以通過網絡文件系統工作, 但是因爲和大多數網絡文件系統都存在延時, 因此執行效率不會很高. 此外大多數網絡文件系統在實現文件邏輯鎖的方面都存在着bug(包括Unix 和windows). 如果文件鎖沒有正常的工作, 就可能出現在同一時間兩個或更多的客戶端程序更改同一個數據庫的同一部分, 從而導致數據庫出錯. 因爲這些問題是文件系統執行的時候本質上存在的bug, 因此SQLite沒有辦法避免它們.
好的經驗告訴我們, 應該避免在許多計算機需要通過一個網絡文件系統同時訪問同一個數據庫的情況下使用SQLite.
· 高流量網站
SQLite通常情況下用作一個網站的後臺數據庫可以很好的工作. 但是如果你的網站的訪問量大到你開始考慮採取分佈式的數據庫部署, 那麼你應當毫不猶豫的考慮用一個企業級的客戶端/服務器數據庫來替代SQLite.
· 超大的數據集
當你在SQLite中開始一個事務處理的時候(事務處理會在任何寫操作發生之前產生, 而不是必須要顯示的調用BEGIN...COMMIT), 數據庫引擎將不得不分配一小塊髒頁(文件緩衝頁面)來幫助它自己管理回滾操作. 每1MB的數據庫文件SQLite需要256字節. 對於小型的數據庫這些空間不算什麼, 但是當數據庫增長到數十億字節的時候, 緩衝頁面的尺寸就會相當的大了. 如果你需要存儲或修改幾十GB的數據, 你應該考慮用其他的數據庫引擎.
· 高併發訪問
SQLite對於整個數據庫文件進行讀取/寫入鎖定. 這意味着如果任何進程讀取了數據庫中的某一部分, 其他所有進程都不能再對該數據庫的任何部分進行寫入操作. 同樣的, 如果任何一個進程在對數據庫進行寫入操作, 其他所有進程都不能再讀取該數據庫的任何部分. 對於大多數情況這不算是什麼問題. 在這些情況下每個程序使用數據庫的時間都很短暫, 並且不會獨佔, 這樣鎖定至多會存在十幾毫秒. 但是如果有些程序需要高併發, 那麼這些程序就需要尋找其他的解決方案了.
|
方面 |
具體要求 |
必要條件 |
詳細描述 |
|
License |
是否收費 |
|
免費使用 |
|
是否開源 |
|
開源 |
|
|
是否有技術支持 |
|
主要是社區支持，如果需要專業支持需要購買 |
|
|
商業目的的分發版本是否仍要收費 |
是 |
免費 |
|
|
其他 |
|
|
|
|
性能 |
數據容量支持100000條以上記錄 |
是 |
支持 |
|
併發查詢處理能力 |
|
SQLite在併發（包括多進程和多線程）讀寫方面的性能一直不太理想。數據庫可能會被寫操作獨佔，從而導致其它讀寫操作阻塞或出錯。 |
|
|
查詢速度 |
是 |
|
|
|
修改速度 |
是 |
|
|
|
平臺支持 |
32/64位 |
|
全部支持 |
|
Linux/window/UNIX/mobile |
|
支持Linux/Mac OS/Windows |
|
|
運行方式支持 |
支持嵌入式 |
|
支持 |
|
支持獨立運行 |
|
不支持 |
|
|
連接方式支持 |
支持ODBC |
|
默認不支持，必須通過第三方的ODBC驅動 |
|
支持JDBC |
|
默認不支持，必須通過第三方的JDBC驅動 |
|
|
支持內存訪問 |
|
通過c接口（專用API） |
|
|
支持網絡訪問 |
|
不支持 |
|
|
SQL支持 |
支持SQL |
是 |
支持 |
|
支持Index，Trigger， Constrains，Views |
|
支持，有資料說其不支持外鍵約束。 |
|
|
管理界面 |
支持管理界面 |
|
支持CLI |
|
管理界面友好程度 |
|
較差 |
Altibase™內存數據庫管理系統（DBMS），內存數據管理系統的最新技術，是一個在事務優先的環境中提供高性能和高可用性的軟件解決方案。Altibase提供極限性能、容錯能力和事務管理的方便性，特別是在通信、網上銀行、證券交易、實時應用和嵌入式系統領域。Altibase能夠最大限度的發揮數據庫服務系統的潛力，使用Altibase能大大增強您公司的數據服務器的處理能力。
Altibase™內存DBMS爲需要容錯服務的系統提供實時數據庫複製的功能。採用Altibase數據庫複製的系統可以實現高性能、高可用性、數據庫一致性、負載平衡和系統可伸縮性。如果您希望您的業務能夠實現最大的成功，請在您的事務優先的系統中使用我們的Altibase數據庫複製解決方案。
資料比較少，且需要商業License，沒有詳細去研究
4.3 Oracle 內存數據庫系列 Berkeley DB 和 TimesTen
Oracle是最重要的商業數據庫產品提供商，它也有內存數據庫的產品系列：主要就是Oracle Berkeley DB 和 Times Ten.前者是隻支持嵌入式內存數據，後者是獨立的內存優化數據庫。
Oracle Berkeley DB是Oracle 收購了開源數據庫廠商後推出的產品，其前身是Berkeley DB。它有開源版本，但且對於開源軟件免費。商業版本是要付費。
Oracle Berkeley DB 系列的可嵌入開源數據庫爲開發人員提供了無需管理的快速、可靠的本地持久性。Oracle Berkeley DB 系列通常部署爲“前沿”數據庫，爲不需要 SQL 的應用程序用例提供很高的性能、可靠性、可伸縮性以及可用性。
Oracle Berkeley DB 產品系列
— Berkeley DB — 事務處理式存儲引擎，用於基本鍵/值數據結構中的非類型化數據 — 新增！版本 4.7 現已推出
— 針對 Java 環境優化的純 Java 版 Berkeley DB — 新增！版本 3.3
— Berkeley DB XML — 原生 XML 數據庫，可基於 XQuery 訪問容器中存儲的文檔，並根據其內容進行索引 — 新增！版本 2.4 現已推出
Oracle 內存數據庫 TimesTen 是一個針對內存進行了優化的關係數據庫，它爲應用程序提供了當今實時企業和行業（如電信、資本市場和國防）所需的即時響應性和非常高的吞吐量。Oracle 內存數據庫 TimesTen 作爲獨立或嵌入式數據庫部署在應用層中，利用標準的 SQL 接口對完全位於物理內存中的數據庫進行操作。它也可以用作 Oracle 數據庫的內存中數據庫緩存，以改進用戶應用程序的響應時間和吞吐量。
eXtremeDB內存式實時數據庫是爲實時系統及嵌入式系統而特別設計的數據庫。與同類產品不同，eXtremeDB不是通過 對企業數據庫面向實時嵌入式應用進行剪裁而來；而是總結了30年來McObject公司在編譯器、實時編程、數據管理、內核級驅 動軟件等領域的經驗，面向實時嵌入式應用從頭開發的最新實時數據管理技術。
eXtremeDB滿足了您對實時數據庫的一切期待：高級數據定義語言、並行訪問、基於交易及靈活的索引… …等等。不僅如此，出乎您的意外，eXtremeDB在緊湊的引擎中還提供諸如事件觸發、目標歷史等等功能。
eXtremeDB嵌入式數據庫滿足更多的實時開發的要求。
· 最快的內存數據庫。
· 多種索引支持
· 高可用性-組合選項
· 非常靈活的數據存儲： 內存式，磁盤式或混合式
· 多種應用接口： 兩種 SQL， 兩種更快的原始接口
· 幾乎牢不可破 -
又一個商業內存數據庫產品，這個特點是實時數據庫，號稱最快。
4.5 H2 Database
h2是Thomas Mueller提供的一個開源的、純java實現的關係數據庫，官方網站：http://www.h2database.com/html/main.html。
它的主要特性是：
- 非常速的數據庫引擎
- 開源、免費數據庫
- 支持 JDBC和ODBC API，支持SQL
- 支持嵌入式，服務器和集羣模式。支持內存數據庫。
- 提供基於瀏覽器的管理控制檯
- 整個應用本身只有1MB左右。
其他特性還包括
- 基於磁盤或內存的數據庫、表，支持只讀數據庫、臨時表。
- 兩段式事務支持
- 支持多個連接。表級別的鎖。
- 基於成本的優化，爲複雜查詢使用遺傳算法，零管理。
- 滾動的、可修改的result set支持。支持大結果集、外部結果排序。
- 加密數據庫（AES或XTEA）,SHA-256密碼加密。
性能比較（摘自h2database網站）
|
Test Case |
Unit |
H2 |
HSQLDB |
Derby |
|
Simple: Init |
ms |
610 |
657 |
3187 |
|
Simple: Query (random) |
ms |
297 |
312 |
1828 |
|
Simple: Query (sequential) |
ms |
203 |
266 |
1766 |
|
Simple: Update (random) |
ms |
1078 |
1484 |
22031 |
|
Simple: Delete (sequential) |
ms |
234 |
281 |
7407 |
|
Simple: Memory Usage |
MB |
6 |
7 |
11 |
|
BenchA: Init |
ms |
859 |
438 |
4047 |
|
BenchA: Transactions |
ms |
5266 |
2875 |
17500 |
|
BenchA: Memory Usage |
MB |
9 |
14 |
10 |
|
BenchB: Init |
ms |
4016 |
2687 |
16875 |
|
BenchB: Transactions |
ms |
2609 |
3282 |
4250 |
|
BenchB: Memory Usage |
MB |
9 |
10 |
8 |
|
BenchC: Init |
ms |
891 |
594 |
5766 |
|
BenchC: Transactions |
ms |
4359 |
75438 |
11718 |
|
BenchC: Memory Usage |
MB |
9 |
18 |
9 |
|
Executed statements |
# |
594255 |
594255 |
594255 |
|
Total time |
ms |
20422 |
88314 |
96375 |
|
Statements per second |
# |
29098 |
6728 |
6166 |
-
- 嵌入式應用。有一個項目在爲.Net使用H2，使用CLI重新編譯H2。還沒有深入關注。
- ODBC。但性能一般。
包括Derby, HSQLDB等.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
In-memory database in wikipedia: (http://en.wikipedia.org/wiki/In-memory_database)
Products
Product name |
License |
Description |
|---|---|---|
| Adaptive Server Enterprise (ASE) 15.5 | Proprietary | enterprise database from Sybase)[4] |
| Apache Derby | Apache License 2.0 | Java RDBMS |
| Altibase | Proprietary | has in-memory and disk table; HYBRID DBMS |
| BlackRay | GNU General Public Licence (GPLv2) and BSD License | |
| CSQL | GNU General Public Licence or proprietary | |
| Datablitz | Proprietary | DBMS |
| Eloquera | Proprietary | In-memory, In-memory:persist modes |
| eXtremeDB | commercial product | DBMS, also check out its open source PERST dbms. |
| FleetDB | MIT | NOSQL db with Writing to an append-only log to provide durability. |
| H2 | Mozilla Public License or Eclipse Public License | has a memory-only mode |
| HSQLDB | BSD license | has a memory-only mode |
| IBM TM1 | Proprietary | in-memory BI and data analysis |
| InfoZoom | Proprietary | in-memory BI and data analysis |
| KDB | Proprietary | DBMS, also supports disk based data |
| membase | Apache License | NoSQL, hybrid |
| MicroStrategy | in-memory BI for MicroStrategy 9 | |
| MonetDB | MonetDB License | |
| MySQL | GNU General Public License or proprietary | has a cluster server which uses a main-memory storage engine |
| Oracle Berkeley DB | Sleepycat License | can be configured to run in memory only |
| Panorama | for Windows and Macintosh, both single user and server versions | |
| ParAccel | Proprietary | in-memory, columnar, relational, ACID-compliant; disk-based mode as well |
| Polyhedra IMDB | Proprietary | relational, supports High-Availability; acquired in 2001 by ENEA |
| QlikView | BI-tool developed by QlikTech | |
| RDM Embedded | Proprietary | including hybrid |
| RDM Server | Proprietary | including hybrid |
| Redis | BSD | NoSQL |
| solidDB by IBM | including hybrid, HSB-based HA, Shared memory, embedded, XA, etc. | |
| SAP HANA database | Proprietary | Database engine of the SAP In-Memory Appliance (SAP HANA) produced by SAP AG |
| SQLite | Public domain | hybrid, RAM and disk dbs can be used together |
| Starcounter | in-memory object relational dbms | |
| TimesTen by Oracle | in memory only or as a cache for Oracle Database | |
| Vertipaq | Proprietary | Microsoft PowerPivot and Microsoft Analysis Services in-memory BI engine |
| VoltDB | GNU General Public License v3 | in-memory |
| TREX | search engine in the SAP NetWeaver integrated technology platform produced by SAP AG | |
| Xcelerix by Frontex | commercial product |
*****************************************************************************************
內存數據庫技術選型
最近一段時間研究了內存數據庫，總結了一下，分享給大家。我們先從應用場景說起。
一. 內存數據庫的應用場景
- 數據緩存：將經常使用的數據存放在內存中，全局共享，減少和數據庫之間的交互頻率，提升數據訪問速度，主要用於應用程序全局共享緩存。
- 內存計算：支持通過標準SQL或者LINQ的方式實現對內存數據的聚合、計算和查詢，充分發揮、利用應用服務器的資源。
二. 業界有哪幾類主流的內存數據庫
1. 關係型內存數據庫
- 傳統關係型數據庫場景下，應用層的數據緩存
- 將傳統的關係型數據庫表搬到內存中，內存數據和數據庫數據之間進行結構映射
- 支持通過SQL語句的方式實現對內存數據的訪問，更加貼合業務實現
- 將經常使用的數據存放在內存中，減少和數據庫之間的交互頻率，提升數據訪問速度
- 數據實時/定時同步
- 有限的事務保證
2. 鍵值對內存數據庫
- 鍵值對存儲結構
- 按Key進行數據讀取
- Value支持各種數據類型
- 類似Redis
3. 傳統數據庫的內存數據庫引擎
- SQL Server 2016 In Memory OLTP
- MySQL Memory Engine
- 在數據庫層面提供了內存數據庫引擎機制，最大程度的減少磁盤IO
- 數據類型有一定的限制
- 事務支持
- 數據持久化保證
還有Oracle 的Timesten、SAP的HANA等，這些商業中間件不在我們研究的範圍之內。
那麼，傳統數據庫和內存數據庫之間是什麼關係？ 相互補充、珠聯璧合的關係
內存數據庫不會獨立於傳統數據庫而單獨存在，因爲內存是易失的。現在具有持久化功能的內存庫，如redis、couchbase等，其持久化功能相較傳統數據庫還較溥弱，持久化性能也不如傳統數據庫。因此，內存數據庫在一段時期內，將是傳統數據庫的一種強有力的補充。
如果說傳統數據庫是一支軍隊，那麼內存數據庫就是爲執行某種特殊任務的特種部隊，不要求功能多，但一定要快速、迅猛。
我們繼續一一對比分析一下上面所述的幾類內存數據庫。
三. 業界主流的內存數據庫
1. SQL Server 2016 In-Memory OLTP
SQL Server 2016的In-Memory OLTP，通俗地講，是內存數據庫，使用內存優化表（Memory-Optimized Table，簡稱MOT）來實現，MOT駐留在內存中，使用 Hekaton 內存數據庫引擎訪問。在查詢MOT時，只從內存中讀取數據行，不會產生Disk IO消耗；在更新MOT時，數據的更新直接寫入到內存中。內存優化表能夠在Disk上維護一個數據副本，該副本只用於持久化數據，不用於數據讀寫操作。
在內存數據庫中，不是所有的數據都需要存儲在內存中，有些數據仍然能夠存儲在Disk上，硬盤表（Disk-Based Table，簡稱DBT）是傳統的表存儲結構，每個Page是8KB，在查詢和更新DBT時，產生Disk IO操作，將數據從Disk讀取到內存，或者將數據更新異步寫入到Disk中。
內存數據庫將原本存儲在Disk上的數據，存儲在內存中，利用內存的高速訪問優勢實現數據的快速查詢和更新，但是，內存數據庫，不僅僅是存儲空間的變化，Hekaton 內存數據庫訪問引擎實現本地編譯模塊（Natively compiled），交叉事務（Cross-Container Transaction）和查詢互操作（Query Interop）：
本地編譯模塊：如果代碼模塊只訪問MOT，那麼可以將該模塊定義爲本地編譯模塊，SQL Server直接將TSQL腳本編譯成機器代碼；SQL Server 2016支持本地編譯的模式有：存儲過程（SP），觸發器（Trigger），標量值函數（Scalar Function）或內嵌多語句函數（Inline Multi-Statement Function）。相比於解釋性（Interpreted）TSQL 模塊，機器代碼直接使用內存地址，性能更高。
交叉事務：在解釋性TSQL模塊中，一個事務既能訪問硬盤表，也能訪問內存優化表；實際上，SQL Server創建了兩個事務，一個事務用於訪問硬盤表，一個事務用於訪問內存優化表，在DMV中，分別使用transaction_id 和 xtp_transaction_id 來標識。
查詢互操作：解釋性TSQL腳本能夠訪問內存優化表和硬盤表，本地編譯模塊只能訪問內存優化表。
內存數據被整合到SQL Server關係引擎中，使用內存數據庫時，客戶端應用程序甚至感受不到任何變化，DAL接口也不需要做任何修改。由於Query Interop的存在，任何解釋性TSQL腳本都能透明地訪問MOT，只是性能沒有本地編譯TSQL腳本性能高。在使用分佈式事務訪問MOT時，必須設置合適的事務隔離級別，推薦使用Read Committed，如果發生MSSQLSERVER_41333 錯誤，說明產生交叉事務隔離錯誤（CROSS_CONTAINER_ISOLATION_FAILURE），原因是當前事務的隔離級別太高。
2. Apache Ignite
Apache Ignite是一個內存數據組織是高性能的、集成化的以及分佈式的內存平臺，他可以實時地在大數據集中執行事務和計算，和傳統的基於磁盤或者閃存的技術相比，性能有數量級的提升。
可以將Ignite視爲一個獨立的、易於集成的內存組件的集合，目的是改進應用程序的性能和可擴展性。
Data Grid：Ignite內存數據網格是一個內存內的鍵值存儲，他可以在分佈式集羣的內存內緩存數據。 它通過強語義的數據位置和關係數據路由，來降低冗餘數據的噪聲，使其可以節點數的線性增長，直至幾百個節點。 Ignite數據網格速度足夠快，經過官方不斷的測試，目前，他是分佈式集羣中支持事務性或原子性數據的最快的實現之一。
SQL Grid：內存SQL網格爲Apache Ignite提供了分佈式內存數據庫的功能，它水平可擴展，容錯並且兼容SQL的ANSI-99標準。 SQL網格支持完整的DML命令，包括SELECT, UPDATE, INSERT, MERGE以及DELETE。 同時支持分佈式SQL Join關聯
RDBMS集成： Ignite支持與各種持久化存儲的集成，它可以連接數據庫，導入模式，配置索引類型，以及自動生成所有必要的XML OR映射配置和Java領域模型POJO，這些都可以輕易地下載和複製進自己的工程。 Ignite可以與任何支持JDBC驅動的關係數據庫集成，包括Oracle、PostgreSQL、MS SQL Server和MySQL。
彙總一下，Apache Ignite的功能特性：
- 分佈式鍵值存儲：Ignite數據網格是一個內存內的鍵值存儲，分佈式的分區化的哈希，集羣中每個節點都持有所有數據的一部分，這意味着集羣內節點越多，就可以緩存的數據越多。 Ignite通過可插拔的哈選算法來決定數據的位置，每個客戶端都可以通過插入一個自定義的哈希函數來決定一個鍵屬於那個節點，並不需要任何特殊的映射服務或者命名節點。
- 內存優化：Ignite在內存中支持2種模式的數據緩存，堆內和堆外。當緩存數據佔用很大的堆，超過了Java主堆空間時，堆外存儲可以克服JVM垃圾回收(gc)導致的長時間暫停，但數據仍然在內存內。
- SQL查詢：Ignite支持使用標準的SQL語法（ANSI 99）來查詢緩存，可以使用任何的SQL函數，包括聚合和分組。
- 分佈式關聯：Ignite支持分佈式的SQL關聯和跨緩存的關聯。
- ACID事務：Ignite提供了一個完全符合ACID的分佈式事務來保證一致性。 支持樂觀和悲觀的併發模型以及讀提交、可複製讀和序列化的隔離級別。 Ignite的事務使用了二階段提交協議，適當地也進行了很多一階段提交的優化。
- 同寫和同讀：通寫模式允許更新數據庫中的數據，通讀模式允許從數據庫中讀取數據。
- 數據庫異步更新：Ignite提供了一個選項，通過後寫緩存來異步地執行數據庫更新
- 自動持久化：自動化地連接底層數據庫並且生成XML的對象關係映射配置和Java領域模型POJO
- 數據庫支持：Ignite可以自動地與外部數據庫集成，包括RDBMS、NoSQL和HDFS。
從以上的Apache Ignite的特性看，它就是一個關係型的內存數據庫。貌似在這個領域，Apache Ignite做的非常好。這一點非常符合我們技術選型的需要！一句話：
可以像操作數據庫一樣，操作內存緩存！
3. FastDB
FastDb是高效的關係型內存數據庫系統，具備實時能力及便利的C++接口。FastDB針對應用程序通過控制讀訪問模式作了優化。通過降低數據傳輸的開銷和非常有效的鎖機制提供了高速的查詢。對每一個使用數據庫的應用數據庫文件被影射到虛擬內存空間中。因此查詢在應用的上下文中執行而不需要切換上下文以及數據傳輸。Fastdb中併發訪問數據庫的同步機制通過原子指令實現，幾乎不增加查詢的開銷。
FastDB的特點：
- FastDB不支持client-server架構因而所有使用FastDB的應用程序必須運行在同一主機上；
- fastdb假定整個數據庫存在於RAM中，並且依據這個假定優化了查詢算法和接口。
- fastdb沒有數據庫緩衝管理開銷，不需要在數據庫文件和緩衝池之間傳輸數據。
- 整個fastdb的搜索算法和結構是建立在假定所有的數據都存在於內存中的，因此數據換出的效率不會很高。
- Fastdb支持事務、在線備份以及系統崩潰後的自動恢復。
- fastdb是一個面向應用的數據庫，數據庫表通過應用程序的類信息來構造。
缺點：
- FastDB在接口上僅支持C++，GitHub有個人版的C# SDK https://github.com/gavioto/fastdb/tree/master/CSharp
- 有限的SQL語法支持
- 個人版開源系統，沒有商業支持，未經生產環境驗證
4. Redis&Memcached
Redis和Memcached，從本質上看，都屬於Key-Value內存數據庫，Redis無論從穩定性、性能和功能上都要強於MemCached。
NoSQL結構設計，不支持關係型數據結構。
Redis我們已經大規模應用了，本次技術選型的重要在於關係型內存數據庫上，所以，Redis和MemCached不作深入研究和討論。
初步的選型總結：
從需求和功能滿足度上看：Apache Ignite 最滿足我們的需求，從Apache Ignite的特性看，它就是一個關係型的內存數據庫。貌似在這個領域，Apache Ignite做的非常好。這一點非常符合我們技術選型的需要！一句話：
可以像操作數據庫一樣，操作內存緩存！
先放出兩張圖給大家：
下一篇文章，將對Apache Ignite做一個深入的技術原型驗證和分享。
同時，大家如果有更好的內存數據庫，可以推薦給我們。謝謝。
*************************************************************************************************************************
MySQL/HandlerSocket和VoltDB：NoSQL的競爭者
一般認爲NoSQL數據庫在性能方面要優於傳統的SQL數據庫。但是有兩個SQL的解決方案宣佈：對於大型系統的高可擴展性需求，SQL仍然是可行的解決方案！這兩個SQL解決方案分別是MySQL加NoSQL層插件和支持SQL的VoltDB數據庫。
MySQL + HandlerSocket
Yoshinori Matsunobu是Sun/Oracle的前僱員，從事MySQL的研發工作，目前是DeNA的首席數據庫和基礎設施架構師，他以插件的方式爲MySQL/InnoDB提供解決方案，可以在一臺2.53GHZ、8核CPU、32G內存的Nehalem服務器上把每秒的查詢數量（qps）提升到750,000以上。在同樣的硬件環境下，無插件的MySQL只能提供100,000左右的qps，如果使用memecached的話，可以增加到大約400,000。經過對RDBMS的分析，Matsunobu意識到大部分時間都花在SQL的開銷上，比如調用MYSQLparse()、MYSQLlex()、make_join_statistics()和JOIN::optimize()等。他寫到：
很顯然性能降低的原因主要在SQL層，而不是“InnoDB（存儲）”層。MySQL必須做很多事情......但memcached/NoSQL是不需要做這些額外工作的。
SQL層的功能包括解析SQL語句、打開/鎖定/解鎖/關閉表、解決併發問題等。Matsunobu的解決方案就是增加額外的NoSQL層：
我們認爲最好的方式就是在MySQL內部實現一個NoSQL的網絡服務器。也就是說，編寫一個網絡服務器作爲MySQL的插件（守護插件），用來監聽特定端口，接收NoSQL的協議和API，然後通過MySQL內部存儲引擎API直接訪問InnoDB。這種方式很像NDBAPI，不同的是它可以與InnoDB交互。
他的團隊開發了HandlerSocket插件，有了這個插件，MySQL更像一個NoSQL數據庫，通過監聽一個獨立的端口，接收從SQL層來的簡單查詢請求，例如主鍵查詢，索引掃描和插入/更新/刪除。這一變化把數據庫性能提升到了750K qps以上。常用端口可以接收處理複雜查詢，其核心仍然是SQL數據庫。DeNA採用SQL/NoSQL混合的方式取得了成功，據Matsunobu所言，在相同的時間內，這種解決方案把多個memcached和MySQL主從服務器的方案遠遠甩在了後面。
VoltDB
另一個很有希望的SQL解決方案是VoltDB，這是一個內存中的開源OLTP SQL數據庫，能夠保證事務的完整性（ACID）。VoltDB是由原Ingres和Postgres的架構師Mike Stonebraker設計的。該數據庫主要特徵如下：
爲了獲得最大化吞吐量，數據保存在內存中（而不是在硬盤），這樣可以有效消除緩衝區管理。
VoltDB通過SQL引擎把數據分發給集羣服務器的每個CPU進行處理。
每個單線程分區自主執行，消除鎖定和閂鎖的需求。
VoltDB可以通過簡單的在集羣中增加附加節點的方式實現性能的線性增加。
正如其開發者宣稱的那樣，該數據庫的性能使其成爲NoSQL解決方案的有力競爭者：
VoltDB在單節點上可以每秒處理53000個事務請求（TPS），其他DBMS在相同的硬件環境下只能處理1155個。VoltDB的擴展是近似線性的──在12個節點的VoltDB集羣上進行同樣測試，可以處理560,000 TPS。
基準案例：某個客戶的在線遊戲在12個節點的VoltDB集羣上處理了130萬 TPS。
VoltDB還針對NoSQL的鍵-值存儲方式作了基準測試，VoltDB在處理各種鍵-值存儲負載的情況下獲得了相同或更好的性能。
除了它的性能，VoltDB的主要優勢是可以與SQL用戶進行交流，這些SQL用戶是很好的資源。
近期還會推出VoltDB的企業版本，包括基於瀏覽器的數據庫管理系統，提供、管理和監控數據庫集羣。除了免費的社區版本，針對企業版的支持也開始了。
應用網址：http://www.infoq.com/cn/news/2010/11/MySQL-HandlerSocket-VoltDB
查看英文原文：MySQL/HandlerSocket and VoltDB: Contenders to NoSQL
******************************************************************************************************
VoltDB內存數據庫分析
引子
VoltDB是一個宣稱性能超過Mysql 100倍的新型數據庫。它源自Micheal Stonebraker一篇論文H-Store。在這篇論文發表後，Stonebraker成立了VoltDB公司帶着他的一些學生開始在OLTP數據庫領域打拼。Stonebraker從上世紀70年代——數據庫剛開始發展的時間——就開始在數據庫領域活躍，這樣的老古董提出的數據庫的新想法，給了整個存儲領域很大的想象空間。
VoltDB源起於應用領域與硬件發展翻天覆地的變化。用戶的使用方法發生了變化，在數據庫開始發展的階段，事務是一個較長的過程，用戶或者管理員可以在"BEGIN TRANSACTION"和"END TRANSACTION"之間慢慢地人工執行整個事務的步驟。但是現在，大部分操作是由Web服務端發起的書寫良好的事務，用戶訪問的是Web服務器，在Web服務器的執行邏輯裏再訪問數據庫，所以即使是很複雜的事務也可以很快執行完。計算機硬件的發展更是一日千里。幾十GB的內存服務器已經很常見。以太網絡也已經步入Gbps時代，而且正在朝向10Gbps方向邁進。基於以太網的集羣的機器價格也降低到比PC機貴不了太多。VoltDB的設計充分利用了這些特點，數據主要存儲在內存中，Shared Nothing的集羣結構，單機是單線程處理事務，不是用鎖而是基於Optimistic的方法處理事務併發，所有的事務必須以存儲過程形式先提交到VoltDB系統。下面分開來說。
VoltDB的數據主要存儲在內存中，Shared Nothing的集羣結構，單機是單線程處理事務，不是用鎖而是基於Optimistic的方法處理事務併發，所有的事務必須以存儲過程形式先提交到VoltDB系統。
適用場景
VoltDB適合OLTP系統，單個事務較小，但是事務總量非常之多的應用。比如金融，零售，WEB2.0等傳統OLTP應用。不適合進行範圍查詢或者頻繁多表Join這樣的場景。
設計思路
VoltDB通過內存存儲、數據分區和無鎖計算來實現高性能運算。
-
- 內存存儲
VoltDB所有數據都保存在內存中(可靠性中會有數據刷到磁盤，見VoltDB ACID中可靠性設計), 內存存取速度已經比磁盤遠遠高出幾個數量級了，這就是VoltDB高性能的重要原因。 - 數據分區
VoltDB對每個節點的內存進行管理，在每個節點上創建多個分區，所有分區表中的數據，都分散在各個分區中，然後在讀寫的時候，就可以實現多個分區併發進行，所以拓展性是線性提升的。
這種分區機制也會帶來問題，當集羣需要擴容的時候，需要停止整個集羣，然後再進行擴容；當集羣啓動的時候，VoltDB會重新調整數據分佈，在所有數據分佈調整完畢之後，纔開始提供服務。 - 無鎖計算
VoltDB數據分區存放，在執行SQL語句的時候，客戶端就會根據條件自動判斷數據在哪個分區中，然後下發至該分區執行。如果查詢條件中不包含分區列，那麼就會由客戶端進行統一控制，在每個分區上都進行查詢之後，再統一返回結果，這種場景會極大影響性能。
VoltDB的程序都是以存儲過程的方式執行的，支持使用java或者其他語言定義存儲過程。每個分區的存儲過程執行都是單線程線性執行的，這就保證了單分區的無鎖設計。當一個語句涉及到多個區分協調讀寫的時候，VoltDB會在協調，統一鎖定分區隊列，等該語句執行完畢之後，纔會釋放鎖。所以多分區操作纔會如此消耗性能。
VoltDB在分區管理上，建議每個物理CPU創建一個分區，這樣單個分區內的數據都在CPU的一級緩存和二級緩存上，避免在多個CPU之間的數據操作，最大限度的提升CPU利用率，避免併發鎖。所以理論上，VoltDB的CPU使用率是可以達到100%的。
- 內存存儲
高可用性
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不得不做出的犧牲。
- K-Safety
事務提交
既需要支持複雜的事務操作，又需要快速的執行過程，VoltDB採取了一個比較極端的事務提交方式。雖然VoltDB支持部分SQL語句接口，但是不允許用戶使用傳統的"BEGIN TRANSACTION"和"END TRANSACTION"的語法模式，而是完全基於存儲過程。用戶通過寫存儲過程完成應用程序的邏輯，作爲一個先置條件將存儲過程提交到VoltDB。運行時，用戶程序調用存儲過程完成事務操作，所有事務的運行邏輯是由VoltDB在服務器進程中完成的。這種方式保證了事務不會被人爲打斷，並且服務器可以預先判斷各個事務的邏輯，也爲事務併發處理挖掘信息。
分區表和複製表
-
- 分區表
創建表之後，需要手工執行分區語句爲表進行分區。
PARTITION TABLE towns ON COLUMN state_num;
該語句表明使用state_numn字段爲towns表進行分區。之後插入數據的時候，VoltDB會自動將數據插入指定分區。
目前VoltDB只支持Hash分區，後續可能會考慮支持範圍分區。
VoltDB的分區是一個邏輯上的概念，一個分區中可能包含多個表的多個數據分區的數據。VoltDB建議按照物理CPU的數量進行分區，每個分區獨立使用一個CPU，這樣可以避免CPU之間的鎖競爭。 - 複製表
一個表，沒有指定分區，那麼就是一個複製表。這個表的特徵就是會在每個分區保存一份全量副本，這樣在和其他表在做Join查詢的時候，就不會跨節點查詢，大大加快Join速度。
複製表適合於數據比較穩定，只有少量更新的場景。如果數據要更新，就意味着要在每個分區上都執行一次插入操作，這種操作會顯著降低系統併發度。
- 分區表
數據分佈
VoltDB使用Shared Nothing結構，整個數據庫的數據分散到集羣的多臺機器上。VoltDB的數據分佈策略是基於哈希的，存儲在VoltDB中的每一張表，對數據的主鍵哈希取模後的結果對應於數據存儲的節點。相比較於BigTable基於主鍵的連續範圍分段的方法，哈希方法的好處是數據分散的均勻，沒有動態數據調整的煩惱。但也有很多缺點，採用這種方法後，集羣的規模是事先確定好的，新增機器需要停止服務後重新分佈數據。另外，數據哈希被分散後，數據的連續性被打亂了，在這個數據結構上做範圍查詢需要動用服務這張表的所有機器，這個後面會祥說。
上面這張圖描述了數據的分佈方式，VoltDB集羣的每臺機器都會服務多張表。從圖裏還能看到VoltDB的數據複製是基於機器單位的，藍色框圈住的兩臺機器內的數據是完全同構的。
VoltDB的哈希分佈數據的方法是系統設計的簡化，這種簡化讓VoltDB工程實現難度降低，可以快速的商用。天下沒有免費的午餐，這個設計也是VoltDB功能缺陷，導致VoltDB無法動態擴容以及其他一些問題。
數據一致性
同一份數據的多個副本之間需要保證數據一致性，VoltDB採用所有修改操作在每一個副本上單獨更新的方式。如何保證更新操作在所有副本上以相同的順序更改而不至於產生不一致，這就要提到VoltDB的併發控制方式。
VoltDB的事務併發控制需要依賴於集羣內所有機器的時間是一致的，這個可以使用NTP之類的時間同步協議，保證機器之間的時間差異遠遠小於一個交換機下的兩臺機器之間的Round Trip時間。VoltDB對於用戶每一次事務的調用分配一個時間戳，並且保證這個時間戳是全局有序的，雖然時間戳是由集羣中的各臺機器獨自分配的，但是加上機器的序號，可以保證（機器序號，時間戳）的組合值是全局有序的。一臺服務器執行事務之前，需要等待Round Trip時間後，如果其他機器沒有開始比自己更早的事務，那麼就執行自己的事務。以這種方式保證集羣內多臺機器之間事務的有序。數據的多個副本的更新操作也都以相同的順序進行修改，所有副本之間保證了一致性。
事務併發處理
爲了充分發揮多核機器的性能，而又不引入多線程執行事務的複雜性，VoltDB的數據分片規模是按照集羣核數來劃分的。一臺物理機器上可能運行多個VoltDB服務器進程，每個進程對應於一個核，服務器進程之間都是通過網絡進行通信。在單個進程內，只使用單線程，所有的事務執行都是順序進行的。
多個事務在多個服務器節點同時執行，VoltDB保證如果事務之間有衝突，那麼事務的執行是完全隔離的，即達到SERIALIZABLE ISOLATION。VoltDB會事先分析好存儲過程之間的關係，如果兩個事務可能存在衝突，則不讓這兩個進程在同一個時間執行。
在VoltDB的併發處理中，每一個事務在執行之前都要等待一個Round Trip時間，顯然會增加事務執行的時延。這麼做是爲了確保別的節點沒有發起比這個事務更早的事務，保證事務執行的順序。在實現中，VoltDB用了另外一種優化方法。例如A，B兩個節點，分別要執行事務1和2，A節點開始執行事務1的時間是T1，如果A收到B發了事務2的執行需求，並且T2 > T1，那麼A節點可以確認從B節點不會有更早的事務再發送過來，A節點就不必等Round Trip時間，可以直接執行事務1。當整個系統壓力比較大時，這個優化方法效果尤其明顯，事務的時延有效降低。
VoltDB還花了很大精力在處理事務之間的邏輯關係，儘可能對事務分門別類進行處理，以期獲得更好的性能。
範圍查詢的處理
VoltDB取巧的採用的哈希的方法做數據分佈，在面對範圍查詢的需求時，再次吃到苦果。哈希方法打亂了數據的連續性，對於範圍查詢的處理能力顯著下降。VoltDB執行某張表的範圍查詢，需要發送這個查詢到這張表的所有數據分片上。在所有分片完成同樣的範圍查詢，再將結果彙總，才能得到全局的準確結果。所以VoltDB處理範圍查詢會很低效
數據持久化
雖然Stonebraker在H-Store的論文裏反覆提到，在內存型數據庫裏，即使使用Group Commit寫操作日誌也是非常低效的，但是爲了保證數據的持久性，VoltDB還是不得不採用記操作日誌的辦法。VoltDB使用定期做Snapshot加上記操作日誌來保證數據持久性，這種方法沒有什麼特別的地方。