內存資料庫 (in-memory database) 的發展現狀和前景如何？

12-30

內存資料庫是指一種將全部內容存放在內存中，而非傳統資料庫那樣存放在外部存儲器中的資料庫。內存資料庫指的是所有的數據訪問控制都在內存中進行，這是與磁碟資料庫相對而言的。磁碟資料庫雖然也有一定的緩存機制，但都不能避免從外設到內存的交換，而這種交換過程對性能的損耗是致命的。由於內存的讀寫速度極快（雙通道DDR3-1333可以達到9300 MB/s，一般磁碟約150 MB/s），隨機訪問時間更是可以納秒計（一般磁碟約10 ms，雙通道DDR3-1333可以達到0.05 ms），所以這種資料庫的讀寫性能很高，主要用在對性能要求極高的環境中，但是在伺服器關閉後會立刻丟失全部儲存的數據。常見的例子有MySQL的MEMORY存儲引擎、eXtremeDB、FastDB、SQLite、Microsoft SQL Server Compact等。

Source: 內存資料庫

1. in-memory資料庫的最大賣點其實不是把數據放在內存里.

2. 最大的變化是把傳統關係型資料庫(RDBMS)里表的存儲方式從行存儲變為列存儲.

列存儲的好處是:

2a. 數據的壓縮率可以很大, 因為往往很多應用表裡一列的數據冗餘度很大

2b. 對於OLAP系統來說, 求和, 平均等aggregation的查詢在列上操作效率非常高

所以列存儲已經成為所有所謂in-memory資料庫的標準配置

3. SAP HANA的終極目標是消滅OLTP和OLAP的區別, 讓快速的直接查詢數據成為可能. 不過由於技術上的限制 (比如列存儲表如何解決鎖的問題), 個人認為還需要幾年的時間才能實現.　不過SAP的優勢是可以通過應用層面的修改來更好的利用列存儲的數據以實現最終用戶的需求.

4. Oracle 12c新推出的in-memory選項只是提供一種可能:選擇性的把某些表變成列存儲放在內存里，如果沒有應用層面的修改，該選項帶來的益處也只是有限的．

先想到這些

如果你認為未來內存容量會變得非常大，大到可以部分取代磁碟。那就去做內存資料庫

如果你認為未來不是這樣，那就是現在的方案更好。

最近沉迷於寫小說了，沒想到還會被邀請，謝邀。

建立在內存讀寫速度遠超磁碟的基礎上，內存資料庫的發展很迅速（發展狀況）。

幾乎特大資料庫廠商都有自己的內存資料庫，微軟的SQL Server 2014也特意將內存資料庫作為一個亮點來宣傳。

大體上來說，那些收費的商業化產品功能更完善，開源的產品主要是達到高性能讀寫的要求。

至於發展前景，雖說各大廠商都投入這件事，但結果依然不太好說，因為裡面涉及一些未知因素。

大家知道內存資料庫的應用場景，會發現通常都不是完整的資料庫，而是其中的一部分。

舉例來說，企業環境建立一套資料庫，涉及到一百張數據表，其中需要採用內存資料庫的表，或許只有十個不到。

也就是說，目前的內存資料庫，並不算是真正的資料庫。

那麼現在應用內存資料庫，主要解決什麼問題？

解決讀寫性能低下的問題？這樣說有些籠統了。

具體點來說，就是解決現有資料庫系統不擅長的數據處理需求，比如說數據分頁這種和演算法親密聯繫的需求。

處理過此類問題的同學都有經驗，隨便幾百萬的數據表聯合一下要分頁，都快不起來的。

無論SQL怎麼寫都不行，因為這不是SQL擅長的領域，但如果採用MMDB，隨便選擇一種，輕鬆解決。

目前的內存資料庫是這樣，不代表將來也是這樣。

那麼在將來，內存資料庫能否取代現有的資料庫系統？

個人認為是可以的。

這裡先說明下前面同學提到的斷電問題，內存資料庫並不是內存，斷電對它的影響沒那麼大。

因為各個產品都有應對措施，叫法也有些區別。

例如微軟的checkpoint，例如有同學提到的log，這些數據持久化的方案能將斷電影響減到最低。

也就是說，在內存資料庫和磁碟之間，是會有數據同步的。

