【IT168 技术】今天的世界已经是一个大数据的世界，伴随数据量爆发式增长的还有硬件的计算能力、不断增强的CPU计算能力和单位GB内存价格的不断下降，更好地利用这些强大的资源是大势所趋。微软SQL Server 2014提供了众多激动人心的新功能，但其中最让人期待的特性之一就是代号为” Hekaton”的内存数据库了，内存数据库特性并不是SQL Server的替代，而是适应时代的补充，现在SQL Server具备了将数据表完整存入内存的功能。相比较于Oracle的TimesTen和IBM的SolidDB，Hekaton是完全集成于数据库引擎并且不需要额外付费的功能。

　　一、内存数据库出现的背景

　　在传统的数据库表中，由于磁盘的物理结构限制，OLTP类操作引起的随机查找会给IO系统带来高昂的开销，因此传统的表和索引的结构设计为使用B-Tree而尽量减少随机查找，但由于机械磁盘和数据库锁的存在，B-Tree结构在处理大并发的OLTP环境时就显得非常乏力，虽然有很多办法来解决这类问题，比如说乐观并发控制、应用程序缓存、分布式架构等，但采用上述方案会导致修改引用程序，这不仅成本高且风险极大。而随着这些年硬件的发展，现在服务器拥有几百G内存并不罕见，此外由于硬件NUMA架构的成熟，也消除了多CPU访问内存的瓶颈问题，因此具备了使用新方式来处理更大并发和数据量的条件，这种新的方式就是使用内存计算技术。

　　内存的学名叫做Random Access Memory(RAM)，因此如其特性一样，是随机访问的，因此对于内存，随机查找不会引入额外开销，使用Hash-Index这样的数据结构更符合内存的特性，而对应并发的隔离方式也对应的变成了MVCC(多版本并发控制)，从而消除了锁引入的性能瓶颈。因此内存数据库可以在同样的硬件资源下，处理更多的并发和请求，并且不会被锁阻塞，在SQL Server 2014中，集成了这个强大的内存数据引擎，如果结合SSD AS Buffer Pool特性，所产生的效果将会非常值得期待。

　　二、SQL Server内存数据库的组成和表现形式

　　在SQL Server 2014的内存数据库引擎由两部分组成：内存优化表和本地编译存储过程。虽然内存数据库集成进入关系数据库引擎，但访问内存数据库的方法对于客户端来说是透明的，这也意味着从客户端应用程序的角度来看，并不会知道内存数据库引擎的存在。如图1所示。

▲图1.客户端APP不会感知Hekaton引擎的存在

　　首先内存优化表完全不会再存在锁的概念(虽然之前的版本有快照隔离这个乐观并发控制的概念，但快照隔离仍然需要在修改数据的时候加锁)，此外内存优化表Hash-Index结构使得随机读写的速度较高提升，内存优化表还可以设置为使用非持久化日志，既数据既不写日志，也不会CheckPoint到磁盘，从而极大的降低了IO压力(适合于ETL中间结果操作，或者其他允许丢失数据的场景)，这样一来也可以消除写日志引入的性能瓶颈。

　　下面来创建一个内存优化表：

　　首先，内存优化表需要数据库中存在一个特殊的文件组，以供存储内存优化表的CheckPoint文件，与传统的mdf或ldf文件不同的是，该文件组是一个目录而不是一个文件，因为CheckPoint文件只会将新增的数据附加在到新的CheckPoint文件，而不会修改现有的CheckPoint文件，如图2所示。

▲图2.内存优化表所需的特殊文件组

　　下面再来看一下内存优化文件组在磁盘系统的存储形式，如图3所示。

▲图3.内存优化文件组

　　创建完内存优化文件组之后，接下来再创建一个内存优化表，如图4所示。

▲图4.创建内存优化表

　　目前SSMS还不支持UI界面创建内存优化表，因此只能通过T-SQL来创建内存优化表，如图5所示。

▲图5.使用代码创建内存优化表

