有关大数据量的问题

[wsh]

我在做一个数据库管理信息系统其中涉及特别大的数据量的问题。用的是Oracle数据库
，数据库不断膨胀,某些表一年后即可达到上百万条记录。但是程序中需要每天从部分数据中进行分类汇总统计因此速度特别慢，请问哪位仁兄有此方面的比较好的解决办理还请赐教。万分感激!

[Tyro]

oracle有一种数据分区的技术应该能够解决这种速度慢的问题！

[halfdream]

你可以去看一看关于数据仓库思想的书。
把事务型系统的同决策型数据从概念上分开。
至少很有启发价值。

[zzj_mjz]

可另建一汇总表,往明细表中插数据的同时也往汇总表中插,这样查询汇总信息时可从汇总表中读出,不过要注意保证数据的完整性.

[Axiong]

把表分离。按年或按月。这样速度就很快。我就是这样设计系统的。

[wsh]

非常感谢这么多兄长提供的答案。数据仓库我可以说一无所知，还有Tyro说的数据分区
技术不知所指是什么能否讲得更详细一些。
至于将数据表进行拆分倒也想过只是在涉及跨时间段进行统计分析时编程过于麻烦。

[Tommy Chang]

建表的时候，有个选项就是指定分区的。参见oracle文档。

[Tommy Chang]

数据仓库、数据挖掘、数据分析都是比较系统的解决方案。这些东西说新不新，但小弟尚一无所知，希望有这方面的大虾能指点一二。

不过在oracle里面，这个问题用数据分区都可以很好的解决，程序修改相对较小，分区的方法看你业务的要求如何。

[town]

我是一个非常现实的问题，可能需要数据库系统分析员级的人才能给出带经验的答案。我们公司有一个类似的数据库系统,也正在研究这个问题。
90分好象太少了。

[rosement]

不久前我也开发过这样的一个数据库，解决的办法是：
1 硬件方面，提高内存容量（这是最重要的），将更多的内存给予ORACLE固定使用。
2 数据库方面，拆分大型表单，使用分时间段数据库，我单位有一个巨型数据也是采用了这种方法！（这非常重要，速度可以提高几十倍左右）。
3 编程方面，尽量不要使用ODBC，采用ORACLE驱动编程，用ODBC太慢。加入每日的统计，加入到你的日报表中去，月底可以加入每月的报表等。
4 看书，查看ORACLE的书籍，对这方面问题应该会有很好的回答（看的书，应该在700页以上，以清华的书为佳）。

[huitor]

hi,

[Tommy Chang]

其实问题到了sundyl这里，已经提升到了一个高度了。
显然为了提高系统的性能，通常有几个办法
1。将所有相关的硬件升级，并尽最大可能减少每个瓶颈，诸如网络速度、硬盘速度等
2。选择稳定、高性能的软件支撑平台，比如选择数据库、应用服务器。。。
3。程序代码优化
4。将软件系统环境优化，例如索引、存储空间、临时空间、碎片整理等选项。

但毫无疑问，经验在这里起到决定性作用。如果sundyl大虾，能够再举出几个案例，就最好了。

:)

[wsh]

sundyl的一番话，真是令我受益不少，在数据库性能优化方面，我还只是个菜鸟级的人
物，对于提高查询速度，所知也只是将要查询的条件字段建立一番索引，以为就此便万
事大吉，却不知还有如此多的东东。不知列位兄长能否为小弟在此方面的学习指点一二。
给我指条路，不甚感激!

[sundyl]

我认为数据分区、分成多个表、增加内存、换更好的机器都是物理上的，当然她带来的速度的改善是有的。但是性能的改善一般比较少做多10倍到100倍之间。
对Oracle我不熟悉，但在SQL Server中最有效和可行的办法是优化数据库结构和索引。
对于优化数据库有根据事务型和数据仓库型分为两个方面。
偏重事务需要插入、更新速度快，所以一般这样的表索引比较少，字段数目也少
数据仓库需要查询速度快，他一般会根据查询可能出现的条件建立所有的索引，形成所谓的索引覆盖。在大数据量的数据库中，一旦某个查询不能完全利用索引，就会形成表扫描。这是最坏的情况，查询速度同数据量成正比。而如果能完全利用索引，查询速度只有在数据量变化几个等级才会有一些变化。我曾经测试过一个库存表150条记录，索引建立不好一个查询需要4分钟，对索引优化以后1秒不到。如果数据单纯作为查询可以取消对该表的日志功能。
我一般是分成两个库，一个处理事务，一个处理查询，然后建立一个定期事务把事务数据增加到查询库中。

总的来说，只有才所有软的手段不能解决问题的情况下才采用物理的方法。但是物理的方法也不是单纯增加应加的配置。一般有以下几个手段
1。把日志放到另外的硬盘上
2。把修改最频繁的表放到另外的硬盘上、甚至放入内存中
3。采用更快的硬盘
4。增加更多内存
5。增加CPU数目
6。建立数据库服务器集群

数据库的优化是一门很专业的学问，这又你充分的了解数据在数据库中存储的结构，查询、修改的处理方式同时又了解业务才可能做好。我们应该花20%的精力去解决那些最关键最常用的地方。

希望能有更多的人参与讨论，一点议论不要见笑。

[sundyl]

不好意思，上面所说是150万不是150

[sundyl]

另外如果你的分类汇总是按时间、客户、商品等一定要处理好几个索引的主次问题，必要的时候可以采用数据库专门的语法强行指定查询采用索引的顺序。思想是能最大限度的划分数据的索引优先使用。在SQL server中有族索引的概念，我一般把她留给那些经常按范围查询的字段。而且在条件部分最好不要有计算和通配符，这会大大影响速度。
要充分提高速度程序的修改是必然的，我个人认为在简洁易懂和快速高效这两个之间作平衡的才是数据库应用的最大乐趣。

[swordmanli]

sundyl果然是数据库的专业人士,他的建议颇有含金量.但在这个问题上,我认为halfdream关于数据仓库的提议更合适这个问题的解决.因为OLTP和OLAP在性能上有根本性的冲突,而你所说的'分类汇总统计'更象是一个数据仓库改做的事,虽然有可能你们不会在为此而重新设计一套数据仓库的方案,但至少可以象halfdream提到的用数据仓库的思维来实现你的需求.