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

首要声明，我仅仅个程序员，不是专业的DBA，以下这篇文章是从一个疑问的处理进程去写的，而不是一开端就给咱们一个准确的成果，假如文中有不对的地方，请各位数据库大牛给予纠正，以便我能够更好的处理这次事务。

项目布景

这是给某数据中心做的一个项目，项目难度之大令人发指，这个项目真实的让我感受到了，商场如战场，而我仅仅其间的一个小兵，太多的战术，太多的高层之间的比赛，太多的内情了。详细这个项目的状况，我有空再写有关的博文出来。

这个项目是请求做环境监控，咱们暂时把受监控的设备称为收集设备，收集设备的特点称为监控目标。项目请求：体系支撑不少于10w个监控目标，每个监控目标的数据更新不大于20秒，存储推迟不超越120秒。那么，咱们能够经过简略的核算得出较抱负的状况——要存储的数据为：每分钟30w，每个小时1800w，也即是天天4亿3千两百万。而实践，数据量会比这个大5%摆布。（实践上大多数是信息废物，能够经过数据压缩进行处理的，可是他人即是要搞你，能咋办）

上面是项目请求的目标，我想许多有不少大数据处理经历的同学都会呲之以鼻，就这么点？嗯，我也看了许多大数据处理的东西，可是之前没处理过，看他人是头头是道，啥分布式，啥读写别离，看起来的确很容易处理。可是，疑问没这么简略，上面我说了，这是一个十分恶劣的项目，是一个职业恶性竞争典型的项目。

1. 没有更多的效劳器，而是这个效劳器除了调配数据库、会集收集器(即是数据解析、告警、存储的程序)，还要支撑30w点的北向接口(SNMP)，在程序没有优化之前CPU终年占用80%以上。由于项目请求要运用双机热备，为了省劲，削减不必要的费事，咱们把有关的效劳放在一同，以便能够充分利用HA的特性（外部采购的HA体系)
   
2. 体系数据准确性请求极端变态，请求从底层收集体系到最上层的监控体系，一条数据都不能差
   咱们的体系架构如下，能够看到，其间数据库压力十分之大，尤其在LevelA节点：
   
   
3. 硬件装备如下：
   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.
   
4. 数据库版别
   选用的是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,