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

2018-06-17 23:22:46来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

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

 

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

大家知道,内存优化表作为In-Memory OLTP功能是从SQL Server 2014开始引入,用来对抗Oracle 12C的In-Memory OLTP选件

不过SQL Server的In-Memory OLTP功能是完全内置的功能,不像Oracle需要额外付费才能获得

由于是比较新的技术,可能大家对内存优化表还是比较陌生,网上也鲜有内存优化表使用场景的文章

朋友公司做的业务是跟蜂鸟配送类似的配送业务,整个配送系统平台每天订单量超过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内存,内存还算足够

 

 

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

 

 

 

 

 

参考文章

http://www.cnblogs.com/lyhabc/p/3691911.html

http://www.cnblogs.com/lyhabc/articles/4230547.html

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

 

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

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

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:mybatis interceptor 处理查询参数及查询结果

下一篇:MySQL的索引与优化