原本想問SQL Server的In-memory OLTP可能對SAP HANA市場造成的影響，但是考慮到影響可能不限於HANA，所以把問題問的寬點。

稍微看了看，Hekaton是將表整體遷移到內存裡面並更改了索引方式和鎖方式，造成的結果就是更加合理的在內存中使用RDBMS的思想。

看了資料說Hekaton可以設置為普通的ACID和另一種不激活log與checkpoint的方式，前者拼大量硬體可以做到高頻低延時且持久化，後者可以允許犧牲數據一致性換來在低成本下的高可用性。

Hekaton本身的戰略意義目前看不透，因為沒有發現這個東西能夠用於分散式的地方（如果可以直接利用雲計算進行計算吞吐就給力了）。

但是集成於SQLServer2014：

一是順應時代潮流，現在內存不值錢，往後SSD不值錢或者其他存儲介質不值錢的時候，還是要用新思想去設計資料庫引擎；

二是繼續捆綁.Net平臺（SQLServer沒有徹底集成到CLR真是心中之痛= =|||），這下子用.Net開發UI層的公司又少了一個理由換用其他資料庫了（有人能給推薦一個能和SQLServer集成起來的全文索引麼？ms自家的太爛了= =），而且這些人又是大金主，ms現在是全線狙擊啊。三是以免費搏收費，本身SQLServer不差，現在繼續使用，在不多花錢的情況下，直接給你個新產品（具體這個產品好不好，怎麼發license還不知道）。隨便猜的。

In-memory OLTP很長一段時間我是沒有看到它的顛覆性有多大的，當然performance啦各種是會有提高的。SQLServer的hekaton啦，或者其他廠商的in-memory OLTP engine，當然你不能重新起爐竈來實現一個OLTP，也只能是漸進式創新了，現在內存那麼便宜，用的激進一點是沒多大關係的。當然考量In-memory OLTP是否有用還是要看其並發度，實時性到底能提高多少，現在來看，heketon可能沒有宣傳的那麼好。如果要說戰略意義，我猜是技術要升級，走向H-Store類型，in-memory當然不能單獨提出來，與多核，分散式，shared-nothing架構都分不開，最終還是要走向雲。

HANA是一個HTAP（Hybrid Transactional/Analytical Processing）系統，最大的技術亮點是無索引無聚合（注意，傳統索引是一種磁碟數據結構，如果沒辦法拋棄索引，你怎麼說自己是一個純粹的in-memory database呢）。實現方式其實是column engine是為主內存的，這樣可以用極致的壓縮高效的處理來實現analytical的任務，所以oracle一個禮拜跑完的任務，HANA只需要8s，所以HANA的亮點還是在OLAP分析型應用上的。其他廠商玩的都屬於沒玩明白的。

到現在來看，所有in-memory database玩家都離HANA差了一大截，要趕上還差得遠。但是另一方面，OLTP系統的升級估計還是沒幾個玩家能跟Oracle拼一拼。無論SQLServer還是HANA都是各自企業的護城河，用來守護windows陣營和ERP陣營的，只有Oracle纔是一個真正的資料庫廠商，所以長遠看，技術不管怎麼升級，影響都不會太大。

看了好多回答，但是都沒有能說明白如下問題

1 SQL Server本來就是in memory的，任何資料庫都會用大量內存去cache磁碟數據，所以未來內存越來越大並不是用in memory字面意思就能說明的優勢。

2 oltp除非降低可靠性，憑什麼in memory能提高性能？都要落盤和集羣才能言及可靠性，然而這一個是磁碟為主的問題，一個是網路為主的問題，in memory到底在哪裡產生了建樹？

3 據我所知sql server本來就支持mvcc的，只是默認沒開snapshot級別的事務模式，snapshot我理解就是multi-version的意思，不知道對不對。

我憑空推測下，in memory表如果要做到實質性的提升，可能主要就是優化內存裏的數據結構而不是經典的cache模式，比如列存儲，拋棄btree(為磁碟設計的)等。

然後是增加很多in memory適合做的東西，比如高並發的鎖操作。一臺資料庫就能做到隊列的功能，並能保證可靠性。

但是對於oltp，必須落盤的東西，除了改變落盤策略，通過降低可靠性提高性能，其他還真想不到能怎麼提升。但是降低可靠性提升性能的落盤策略，同樣適用於普通表。

20170929，經過 @西皮士 在回答中的提醒，找到了一篇最能確切回答這個問題的論文，我摘抄一段出來分享一下，我覺得這纔是這個問題的好答案。（7. TRANSACTION DURABILITY）

  1. Optimize for sequential access so customers can spend their money on main memory rather than I/O devices with fast random access.
  2. Push work to recovery time to minimize overhead during normal transaction execution.
  3. Eliminate scaling bottlenecks.

