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

int BatchInert ( string connectionString， string desTable， DataTable dt， int batchSize = 500 ) { using ( var sbc = new SqlBulkCopy (connectionString， SqlBulkCopyOptions .seInternalTransaction )

{

BulkCopyTimeout = 300 ，

NotifyAfter = dt. Rows . Count ，

BatchSize = batchSize，

DestinationTableName = desTable

})

{ foreach ( DataColumn column in dt. Columns )

sbc. ColumnMappings. Add (column. ColumnName ， column. ColumnName )；

sbc. WriteToServer (dt)；

} return dt. Rows . Count ；

}

存在什愦问题？

持续分表，我想到了，我们还可以按底层的采集器持续分表，因为采集设备在不合的采集器中是不合的，那么我们萌芽汗青曲线时，只有查单个指标的汗青曲线，那么如许就可以分散在不合的表中了。

膳绫擎的架构，在天天4切切的数据都是OK的。然则，调剂为上述背景下的设备时，集中监控法度榜样就内存溢出了，分析得知，接收的太多半据，放在了内存中，然则没有来得及写入到数据库中，最终导致了生成的数据大年夜于花费的数据，导致内存溢出，法度榜样无法工作。

瓶颈到底在哪里？

是因为RAID磁盘的问题？是数据构造的问题？是硬件的问题？是SQLServer版本的问题？是没有分区表的问题？照样法度榜样的问题？

当不时光只有一个礼拜，一个礼拜搞不好，项目监管就要我们滚蛋了，于是，有了持续工作48小时的豪举，有了到处打德律风求人的抓鸡……

然则，这个时刻须要的是沉着，再沉着……SQLServer版本？硬件？今朝都不大年夜可能换的。RAID磁盘阵列，应当不是。那么到底是什么，真TM的沉着不下来。

大年夜家可能领会不到现场那种重要的氛围，其实过了这么久，我本身也都很难再回到那种情境。然则可以这么说，或许我们如今有了各类办法，或者处于局外人我们有更多思虑，然则当一个项目榨取你快到放弃的时刻，你那时的设法主意、推敲在现场情况身分的制约下，都可能出现重大年夜的误差。有可能让你快速的思虑，也有可能思维停止。有些同事在这种高压的情况下，甚至出现了更多的初级缺点，思维已经完全乱了，效力更低了……36小时没有合眼，或者只在工地上（下雨天到处都是泥巴，干了的话到时都是泥灰）眯两三个小时，然后持续干，持续这么一个礼拜！或者还要持续！

很多人给了很多设法主意，然则似乎有效，又似乎没用。等等，为什么是“似乎有效，又似乎没用”？我模糊约约中，似乎抓住了一丝偏向，到底是什么？对了，验证，我们如今是跑在现场情况下，之前没有问题，不代表示在的压力下没有问题，要在一个大年夜型体系平分析这么个小功能，影响太大年夜了，我们应当分化它。是的，是“单位测试”，就是单个办法的测试，我们须要验证每个函数，每个自力的步调到底耗时在哪里？

2/5 首页上一页 1 2 3 4 5 下一页尾页

　　推荐阅读

　　数据中心“中庸”是王道?康普新品助数据中心网络效用最大化

开辟者大年夜赛路演 | 12月16日，技巧立异，北京不见不散【51CTO.com原创稿件】数据中间的收集经由多年的演进>>>详细阅读

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

地址：http://www.17bianji.com/lsqh/39583.html

1/2 1