例如Redis，程序猿很容易就能實現內存數據到磁碟的同步。

不久的將來，資料庫系統可能就完全運轉在內存中，只要持久化做得好，應該是能實現的。

比較關鍵的是，內存速度比磁碟快了一個數量級，這個持久化能否做到很好？

比如說內存有1TB數據變化，誰能保證在斷電時全部都持久化完畢？

或許到了那一天，我們的內存資料庫後面有一百個SSD用於數據持久化，一百個不夠的話，或許是一千個，甚至更多……

PS：相比於資料庫管理人員，資料庫開發工程師應該更懂內存資料庫。

1.內存資料庫的發展已經有很長歷史了，目的就是解決關係型資料庫高並發情況下數據處理時壓力問題。

2.未來的發展很廣闊，可以說最近幾年使用率比較高。

3.最關鍵的是內存資料庫解決了關係型資料庫，存儲等在數據存取方面存在的弊端。

4.內存資料庫解決的是數據使用效率的問題，不是數據的持久化，所以那裡有數據使用，他就會發揮餘熱。

5.未來很長一段時間，使用前景很廣闊。

蟹妖~

請原諒我沒有真實的使用過in-memory database, 即中文的「內存資料庫」，僅僅給你附幾個帖子，想來可以解決掉你的一些問題~

終結硬碟時代主流內存資料庫對比報告-IT168 技術開發專區

甲骨文John Foley：內存技術怎樣變革業務

內存資料庫優劣勢有那些？

容我小小的偷個懶搬運下~~

講點個人見解。從計算機硬體技術來看，將來內存替代硬碟，甚至CPU集成內存，數據存儲全部由CPU RAM來操作，是完全有可能實現的。至於成本何時能夠降下來，這個就說不準了。實際上，企業用內存資料庫，更多的考量來自於數據處理速度，這方面採用的數據相對於企業整體數據來看肯定是少部分，畢竟成本偏高。現今的企業資料庫應用更多的還是以數據存儲、管理、維護為主，即時性的應用更多的存在於金融、通信等實時性較高、企業本身運營成本極高的較為狹窄的領域。

我的觀點是，除非將來大部分有關於數據管理的應用需要即時操作，那麼內存資料庫將會大有可為；反之，如果大量的數據僅僅是用作存儲及較為不頻繁的計算的話，那麼內存資料庫的存儲穩定性相對不足以及高成本就可能制約其大量應用。

而且，大容量SSD硬碟技術，我想應該也是內存資料庫的一個挑戰。現在很多企業的資料庫均採用大容量SSD搭建，本身的速度、穩定性可能已經滿足現今的實時性要求。所以，內存資料庫前景應該很廣闊，但是怎麼用，用在哪裡，這個得看將來的商業數據處理模式的主流來定，現在肯定說不好。

不知道滿不滿足你的要求，有什麼問題請及時與我溝通，有說的不對的地方請指正，謝謝！！

未在生產環境中使用過，個人這麼認為：

內存資料庫出現的原因有，

1. 用戶對性能要求的高標準：一般來說越快的應用用戶越喜歡

2. 數據實時計算：快速處理輸入數據，從而提高快速反應能力，比如流計算，如果所有數據都在內存，那麼流計算能提供的功能會更加豐富；

3. 企業內部特定場景對性能的高要求：比如OLAP系統（比如出報表）裡面對某些元數據的頻繁訪問，這時候元數據放入內存肯定能大大加快整個程序的執行

當然，內存價格的下降也是的內存資料庫成為現實；

內存資料庫的定位：傳統資料庫的補充，數據越來越多，內存肯定是搞不定的，那麼如何合理的分配內存資料庫和磁碟資料庫值得考量，這方面會有越來越多的模式出現；

內存能資料庫的劣勢：

1. 數據安全：進程crash則數據丟失，對於資料庫這基本不可忍受，可以通過log形式保存數據，一旦出現問題再恢復；或者做跨機房多拷貝，那麼可以不寫log，後台慢慢刷存儲也是可以的；

2. 風暴效應：一旦進程crash，則應用性能大幅下降，此時極高的壓力可能再次將進程壓垮，這個通過上面說的多份拷貝也能解決；

