原本想问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资料库，是很有意义的
推荐阅读：
相关文章