none
用sql 2005 处理过10亿的数据量 应该注意什么? RRS feed

  • 问题

  • 如果自己开发程序  处理过10亿的数据量  应该注意什么?如何设计 数据库? 才能达到最佳性能

    或着 帮小弟推荐 几个 能处理海量数据 的cms 或 电子商务系统?  

     

    谢谢各位

    2011年5月4日 3:37

答案

  • 以我的经验来看,10亿的数据大概在200G左右

    按照20G一个库文件,先划分10个库文件,和一个主数据库文件。

    可以使用分区表,或者直接分表存储,如果只是查询,每个表数据可以控制在1亿左右,如果有更新操作,数据最好控制在0.1亿左右。

    服务要求尽可能多的内存(推荐64G内存以上)和最够的磁盘空间,如果有很复杂的运算,cpu也要强劲点(推荐2路8内核以上)

    数据分析处理展现可以使用SSIS,SSAS,SSRS。

    大致能说的就这些,有问题再问吧


    family as water
    2011年5月4日 5:23
  • 如果自己开发程序  处理过10亿的数据量  应该注意什么?如何设计 数据库? 才能达到最佳性能

    或着 帮小弟推荐 几个 能处理海量数据 的cms 或 电子商务系统?  

     

    谢谢各位

     

    你的问题过于空洞,只能随便聊聊
    根据你说的系统都是OLTP数据库应用

    下面大致上谈一些值得重视的问题(个人见解,不要轻信,最好根据你的现场情况进行模拟验证):

    1. 确立服务等级协议:确定客户最终内接受的性能范围,这决定你如何去规划和建设你的应用程序

    2. 大数据量处理时分清两个主要问题:

     a 并行任务

     b 并发任务

    3. 在MSSQL 2005、2008、2008 R2的企业版、数据中心版本是支持并行的,这个无需做太多纠结,相关问题可以查阅MSDN或自己动手模拟一下就清楚了

    4. 关键问题在于数据的并发操作上,OLTP核心操作无非是UPDATE、DELETE、INSERT、SELECT,以及它的事务机制

    大数据量操作中性能影响最大的几个方面:

    UPDATE、DELETE:大批量UPDATE、DELETE,不可取,会导致锁等级提升,建议小循环UPDATE、DELETE,每次处理2000-5000行即可

    INSERT:两个方面主要影响:

       1. 索引维护:当大批量数据INSERT时,如果正巧你该对象索引非常多、且容量非常大的时候会出现长时间的提交等待(无论直接语句INSERT INTO ... ... SELECT ... ... FROM ...插入还是ETL都会触发这种情况);

       2。锁事务:为了保持事务完整性一般会加锁,尽可能地解决方案是相关数据分多个阶段小批量插入,尽可能避免频繁提交和大批量提交现象发生

    SELECT:根据常规做法:日数据增量>50W行的最好考虑分区,同时如果对此后有高性能查询需求的,可以考虑跨RAID组,以分摊IO,

                 同时也需要主要分区不是万能的,如跨多分区查询效果不一定比不分区查询快,且大SELECT也会产生锁阻塞数据变更,更详细的说明的可以查询msdn 或 google

    5. 除了应用程序SQL质量以外还得考虑其他因素:存储IO、CPU、内存、网络以及实施的数据库安全配置等都可能直接或间接影响到数据库的使用和配置

     

     

     

    2011年5月5日 5:29

全部回复

  • 这题真是"太难",路过
    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com
    2011年5月4日 4:27
  • 以我的经验来看,10亿的数据大概在200G左右

    按照20G一个库文件,先划分10个库文件,和一个主数据库文件。

    可以使用分区表,或者直接分表存储,如果只是查询,每个表数据可以控制在1亿左右,如果有更新操作,数据最好控制在0.1亿左右。

    服务要求尽可能多的内存(推荐64G内存以上)和最够的磁盘空间,如果有很复杂的运算,cpu也要强劲点(推荐2路8内核以上)

    数据分析处理展现可以使用SSIS,SSAS,SSRS。

    大致能说的就这些,有问题再问吧


    family as water
    2011年5月4日 5:23
  • 因为没有处理过上亿的数据,所以想问问如果 要处理海量数据的时候, 要注意什么、用什么方法 , 在系统运行起来 保证 对数据  检索  的速度   ,  目前的水平,我就知道缓存、索引、存储过程 之类的方法..
    2011年5月4日 6:04
  • Depends on what kind of prosess and transaction rate, there's no standard configuration for every VLDB.
    2011年5月4日 14:44
  • 太泛泛了,遇到瓶颈了吗?这些数据是怎么分布的?服务器的配置,负载情况 都要需要说清楚啊

     


    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com
    2011年5月4日 14:52
    版主
  • 如果自己开发程序  处理过10亿的数据量  应该注意什么?如何设计 数据库? 才能达到最佳性能

    或着 帮小弟推荐 几个 能处理海量数据 的cms 或 电子商务系统?  

     

    谢谢各位

     

    你的问题过于空洞,只能随便聊聊
    根据你说的系统都是OLTP数据库应用

    下面大致上谈一些值得重视的问题(个人见解,不要轻信,最好根据你的现场情况进行模拟验证):

    1. 确立服务等级协议:确定客户最终内接受的性能范围,这决定你如何去规划和建设你的应用程序

    2. 大数据量处理时分清两个主要问题:

     a 并行任务

     b 并发任务

    3. 在MSSQL 2005、2008、2008 R2的企业版、数据中心版本是支持并行的,这个无需做太多纠结,相关问题可以查阅MSDN或自己动手模拟一下就清楚了

    4. 关键问题在于数据的并发操作上,OLTP核心操作无非是UPDATE、DELETE、INSERT、SELECT,以及它的事务机制

    大数据量操作中性能影响最大的几个方面:

    UPDATE、DELETE:大批量UPDATE、DELETE,不可取,会导致锁等级提升,建议小循环UPDATE、DELETE,每次处理2000-5000行即可

    INSERT:两个方面主要影响:

       1. 索引维护:当大批量数据INSERT时,如果正巧你该对象索引非常多、且容量非常大的时候会出现长时间的提交等待(无论直接语句INSERT INTO ... ... SELECT ... ... FROM ...插入还是ETL都会触发这种情况);

       2。锁事务:为了保持事务完整性一般会加锁,尽可能地解决方案是相关数据分多个阶段小批量插入,尽可能避免频繁提交和大批量提交现象发生

    SELECT:根据常规做法:日数据增量>50W行的最好考虑分区,同时如果对此后有高性能查询需求的,可以考虑跨RAID组,以分摊IO,

                 同时也需要主要分区不是万能的,如跨多分区查询效果不一定比不分区查询快,且大SELECT也会产生锁阻塞数据变更,更详细的说明的可以查询msdn 或 google

    5. 除了应用程序SQL质量以外还得考虑其他因素:存储IO、CPU、内存、网络以及实施的数据库安全配置等都可能直接或间接影响到数据库的使用和配置

     

     

     

    2011年5月5日 5:29
  • 现在的云不就是解决这个问题的吗?

     


    学习无涯,游戏与白开水作伴。
    2011年5月9日 10:17
  • Cloud doesn't handle those issue automatically, still need proper processes in place.
    2011年5月9日 13:38
  • 你可以看下mongodb这方面的知识,能解决大数据量插入、查询、修改问题,也可以水平扩展。

    现在做的比较好的cms系统是dedecms系统php 的

    2012年5月21日 15:43