海量数据性能优化措施

大家一起讨论总结下海量数据性能优化措施有哪些，要求：
1. 最好是通用的优化措施，不是针对某个特定数据库的优化措施。如果针对某个特定数据库，则需要单独说明。
2. 这里说的性能优化：主要是查询性能，也包括增加，删除，更新数据时的性能。
4. 这里说的海量数据包括以下两种情况：
（1）上亿的数据量。
（2）百万到千万的数据量。
个人之所以这么分，是觉得这两种数量级，优化处理方法差别比较大的。
5.大家可以从硬件配置，数据库设计配置，SQL优化，程序优化等多方面考虑。
本人考虑主要有以下措施：
1.建立索引，根据不同的情况建立不同的索引，具体不细说。另外：sql server里有聚集索引和非聚集索引，oracle中对应的是什么索引，谁知道？
2.建立表分区，将分区对应的表空间存储在不同的磁盘上。、
3.分表：建立同样的表结构的表N个，存储不同范围的数据。
4.设计上拆分表：比如原来复杂的表，通过关联拆分成多个表，主表只保留主要字段。、
5.表的冗余设计。
6.设计性能优良的SQL语句。
先吃饭了，大家一起想想，还可以讨论的更细。
[该贴被admin于2009-04-26 08:35修改过]

楼主提出的问题，几乎囊括DB的所有技术，需要用几大本书来回答。楼主倒好，自己轻轻松松写了几个字，就跑去吃饭了，让我们饿着肚子写书？
BBS上，可以问各种各样的问题，深的、浅的、高的、低的，但有一限制，需要的回答只能是简短的。
楼主别心急，一点一点问。起一帖，问一点。

首先要采取切割方式，具体情况具体研究。
这些数据其实代表业务，能否根据业务划分子领域，找出核心领域，不能就数据论数据，没有一套裤子适合所有人穿，一定要打破那种学好一套数理化，走遍天下都不怕的僵硬解决问题的思路。

性能之所以优化，而不是提升，是因为优化这个概念中就有天花板，也就是说：总有一天优化不下去。

大数据量的性能提升就是将数据从数据库这个盒子里面拿出来，重点研究解决，而不是隔着靴子(具体数据库产品)挠痒痒，这是基本逻辑，先把方向选定，别急着讨论技术细节，否则南辕北辙。

scalable伸缩性是软件的一个设计目标，如今分布式云计算非常廉价而且容易，google自己就用云计算树立了一个解决大数据的典范。
[该贴被banq于2009-04-26 08:38修改过]

谢谢楼上2位的关注。
谢谢Banq老师的回答。
其实我主要是想总结下而已，没有具体环境。总结些常用的解决方案。我不是说以后有场合就用，而是说，到了具体需要用的时候，知道从哪些方面着手，然后再具体问题具体分析。
另外：SQL SERVER 里的聚集索引对应到oracle中，有什么同样的功能呀。SQL SERVER 里的聚集索引就是根据数据存储的物理顺序建立索引，所以效率很高，也基于这个原因，所以每个表必须只有一个聚集索引，因此在需要用的时候，要好好规划，究竟哪个字段需要设置成聚集索引。。但是我现在用的最多的是oracle ，我想知道有什么类似的功能。

banq老师说的云计算，其实我也是去年才听说过，但是具体不太清楚，好象云就是虚拟资源，通常为一些大型服务器集群，包括计算服务器、存储服务器、宽带资源等等。不过总体来说，我觉得还是网上的资料说得都比较专业，比较抽象，换句话说，比较难以理解，banq老师能否给我们一个详细的解释，最好用简单的项目例子说明，谢谢。比如我们在什么样的项目需求上需要用，怎么做，谢谢了。

“就是根据数据存储的物理顺序建立索引”，这至少在Oracle里是内部的，对用户是透明的，你无须关心。
正规的数据库，这是最起码的事。

根据数据存储的物理顺序建立索引 SQL SERVER里的聚集索引就是这个意思