　　这里创建一个简单的内存优化表，这里上述设置Hash Bucket为1024，目前SQL Server 2014还不支持动态的Hash Bucket，因此必须手动设置该值。表中设置了Memory_Optimized为ON意味着表是内存优化表，而Durability设置为Schema_And_Data则意味着内存优化表中数据也是持久化，这意味着除非启用了SQL Server 2014的延迟写特性，数据不会由于异常情况导致丢失。

　　当表创建好之后，就可以查询数据了，值得注意的是，查询内存优化表需要snapshot隔离等级或者hint，这个隔离等级与快照隔离是不同的，如图6所示。

▲图6.查询内存优化表需要加提示

　　三、迁移现有环境到内存优化表

　　1.内存引擎与高可用特性兼容性

　　将现有数据库迁移到内存优化表需要充分考虑现有数据库系统的环境，从大的方向来说，内存优化表与一部分SQL Server高可用特性不兼容，比如说，数据库镜像和复制，但其他诸如AlwaysOn可用性组、日志传送、备份还原等高可用特性与内存优化表完全兼容。

　　2.内存引擎与传统引擎的无缝集成

　　内存引擎的最小粒度是表，所以仅可以将数据库中的部分表转为内存优化表。内存优化表与磁盘表可以无缝的进行交互，从而可以充分利用这两个引擎的优点。在图7中将内存优化表和磁盘表进行连接操作。

▲图7.内存优化表与磁盘表的连接

　　3.内存引擎与表级别特性的兼容性

　　内存优化表还与其他一些表级别特性不兼容，比如说迁移到内存优化表的表中不能存在计算列、触发器等。微软在SQL Server 2014中提供了一个叫做”内存优化顾问”的工具，该工具可以帮助数据库人员快速找出不兼容内存优化表的部分并帮助完成迁移。下面来看内存优化顾问。

　　4.内存优化顾问

　　不是所有的数据都可以无缝迁移到内存优化表中，如果表上存在一些诸如计算列、外键、Default或Check约束的对象时，则无法将现有表迁移到内存优化表中。因此使用微软提供的内存优化顾问可以使得迁移过程更加平滑。

　　通过SQL Server 2014的SSMS，在需要验证的表上右击，在弹出菜单中选择“内存优化顾问”来打开内存优化顾问，如图8所示。

▲图8.内存优化顾问

　　打开内存优化顾问后，可以利用内存优化顾问找到阻止迁移到内存优化表的问题，如图9所示。

▲图9.查看影响迁移到内存优化表的问题

　　而如果不存在阻止迁移到内存优化表的问题，则可以利用内存优化顾问直接将表和表中的数据迁移到内存优化表中。如图10和图11所示。

▲图10.将数据也迁移到内存优化表

▲图11.将数据从磁盘表迁移到内存优化表完成

　　四、内存数据库性能测试

　　有了前文的理论铺垫后，下面来做一个简单的性能测试，来比对使用内存优化表结合本地编译存储过程与传统的B-Tree表，在B-Tree表上进行性能测试的结果如图12所示，在内存优化表加本地编译存储过程上进行性能测试的结果如图13所示。

▲图12.传统的B-Tree表

▲图13.内存优化表+本地编译存储过程

　　内存优化表在10倍于传统表并发的情况下，执行时间却只有传统表上执行时间的三分之一，因此不难看出，内存优化表+本地编译存储过程有接近几十倍的性能提升。

　　五、小结

　　SQL Server 2014中的内存数据库是一项可以极大的提升OLTP性能的功能，通过测试可以看出OLTP环境下使用内存数据引擎来说有几十倍的性能提升，微软同时还提供了内存优化顾问工具来使得迁移更加平滑。但是内存数据库的要求也比较严格，现有数据库如果希望能够享受内存优化表带来的性能提升，则需要做一些前期铺垫工作。

　　作者简介

　　宋沄剑，微软SQL server最有价值专家，《SQL Server 2012管理高级教程》译者，SQL Server专家协会北京分会创始人之一，目前就职于北京格瑞趋势科技有限公司任数据库高级顾问，专注于帮助大型企业用户设计数据库方案和解决数据库问题。