一、內存數據庫的應用場景
- 數據緩存：將經常使用的數據存放在內存中，全局共享，減少和數據之間的交互頻率，提升數據訪問速度，主要用於應用程序的全局共享緩存。
- 內存計算：支持通過標准的SQL或Linq的方式實現內存數據的聚合、計算和查詢、充分發揮、利用應用服務器的資源
二、業界有哪幾類的主流內存數據庫
1.關系型內存數據庫
- 傳統關系型數據庫場景下，應用層的數據緩存
- 將傳統的關系型數據庫表搬到內存中，內存數據和數據庫數據之間進行結構映射
- 支持通過SQL語句的方式實現對內存數據的訪問，更加貼合業務實現
- 將經常使用的數據存放在內存中，減少和數據庫之間的交互頻率，提升數據訪問數據
- 數據實時/定時同步
- 有限的事物保證
2.鍵值對內存數據庫
- 鍵值對存儲結構
- 按Key進行數據讀取
- Value支持各種數據類型
- 類似Redis
3.傳統數據庫的內存數據庫引擎
- SQLServer2016 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做的非常好。這一點非常符合我們技術選型的需要！一句話：
可以像操作數據庫一樣，操作內存緩存！
先放出兩張圖給大家：
