最近遇到一个问题,对四千W条数据的数据库进行更新 20delphigbg]

发布时间:2016-12-9 8:35:59 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"最近遇到一个问题,对四千W条数据的数据库进行更新 20delphigbg]",主要涉及到最近遇到一个问题,对四千W条数据的数据库进行更新 20delphigbg]方面的内容,对于最近遇到一个问题,对四千W条数据的数据库进行更新 20delphigbg]感兴趣的同学可以参考一下。

   由于我们是做服装生产管理系统的,我们的系统可以实时的收集到员工的生产每扎货的生产信息,一般二K人的客户,一个月收集到的数据是400万条,我们每个月初都需要计算每一扎货的生产时间(前一扎货的结束是本扎的开始,当然还得扣掉中间休息时间,第一扎货的开始时间取上班时间)而且还需要跟工序表计算每扎货的SAM以及单价。   1、现在遇到的问题是更新这么多数据该需要非常长的时间,有没有办法可以提速。   2、如果更新这么多数据会导致硬盘瓶劲,硬盘改写数据太多,磁盘读写速度跟不上。   3、这么多数据很容易产生锁,当然有的是旧锁,导致急时的数据采集上来时会超时。

升级软硬 索引 分区

如果为了系统稳定,就要控制并发了。 将用户操作分出优先级,加强控制。 牺牲速度

引用 2 楼 xys_777 的回复:如果为了系统稳定,就要控制并发了。 将用户操作分出优先级,加强控制。 牺牲速度。。

实时数据采集,RFID ?  每个月400万条数据量不算什么...但你要一次更新400万就是系统设计有问题.

引用 1 楼 yhtapmys 的回复:升级软硬 索引 分区 建议采用分区表来实现 http://blog.csdn.net/robinson_0612/archive/2009/11/07/4783702.aspx

1\分区表我也想过,只是客户买的是正版式的SQL,那个版本不知道分区表。 2\其实我也感觉没有必分每次重新分析上一个月的所有的数据,其实过前一天或是几天的问题就不大。如果太多确是有问题。因为其中有很多不确定因素。如月初改单价,要对上个月整个月生效。。所以没得办法。 3、我们做过测试,一台数据库服务器,经过测试一天可以达到300W条。这个我们对自己以及客户对我们的要求。

即使改400万条数据,耗时也不会很久呀。。。偶有时也改BOM,800多万 还有计件绩效,3千多万。。。呵 仔细规划设计,没那么恐怖。提供有偿支持 另:企业版支持分区

企业版当然是支持分区,我们这里的计算与实际应用并在一起的。什么都需要实时的。所以你修改时会锁定该表,而锁定该表,其它的插入或是修改无法操作。

以今天的软硬件技术发展来看 4千万条记录的表 也只能算普通,  把你的数据库结构写出来  并讲清 你需要得到什么样的结果 让大家给你评点 你才会有更大的进步,  不要怕丢脸  讲得透彻 理解深刻 你才会有进步 还让更多的人能学到东西  期待你早点 写出你现有的表设计及索引    和期待的结果 让我们也可以练练手

还有 SQL Server 2008 R2 新鲜出炉 火辣登场了 .  2000 实在是有些太老了.

   靠规划设计了,找平衡了

要末数据库设计有问题,要末就是对业务的理解有问题,需要重新进行抽象。

1:如果月与月之间数据没有联系的话,月初将上个月的数据库备份出来,找台机器去算。 2:如果没上面的条件的话,找闲的时候算 3:如果没有上面2个条件的话,每天算。

历史数据,即使要在同一个库,也可以放在另一个表,这样,更新它们是不影响当前表的

提高速度的办法是将数据文件和日志文件放到不同的盘中,同时创建索引,这样能加快你的访问速度,也能提高更新速度。

创建索引UPDATE会更慢,怎么可能提高UPDATE速度,晕

一次性更新绝对是设计上的问题

更新时把索引先关掉.

主要是每个人需要重算,这个跟管理有关。列在计算放在临时表单中都是很快的,就是那个update很慢。由于这个表单用的比较大,每天的实时数据都需要进该表单,而且需要通过该表单检查是否有重复的现象。这个跟检查表中是否重复的不一样。

无论怎么看,都是设计的问题。

I got it

能不能按照日期每天生成一个表,这样一个表中的数据就不会太大! 对表操作的冲突就会大大减少,不过这样做你的程序肯定也要相应的改动! 从固定操作一个表变成动态操作表!

 头疼的并发问题

这么好的问题不能让沉了,顶起来等高手解答

该回复于2010-09-02 10:23:08被版主删除

系统设计上有问题 把问题分散,不要把一个月的数据集中到一天处理

该回复于2010-09-29 14:00:49被版主删除

我也同意把问题分散

我同意散分,哈哈。

使用库表分组,

基于你的描述,你应该不想改变原有的处理方式,你建个job把数据分开来处理就可以了,比如在一天中娴时去更新部分数据,这样你不用专门一次性去处理了。400w应该是一个很小的数量级。

涉及到SQL SERVER 的并发和负载问题,,建议你用试试用DBTWIN来测试下系统的效率

上班已经说了很多,俺就不多说什么了。 就谈一下自己的看法吧。 如果是现有的需求不去改变,即:需要实时的数据更新,那么目前听你上述的一些信息中,磁盘IO以及服务器均不符合要求。或者说开始的设计就是拿一个平房的地基想去盖摩天大楼! 我的建议是: 如果业务不发生改变,硬件不更换的情况下,那么目前在软件层面是不可能达到你想要的结果,而随着时间的推移,即:数据量将不断增大,即便是分区也解决不了问题。想有所改善只有两条路,一是改变业务(也就是通过底层进行数据库优化以及业务优化),二是提升硬件,并在软件层做优化。

