SQL Server 2014内存优化表的使用场景

 

最近一个朋友找到走起君，咨询走起君内存优化表如何做高可用的问题

大家知道，内存优化表是从SQL Server 2014开始引入，可能大家对内存优化表还是比较陌生，网上也鲜有内存优化表使用场景的文章

朋友公司做的业务是跟蜂鸟配送类似的配送业务，整个配送系统平台每天订单量超过30W

 

坐标问题

系统中某一个部分需要保存跑男的坐标

坐标需要保存到redis和数据库，一旦坐标更新也需要更新redis中的数据

刚开始朋友用传统表来保存坐标数据，但是很快遇到问题，传统表在更新的速度跟不上

后来改用内存优化表，使用了之后

刚开始上传坐标的接口，延迟很大，用了内存表，100毫秒以内，搞定

这些坐标是需要持久化的，而内存优化表是完全支持ACID的，所以也不需要担心数据丢失的问题

内存优化表更新速度快的另一个原因：无锁机制，  并发（如闩锁争用或阻塞）影响的应用程序迁移到内存中 OLTP 时，其性能会显著提高。

 

 

大家知道，内存优化表需要有一个非聚集哈希主键索引，大概的表结构是

每个跑男占用一行记录

 

对应到redis里面大家应该都知道怎麽存储了吧，使用redis的散列类型来存储跑男的坐标

hmset 跑男ID X坐标 value Y坐标 value 跑男在线时间 value hmset 1 X坐标 12 Y坐标 10 跑男在线时间 60

 

 

因为数据库高可用的问题，朋友就购置了新服务器，用来搭建AlwaysOn，新服务器都用SSD固态硬盘

内存优化表的瓶颈主要在事务日志固化，虽然有延迟持久化，但是延迟持久化在意外宕机的时候可能丢失部分数据

现在新服务器使用SSD固态硬盘之后，事务日志固化的瓶颈基本消失

使用新服务器之后，支撑30w/日订单是完全没有问题的

 

 

另一个问题是AlwaysOn问题

实际上，SQL Server 2014的AlwaysOn集群已经支持内存优化表，只是不支持在辅助副本上查询内存优化表数据，在故障转移之后

辅助副本上的内存优化表数据是完全没有丢失的，SQL Server 2016对AlwaysOn集群的内存优化表做了改进，支持在辅助副本上查询内存优化表数据

 

 

总结

 

实际上，如果大家对内存优化表研究比较深入的话，内存优化表实际上相当于把redis嵌入到SQL Server，再在上面加上事务等关系型数据库特性

因为两者实现的底层都是哈希表

 

注意：内存优化表跟redis一样，是纯内存操作的，所以机器内存不能太小，SQL Server在启动时候会把内存优化表数据库文件

里面的数据全部load入内存，朋友的redis服务器和SQL Server服务器都用的256G内存，内存还算足够

 

 

这篇文章写得比较粗糙，最后祝大家新年快乐！

 

 

 

 

 

参考文章

https://msdn.microsoft.com/en-us/library/dn635118(v=sql.120)

 

如有不对的地方，欢迎大家拍砖o(∩_∩)o 

本文版权归作者所有，未经作者同意不得转载。