你好,游客 登录
背景:
阅读新闻

Sqlserver 高并发和大数据存储方案

[日期:2017-01-11] 来源:  作者: [字体: ]

Sqlserver 高并发和大数据存储方案 

随着用户的日益递增,日活和峰值的暴涨,数据库处理性能面临着巨大的挑战。下面分享下对实际10万+峰值的平台的数据库优化方案。与大家一起讨论,互相学习提高!

案例:游戏平台.

1、 解决高并发

当客户端连接数达到峰值的时候,服务端对连接的维护与处理这里暂时不做讨论。当多个写请求到数据库的时候,这时候需要对多张表进行插入,尤其一些表 达到每天千万+的存储,随着时间的积累,传统的同步写入数据的方式显然不可取,经过试验,通过异步插入的方式改善了许多,但与此同时,对读取数据的实时性也需要做一定的牺牲。

异步的方式有很多,目前采取的方式是通过作业每隔一段时间(5min、10min..看需求设定)将临时表的数据转到真实表。

1.已有原始表A 也是在读取的时候真正用到的表。

2.建立与原始表A同结构的B和C,用来作数据的中转处理,同步流程是C->B->A。

3.建立同步数据的作业Job1和记录Job1运行状态的表,在同步的时候比较 关键 的是需要检查Job1的当前状态,如果当前正在将B的数据同步到A,则把服务端过来的数据存到C,然后再把数据导入到B,等到下一次Job执行的时候再将这批数据转到A。如图1:

图1

同时,为保万无一失和便于排查问题,应该用一个记录整个数据库实例的存储过程,在较短的时间检查作业执行结果,如果遇到异常失败的,应该及时通过其他方式通知到相关人员。如写入到发邮件和短信表,让一个Tcp的通知程序定时读取发送等等。

注:如果一天的数据达到几十个G,如果又对这个表有查询要求(分区下面会提到),下策之一:

可将B同时同步到多台服务器分担下查询压力,减少资源的竞争。因为整个数据库的资源是有限的,如插入操作,会先获得一个共享锁,然后通过聚集索引定位到某一行数据,再升级为意向锁,而sqlserver对锁的维护根据数据的大小需要申请不同的内存,造成了资源的竞争。所以应该尽可能的将读和写分开,可根据业务模型分,可根据设定的规则分;在平台性的项目中应该优先保证数据能有效的插入。

在不可避免的查询大数据肯定会耗用大量的资源,如遇到批量删除的时候,可以换成以循环分批次(如一次2000条)的方式,这样不至于这个进程导致整个库挂掉,衍生出一些无法预计的bug。经实践,有效可行,只是牺牲了存储空间。也可根据查询需求将表里数据量大的字段拆分出来到新表,当然这些也要根据每个业务场景结合需求来设定,设计出适合而并不需要华丽的方案即可。

2、 解决存储问题

如果每天单表的数据都达到了几十个G,改善存储方案自然迫不及待了。现分享下自有的方案,在暴涨的数据摧残之下,仍坚守在一线!现举例对自有环境分享拙见:

现有数据表A,单表每天新增数据30G,在存储的时候采用异步将数据同步的方式,有的不能清除数据的表,在分区后还可分文件组,将文件组分配到不同的磁盘中,减少IO资源的竞争,保障现有资源的正常运行。现结合需求保留历史数据5天:

1这时需要通过作业job根据分区函数去生成分区方案,如根据userid或者时间字段来分区;

·   2.将表分区后,查询可以通过对应的索引,快速定位到某一段分区;

3通过作业合并分区将不要的分区数据转移到相同结构和索引的表,然后清除这个表的数据。

如图2:

图2

通过sql查询跟踪捕捉到查询耗时长的,以及通过sql自带的存储过程sp_lock或视图dm_tran_locks、dblockinfo查看当前实例存在的锁的类型和粒度。

定位到具体的查询语句或者存储过程之后,对症下药!药到病除!

当然,仁者见仁,智者见智-_-

收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款
热门评论