可以看到一些關鍵點

  1. 首先是這種類型的表完全放在內存中，因為當前內存相對來說已經白菜價，不應該像以前資料庫一樣重點是磁碟，輔助纔是內存。同時也因此對「表」的處理專門做了內存層面的大量重寫，不沿用以前的做法，祥見論文。
  2. 基於以上，怎麼解決數據持久化的問題呢？就是日誌。而且是簡單的日誌。因為in memory OLTP的設計原則就是必須分散式的，所以僅靠日誌來做持久化，不考慮只有日誌，資料庫宕機後恢復緩慢的問題。因為應對資料庫宕機是always online的集羣方案。
  3. 因為都在內存裏，方便做大並發

論文其它地方主要在重複一些mvcc和一些底層細節，希望詳細瞭解的可以自行查看。

https://web.eecs.umich.edu/~mozafari/fall2015/eecs584/papers/hekaton.pdf

我從2012年在西雅圖pass峯會上第一次聽說內存資料庫，當時感覺我們sql server黨的春天就要來了，後來發現hekaton有很多缺陷，比如不支持中文排序規則，極度喫內存等，當時我做了大量的測試，發現與官方宣稱的幾十倍不符合，最好的情況也僅僅是幾倍。這個功能其實更適合國外的一些場景，國內很多場景用不到這個量，能到這個量的早已在前端做了緩存

從行業趨勢上講，整個行業現在內存越來越便宜。但是對傳統的關係型資料庫性能要求越來越高。

從技術棧上來講，現在大家越來越喜歡用in-memory 資料庫。但是學習一個新的資料庫是需要成本的，那麼不如直接在我們的sqlserver裏嵌一個新的feature吧，而且我可以同時查詢in-memory table和disk-based table

從技術細節上來講，in-memory table 幹掉了傳統disk-based表的lock 和latch,使用了multi-version concurrent control.在內存裏的表現就是將很多內存行使用了hash索引連接了起來。並且使用transaction ID對並發進行管理。hash索引意味著O(1)的查詢性能（你可以在in-memory表裡創建多個hash索引，當然也可以創建Bw-tree的非聚集索引)對於stored procedure來說，in-memory table使用的是native compiled sp,也就是你所有的存儲過程是被預先編譯成二進位代碼的。

總結起來，性能飆的飛起~

但是使用起來需要對你的內存有一個完整的規劃，一般推薦的配置是2:1,也就是你如果使用100MB的in-memory table，你至少要為它預留200MB內存~

利益相關：巨硬consultant.

毫無疑問用內存比用硬碟要快，但是怎麼從軟體架構上讓OLTP系統最大程度的利用內存來提高吞吐量呢？

Hekaton 的主要創新是：

1. MVCC取代了latch, 讓交易阻塞的時間儘可能短 (論文 http://vldb.org/pvldb/vol5/p298_per-akelarson_vldb2012.pdf)

2. 使用了一種在內存上性能更好的Bw-Tree實現 （論文 http://research.microsoft.com/pubs/178758/bw-tree-icde2013-final.pdf）戰略上來說，一站式的解決方案不管是對留住現有用戶還是對新用戶都很有吸引力吧？====================================================================順便講一句，目前地球上最懂transaction的人在微軟，叫Philip Bernstein, 現在做transaction的大部分人都是看著他教科書來做系統的
Hekaton表的 並發寫能力非常非常牛逼 ! 在同樣電腦上簡單測試了一下，比Oracle的普通錶快很多！
其實hekaton可不僅僅是sql server用，微軟的cosmosdb的存儲引擎就是這個，bing store用的也是這個，微軟的paxos實現用的也是這個，還有其他

當然是為了充分壓榨CPU的性能，結合一些memory optimized的黑科技，提高並發吞吐量。

可以先思考這樣一個問題：假設數據都在內存(設置一些參數可以模擬)，MySQL性能(這裡只說事務性引擎)能提高多少呢？答案是沒多少，恐怕CPU的大部分指令都是空跑。

這個h就不同了，主索引哈希，二級索引bw-tree,sql預編譯，所有事務都是lock-free，而且支持ACID，還可以快速recover，真是師奶級別殺手。

內存越來越大，CPU越來越強勁，我們就不要浪費它。

Hana主要市場是OLAP,如果sql server 2014是內存OLTP的話，那受影響的是Timesten要說其適用範圍，和timesten類似了，實時計費，證券交易，對於這些低延時，高並發，強事務要求類型系統，內存OLTP資料庫，是很有意義的
推薦閱讀：
相關文章