多份拷貝的難點是如何保證一致性，目前已有不少這方面的理論和實踐。

總體來看，內存資料庫更像一個有益的補充，而很難獨撐大梁。

內存資料庫將會越來越重要，將來每一個DBA都要掌握內存資料庫，每一名開發，也要懂些內存資料庫。現在大數據概念火的一溻糊塗，大數據的「數據」從何而來？當然是前台的OLTP系統，用戶總是會要求響應速度越來越快，而前台OLTP系統隨著用戶越來越多，業務越來越多等等因素，速度、響應時間都會逐漸變慢，內存資料庫無疑是解決OLTP性能問題的最好方式。而且現在內存容量在快速加大，價格成本卻保持不變。三、四年前配有32G、64G內存的PC Server已經是大的了，現在256G內存已經是主流配置。「將資料庫全部Load到內存」中，這DBA、開發們的夢想，勢必會比「中國夢」更快實現。在這些條件下，內存資料庫的需求一定會快速生長起來。

但內存資料庫和將「數據全部Load到內存中的傳統資料庫」，有何區別呢？內存資料庫通常以Key-Value方式存取數據，其內部簡單。傳統資料庫，單是「讀/寫」操作前的SQL解析，就要耗費不少資源。內存資料庫功能單一，但更短的代碼路徑，使性能也更加快速。

但內存資料庫不會獨立於傳統資料庫而單獨存在，因為內存是易失的。現在具有持久化功能的內存庫，如redis、couchbase等，其持久化功能相較傳統資料庫還較溥弱，持久化性能也不如傳統資料庫。因此，內存資料庫將一直是傳統資料庫的一種強有力的補充。

如果說傳統資料庫是一支軍隊，那麼內存資料庫就是為執行某種特殊任務的特種部隊，不要求功能多，但一定要快速、迅猛。

我沒有從技術角度講這個問題，更沒有去比較現在的內存資料庫誰更強。技術的高低很難用幾句話甚至幾篇文章描述，更多時候，可能某種技術只在某些種情況下是最好的，換其他的情況，可能就是其他技術更好。我只從商業角度來回答這個問題。現在「大數據」這個名詞火的一溻糊塗。但正如海洋是由每一滴水彙集而成一樣，「大數據」是由一條條」數據「彙集而，這聚集成大數據的」數據「又從何而來，當然是OLTP。OLTP相當於企業」大數據「的咽喉，沒有OLTP中的數據，沒有大數據中的數據。而內存資料庫現在已經成為OLTP中不可或缺的部分，而且隨著OLTP規模擴展，會越來越重要。

無論以日誌還是哪種方式存在，數據持久化終歸要落實到磁碟/ssd等設備上，完全依賴內存的資料庫應該短時間難以實現。如果完全依賴於ram來存儲數據，用高可用的架構解決斷電數據丟失的問題，應該還有很長的路要走，再者其實現成本可能超出部署分散式高性能存儲的成本。當傳統的關係型/非關係型資料庫，sql和nosql資料庫都無法應變數據處理需求時，資料庫類型的大變革或許才會真正到來。

不提HANA，純說oracle 自己，傳統的做法了為了節省內存把數據做到小塊8k載入，然後用hash的方法來尋找這些數據塊，然後計算數據塊的hot程度，為了保證內存不夠的時候把一些不用的dirty data block flush回資料庫。

一個典型的數據讀取會經過非常長的代碼路徑做訪問控制。當內存大到可以把整個表放到內存，我們是不是還需要用keep /default的方法來手動控制表放在內存硬碟。如果可以的話，是不是可以有一些自動的方法來控制。傳統的row table是否適合 group，為什麼需要做PGA一次排序，兩次排序以及多次排序。列表如何支持行鎖跟快速更新。ORACLE這麼多年太強大，其實歷史負擔也很大

內存數據能的優勢就是速度，但是由於數據持久存儲的問題，現階段應用主要還是緩存數據。

關於前景，現有的技術在應用層面都不是單一存在的，越來越複雜的需求需要多種技術的融合來實現，

蟹妖。

