內存數據庫技術選型

最近一段時間研究了內存數據庫，總結了一下，分享給你們。咱們先從應用場景提及。

一. 內存數據庫的應用場景

• 數據緩存：將常用的數據存放在內存中，全局共享，減小和數據庫之間的交互頻率，提高數據訪問速度，主要用於應用程序全局共享緩存。
• 內存計算：支持經過標準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作的很是好。這一點很是符合咱們技術選型的須要！一句話：

能夠像操做數據庫同樣，操做內存緩存！

先放出兩張圖給你們：

  

from:https://www.cnblogs.com/tianqing/p/7429900.html