我是如何在 SQL Server 中处理每天四亿三千万记录的？

开辟者大年夜赛路演 | 12月16日，技巧立异，北京不见不散

项目背景

这个项目是请求做情况监控，我们暂且把受监控的设备称为采集设备，采集设备的属性称为监控指标。项目请求：体系支撑不少于10w个监控指标，每个监控指标的数据更新不大年夜于20秒，存储延迟不跨越120秒。那么，我们可以经由过程简单的计算得出较幻想的状况——要存储的数据为：每分钟30w，每个小时1800w，也就是天天4亿3千两百万。而实际，数据量会比这个大年夜5%阁下。（实际上大年夜部分是信息垃圾，可以经由过程数据紧缩进行处理的，然则别人就是要搞你，能咋办）

膳绫擎是项目请求的指标，我想很多有不少大年夜数据处理经验的同窗都邑呲之以鼻，就这么点？嗯，我也看了很多大年夜数据处理的器械，然则之前没处理过，看别人是头头是道，什么分布式，什么读写分别，看起来确切很轻易解决。然则，问题没这么简单，膳绫擎我说了，这是一个异常恶劣的项目，是一个行业恶性竞争典范的项目。

没有更多的办事器，而是这个办事器除了搭配数据库、集中采集器(就是数据解析、告警、存储的法度榜样)，还要支撑30w点的北向接口(SNMP)，在法度榜样没有优化之前CPU常年占用80%以上。因为项目请求要应用双机热备，为了省事，削减不须要的麻烦，我们把相干的办事放在一路，以便可以或许充分应用HA的特点（外捕钥跪的HA体系)
体系数据精确性请求极其掉常，请求大年夜底层采集体系到最上层的监控体系，一条数据都不克不及差

我们的体系架构如下，可以看到，个中数据库压力异常之大年夜，尤其在LevelA节点：

硬件设备如下：

CPU：英特尔？至强？处理器 E5-2609 (4核， 2.40GHz， 10MB， 6.4 GT/s)

内存：4GB (2x2GB) DDR3 RDIMM Memory， 1333MHz，ECC

精确的建立索引

硬盘：500GB 7200 RPM 3.5’’ SATA3 硬盘，Raid5.

数据库版本

采取的是SQLServer2012标准版，HP供给的┞俘版软件，缺乏很多企业版的NB功能。

写入瓶颈

起首碰到的第一个拦路虎就是，我们发明现有的法度榜样下，SQLServer根本处理不了这么多的数据量，具体情况是如何的呢？

我们的存储构造

一般为了存储大年夜量的汗青数据，我们都邑进行一个物理的分表，不然天天上百万条的记录，一年下来就是几亿条。是以，本来我们的表构造是如许的：

CREATE TABLE [dbo].[ His20140822 ]( 
    [ No ] [bigint] IDENTITY( 1 ， 1 ) NOT NULL， 
    [ Dtime ] [datetime] NOT NULL， 
    [ MgrObjId ] [varchar]( 36 ) NOT NULL， 
    [ Id ] [varchar]( 50 ) NOT NULL， 
    [ Value ] [varchar]( 50 ) NOT NULL， CONSTRAINT [PK_His20140822] PRIMARY KEY CLUSTERED 
(     [ No ] ASC )WITH (PAD_INDEX = OFF， STATISTICS_NORECOMPUTE = OFF， IGNORE_DUP_KEY = OFF， ALLOW_ROW_LOCKS = ON， ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY]

No作为独一的标识、采集设备Id(Guid)、监控指标Id(varchar(50))、记录时光、记录值。并以采集设备Id和监控指标Id作为索引，以便快速查找。

批量写入

写入当时是用BulKCopy，没错，就是它，号称写入百万笔记录都是秒级的

public static	
			 1/5    1 2 3 4 5 下一页 尾页	
			

　　推荐阅读
　　数据中心“中庸”是王道?康普新品助数据中心网络效用最大化
            开辟者大年夜赛路演 | 12月16日，技巧立异，北京不见不散
            
                
                    
                
                【51CTO.com原创稿件】数据中间的收集经由多年的演进>>>详细阅读


本文标题：我是如何在 SQL Server 中处理每天四亿三千万记录的？
地址：http://www.17bianji.com/lsqh/39583.html
 1/2    1