积极答复者
用sql 2005 处理过10亿的数据量 应该注意什么?

问题
答案
-
以我的经验来看,10亿的数据大概在200G左右
按照20G一个库文件,先划分10个库文件,和一个主数据库文件。
可以使用分区表,或者直接分表存储,如果只是查询,每个表数据可以控制在1亿左右,如果有更新操作,数据最好控制在0.1亿左右。
服务要求尽可能多的内存(推荐64G内存以上)和最够的磁盘空间,如果有很复杂的运算,cpu也要强劲点(推荐2路8内核以上)
数据分析处理展现可以使用SSIS,SSAS,SSRS。
大致能说的就这些,有问题再问吧
family as water- 已标记为答案 WeiLin QiaoModerator 2011年5月11日 5:34
-
如果自己开发程序 处理过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、内存、网络以及实施的数据库安全配置等都可能直接或间接影响到数据库的使用和配置
- 已标记为答案 WeiLin QiaoModerator 2011年5月11日 5:34
全部回复
-
以我的经验来看,10亿的数据大概在200G左右
按照20G一个库文件,先划分10个库文件,和一个主数据库文件。
可以使用分区表,或者直接分表存储,如果只是查询,每个表数据可以控制在1亿左右,如果有更新操作,数据最好控制在0.1亿左右。
服务要求尽可能多的内存(推荐64G内存以上)和最够的磁盘空间,如果有很复杂的运算,cpu也要强劲点(推荐2路8内核以上)
数据分析处理展现可以使用SSIS,SSAS,SSRS。
大致能说的就这些,有问题再问吧
family as water- 已标记为答案 WeiLin QiaoModerator 2011年5月11日 5:34
-
如果自己开发程序 处理过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、内存、网络以及实施的数据库安全配置等都可能直接或间接影响到数据库的使用和配置
- 已标记为答案 WeiLin QiaoModerator 2011年5月11日 5:34