spikeme：Oracle有没有这个？
小沈阳：这个没有。
spikeme：这个可以有。
小沈阳：这个真没有。
没研究过MS SQL SERVER。如果真这样，那。。。

1、最简单的提升性能的方法就是提升硬件，增加硬件的投入效果立竿见影，不过这个主要是是投资方的可接受成本问题了。一般的来说从硬件方面的投资主要是购买大型机RS9000,购买磁盘柜（同时也是高可用的需要），增大内存。这些都可以提升系统的速度。
2、从软件方面来说首先应该尽量使用64位的数据库，同时数据库应当建立在裸设备上。
3、你说的确实是对的，对于亿级别的数据通常是历史数据，而百万以及千万级别的数据通常是交易数据，这两种确实有很大区别，历史数据多为了读取，交易数据通常是可修改的，在建立索引的时候要考虑插入的问题。
4、通常有表分区功能的数据库就不需要在设计上进行分表设计，只有在数据库系统不提供该功能的时候才会采用分表设计。分区要建立在不同的磁盘上以提升IO性能。

楼上说的很对，看来是经验比较丰富。另外，我想起，网上有谈过读写数据库分离技术，就是写数据放到一个库，读数据放到一个库。写数据库进行事务处理，读数据库主要进行SELECT查询，读数据库的数据主要是从写数据库复制过来的。大访问量的网站一般都进行过这样的处理。
谁做过这样的架构设计处理，谈谈感想。

>网上有谈过读写数据库分离技术，就是写数据放到一个库，读数据放到一个库

很有意思，我们在另外一个帖子也在讨论读写分离，写是写到数据库，用事务，这是共同的，但是区别读，我们是通过在中间件服务器中建立一个跨服务器的大内存缓存(可以想象成另外一个库)，这样就巧妙解决复制的即时性和频率问题。

用缓存处理读就是打破数据库的盒子，读写分离不一定要分开两个数据库啊。

详见：http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23121918#23121918
[该贴被banq于2009-04-29 09:10修改过]

需要多少内存？另外当数据库数据变化时，如何同步缓存？

我没有使用过数据库读写分离的技术，不过从我的经验来想，这种技术大多为了读多写少的应用准备的，是否使用这种技术应当适当考虑一下自己的应用是否是这一类型的。而且这两个数据库之间的同步也是需要成本的，那么用户对于实时性要求是不是很高。这些都是需要考虑的问题。如果数据量不是很大，这个基本上不需要。

banq说的那种技术不适合这种数据量的访问，最起码现在不适合，首先共享内存肯定需要属于某一个设备，那么设备是否又成为单点，其二这种技术的备份策略以及冗余策略有待于考察，如果数据量很大，那么怎么备份，全备份还是增量备份？？如果一旦有内存出现故障怎样进行保证数据完整性。

>当数据库数据变化时，如何同步缓存
数据库数据为什么会变化，首先因为是缓存里对象发生变化，所以，缓存变化是在数据库变化之前，一定要改变这种习惯思维。

那么如何更新缓存中变化的对象，那么就涉及到了我们正在讨论的那个帖子：http://www.jdon.com/jivejdon/thread/36063.html

一定要清楚了解缓存中保存的不是碎片数据，而是反映需求核心模型的聚合根实体和它的边界内子对象群，所以，同步缓存这些对象群时，遵循DDD要求的不变性和一致性。

当更新完成内存中聚合对象群以后，再通过一个专门机制sync将数据库向缓存看齐，更新数据库。

>共享内存肯定需要属于某一个设备，那么设备是否又成为单点
我们有分布式缓存集群就是本质上分布式缓存，几台服务器内存集群在一起，就象一块大内存，任何一个点失败，都没有单点风险，其他机器顶上。

>这种技术的备份策略以及冗余策略有待于考察
缓存本身就解决了冗余，因为缓存里保存的是领域核心模型，是经常使用的，聚合边界就是解决冗余，保持精简模型。