不能一下子更新这么多数据的,你要重新理下你的思路

非常感谢大家的支持,其实这个很大程度上依赖于IO,但是程序中的一些算法,也非常重要,有可能一个语句会搞死一个系统。   

你的设计很糟糕 所以你程序的运行有问题  但你从来不这样认为, 只能归咎于IO. 就你这点数据,我觉得再放大10倍甚至100倍可能也还是个小CASE. 把你的设计丢上来 再说出你要的结果 大家给你想办法 这里牛人多  这是提高的机会 对很多人来说都是 为什么不。。。。呢 我以过往的经历看来 这点数据处理起来要超过 5 分钟 那都是有罪的. 我看你都纠结了不止半年了 真辛苦。  是骡子是马 牵出来遛一下.

我估计 甚至有可能从冗余与范式的设计方面 甚至这些东西 根本不需要更新。 需要的时候 连接计算一下就好了。 如果这个数据库用 10年20年 或者 公司 业务有增长 这样的系统如何支撑? 这是垃圾 还是老牛拉破车 ?

钱是万能的,4kw条轻量级,告诉你们老板,只存在一个钱的问题,其他问题通通不存在

建立文件组,将数据文件分别放在不同的盘上,可以稍稍缓解磁盘读写的压力; 考虑调整数据库结构来根本解决。

固态硬盘!

更新价格体系就更新整个历史流水表 既然有这个需求,设计时候,就应该价格体系和销售流水分开,需要数据时候JOIN就可以了。修改价格,直接在价格体系里增加新的价格甚至修改原价格体系的价格,当然我喜欢增加新的价格执行区间,你的这个情况就不必要修改原价格,增加一个最新价格就OK了 总之不是SQL的问题,这个是软件设计的硬伤。

我的建议是 1.把该表建立分区。 2.然后对该表的每个分区,进行复制到不同的DB SERVER 3.在同一时间段进行并行计算。 4.然后再通过复制传回主数据库。 好处是复制修改数据,比你用SQL语句改,效率高多了。而且是并行计算。

我同意26楼的观点,不要把所有的数据集中到某一天来做,把计算数据的工作分到平时来做。

索引,分区来处理吧

非常感谢大家的支持。现在的数据量已经达到每天40W条。大家讲得都没有错,我承认设计上确是存在问题。现在有一二十间工厂在用,此时谈更改结构确是一件比较难的事情。如果有兴趣加和我们团队的可以留言给我。一起研究大型数据库。

才发现,我的回复似乎是回复错帖子了。

打破旧世界 建立新轶序. 我最喜欢干这种事情了。 十年前处理的数据库单表就达到 数千万级别,响应速度在秒级. 很多系统 运行近十年 以后 速度仍然不减。 历史数据连贯 没有任何结转 或者 移出. 光从SQL技术上来说 未必最顶级的. 从SQL技术与业务 结合方面 可能 最顶级的。 希望 我能有会 为此 出力 献策 联络方式  见用户ID.

如果楼主不想改变一个月分开每天处理的话,可以在当月收集的需要修改的数据当中增加日期字段,并在日期上增加索引,并通过循环语句一天天UPDATE,如果收集的数据(临时表)与历史表的结构是一样的话,在历史表当中建立与临时表对应的索引,我建议DELETE+INSERT..而且这个操作可以在写一个JOB在半夜进行。。

由于我们是做服装生产管理系统的,我们的系统可以实时的收集到员工的生产每扎货的生产信息,一般二K人的客户,一个月收集到的数据是400万条,我们每个月初都需要计算每一扎货的生产时间(前一扎货的结束是本扎的开始,当然还得扣掉中间休息时间,第一扎货的开始时间取上班时间)而且还需要跟工序表计算每扎货的SAM以及单价。   1、现在遇到的问题是更新这么多数据该需要非常长的时间,有没有办法可以提速。   2、如果更新这么多数据会导致硬盘瓶劲,硬盘改写数据太多,磁盘读写速度跟不上。   3、这么多数据很容易产生锁,当然有的是旧锁,导致急时的数据采集上来时会超时。    這個是一個非常有意思的問題,從決策和部署上考慮,可以參考: OLTP + OLAP 每一個ProductLine作為一個數據收集站點(部署一個Sub Server),使用批量Insert數據方法(e.g.生成批量的Insert T-SQL語句),再把各個站點數據同步到中央服務器(Data Central),同步頻率(1h or 30m Or 1/2Day 看實際情況需要),每月可以考慮使用SSAS來實現OLAP業務

感谢大家,现在我对数据结构做了一些优化,现在的数量量是一天42W条,系统运行正常。为了挑战更大数据量的要求,我们不仅修改数据结构,而且对我们的程序结构也做大的调整。最少应该可以应付一天二百W的数据量。关于现在的报表查询,我也考勤到用商业智能。正在学习这方面的资料。到时有问题再请教大家。

即使一天更新400W的数据 肯定是没有问题的,只要减少界面的显示很好做的,如果怕表被锁死,就分段执行,例如400W我每次只执行10W ,执行完成 在执行下一次的就可以了。

结贴了,先回复的才有分,如果没有拿到分的。表示歉意。

上一篇:将sql 2008 r2 中varbinary(max)类型数据转为xml格式文件,谁搞过。给点意见。 20分,无满意结帖,结帖人zhangtaoxgu]
下一篇:用SQL SERVER 2008的新功能 resource governor 40liuhuayang]

相关文章

相关评论