技術的發展，取決於人類的需求。很明顯，in-memory database帶來的是超高的效率，前景是非常可觀的，但斷電對其而言卻也是明顯致命的；當然這個問題也是能解決的，比如UPS容災，當然這個屬於下策。就當前在這個領域比較領先及具有代表性的產品是SAP公司的HANA，在關於斷電數據處理這塊，SAP做了這樣的處理：在數據的持久化機制這塊上，HANA做了類似oracle的redolog功能，通過提交log，斷電後可以重新讀取。具體實現是在硬體層提供高速快閃記憶體用於同步內存中的log信息，並生成Save Point寫入到物理磁碟中。這樣，即使是斷電，數據還是得到了保留。當然受所屬時代在技術及知識層面上的限制，我們無法預知未來更多、更大的數據到底是跑在內存還是其他更高速度的硬體上。但能肯定的是，技術的革新變革取決於人類生產與生存的需求，如果需求沒再提高，可能我們未來十年、二十年都還覺得hana是屬於高端科技。當然這個設想肯定不可能是真命題，人性的貪婪，遠比我們自己想像的還要可怕。

在這個速食的年代，內存為王。所以in mem的資料庫必然是未來的主流趨勢，同時由於使用內存型數據需要將RDBMS中的關係都轉化成KV，業務會被迫設計的更加簡潔和清晰，也有助於定位問題。唯一考慮的就是內存的價格，但是隨著Flash的價格越來越平民，同事性能也在不斷提升，即時data in mem也可以分冷熱，可以通過將部分冷數據落地到flash的方法降低這部分的成本。

看看RAMCloud，這個要考慮數據在內存中的布局，容錯和調度等問題，這個方向還是很難的，感覺。

對內存資料庫使用不多，只接觸過timesten，一般都是作為oracle的前端cache，各有各的優勢，通常都是結合使用

首先說一下接觸過的內存資料庫有redis，volddb。內存資料庫應該算是資料庫的一類吧，資料庫主要是來解決在應用的數據方面的需求，而現在的數據需求也有很多類。說說結果過的資料庫吧。

大數據（海量數據）分析資料庫，Hive；大數據實時響應資料庫Hbase；內存資料庫volddb；KV資料庫redis，傳統資料庫mysql，oracle，還有其他的內存資料庫。目前來看，內存資料庫也有很多的應用場景，很多的大公司也都在用，將來也會是資料庫的一個很重要發展方向。至於內存資料庫使用的一些技術，可以另做一個主題分析下。

謝謝。

內存資料庫其實一直都在應用的很好，在不需要寫到外存儲器的情況下，處理數據速度很快，可以跟應用很好的集成到一起，提供高性能的數據處理能力。如果對於數據只是在內存處理而不是從外存讀取和存儲，內存資料庫的優勢無可抵擋。退一步講，如果數據初始load和最終需要flush到外存，那麼就需要考慮數據一致性問題，但是中間處理過程依然是快速的。

傳統的分散式資料庫現在用的越來越少，而分散式數據處理這個概念卻是多年來應用非常好的領域，比如各種大數據框架都就是分散式數據處理嗎？所以，內存資料庫稍微延伸一下，也就是內存數據處理也會是一個很好的方向。Spark框架就是在內存中處理數據，目前正煥發強勁的生命力。

一般來說，某種技術還是隨應用場景的需求而定，好比生產力和生產關係之間，如果適合了，技術大發展，應用也會大發展，如果應用不需要，技術一定會慢慢銷聲匿跡。

這個方向的事情早就有相關的類似項目在做。

比如java版本的in-memory grid項目。

我具體還要看下RAMCloud相關的文檔和試用下demo軟體（如果有的話）。再回來做下相關論述。

因為我也很感興趣這種項目。普通的RDBMS或NOSQL資料庫都是將數據布局依託於系統本身的文件系統或自身重定義的存儲方式（比如mongodb的BSON更類似於object-storage方式的文件系統存儲）.這個議題很值得挖掘和分析。我先看下它的相關技術層面的簡介。

你想要的應該是Oracle Exalytics...

取決於需求，很多資料庫在出現之前都認為是理論的東西，像處理大數據的幾個資料庫。現在不也一樣那麼火！ do it ！

商業化產品SAP HANA已經投入生產環境商用，內存資料庫前景廣闊。

舉個栗子：2億條庫存交易數據算按周的收發存，幾秒內出結果。

PS：HANA可不是什麼In-Memory的伎倆。