海量数据性能优化措施

09-04-25 spikeme
大家一起讨论总结下海量数据性能优化措施有哪些,要求:

1. 最好是通用的优化措施,不是针对某个特定数据库的优化措施。如果针对某个特定数据库,则需要单独说明。

2. 这里说的性能优化:主要是查询性能,也包括增加,删除,更新数据时的性能。

4. 这里说的海量数据包括以下两种情况:

(1)上亿的数据量。

(2)百万到千万的数据量。

个人之所以这么分,是觉得这两种数量级,优化处理方法差别比较大的。

5.大家可以从硬件配置,数据库设计配置,SQL优化,程序优化等多方面考虑。

本人考虑主要有以下措施:

1.建立索引,根据不同的情况建立不同的索引,具体不细说。另外:sql server里有聚集索引和非聚集索引,oracle中对应的是什么索引,谁知道?

2.建立表分区,将分区对应的表空间存储在不同的磁盘上。、

3.分表:建立同样的表结构的表N个,存储不同范围的数据。

4.设计上拆分表:比如原来复杂的表,通过关联拆分成多个表,主表只保留主要字段。、

5.表的冗余设计。

6.设计性能优良的SQL语句。

先吃饭了,大家一起想想,还可以讨论的更细。

[该贴被admin于2009-04-26 08:35修改过]

2
beepbug
2009-04-26 07:03
楼主提出的问题,几乎囊括DB的所有技术,需要用几大本书来回答。楼主倒好,自己轻轻松松写了几个字,就跑去吃饭了,让我们饿着肚子写书?

BBS上,可以问各种各样的问题,深的、浅的、高的、低的,但有一限制,需要的回答只能是简短的。

楼主别心急,一点一点问。起一帖,问一点。

banq
2009-04-26 08:30
首先要采取切割方式,具体情况具体研究。

这些数据其实代表业务,能否根据业务划分子领域,找出核心领域,不能就数据论数据,没有一套裤子适合所有人穿,一定要打破那种学好一套数理化,走遍天下都不怕的僵硬解决问题的思路。

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

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

scalable伸缩性是软件的一个设计目标,如今分布式云计算非常廉价而且容易,google自己就用云计算树立了一个解决大数据的典范。

[该贴被banq于2009-04-26 08:38修改过]

spikeme
2009-04-26 10:44
谢谢楼上2位的关注。

谢谢Banq老师的回答。

其实我主要是想总结下而已,没有具体环境。总结些常用的解决方案。我不是说以后有场合就用,而是说,到了具体需要用的时候,知道从哪些方面着手,然后再具体问题具体分析。

另外:SQL SERVER 里的聚集索引对应到oracle中,有什么同样的功能呀。SQL SERVER 里的聚集索引就是根据数据存储的物理顺序建立索引,所以效率很高,也基于这个原因,所以每个表必须只有一个聚集索引,因此在需要用的时候,要好好规划,究竟哪个字段需要设置成聚集索引。。但是我现在用的最多的是oracle ,我想知道有什么类似的功能。

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

beepbug
2009-04-26 16:38
“就是根据数据存储的物理顺序建立索引”,这至少在Oracle里是内部的,对用户是透明的,你无须关心。

正规的数据库,这是最起码的事。

spikeme
2009-04-26 19:15
“就是根据数据存储的物理顺序建立索引”,这至少在Oracle里是内部的,对用户是透明的,你无须关心。

正规的数据库,这是最起码的事。

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

beepbug
2009-04-27 07:11
spikeme:Oracle有没有这个?

小沈阳:这个没有。

spikeme:这个可以有。

小沈阳:这个真没有。

没研究过MS SQL SERVER。如果真这样,那。。。

ACoder
2009-04-28 10:07
1、最简单的提升性能的方法就是提升硬件,增加硬件的投入效果立竿见影,不过这个主要是是投资方的可接受成本问题了。一般的来说从硬件方面的投资主要是购买大型机RS9000,购买磁盘柜(同时也是高可用的需要),增大内存。这些都可以提升系统的速度。

2、从软件方面来说首先应该尽量使用64位的数据库,同时数据库应当建立在裸设备上。

3、你说的确实是对的,对于亿级别的数据通常是历史数据,而百万以及千万级别的数据通常是交易数据,这两种确实有很大区别,历史数据多为了读取,交易数据通常是可修改的,在建立索引的时候要考虑插入的问题。

4、通常有表分区功能的数据库就不需要在设计上进行分表设计,只有在数据库系统不提供该功能的时候才会采用分表设计。分区要建立在不同的磁盘上以提升IO性能。

spikeme
2009-04-28 22:47
楼上说的很对,看来是经验比较丰富。另外,我想起,网上有谈过读写数据库分离技术,就是写数据放到一个库,读数据放到一个库。写数据库进行事务处理,读数据库主要进行SELECT查询,读数据库的数据主要是从写数据库复制过来的。大访问量的网站一般都进行过这样的处理。

谁做过这样的架构设计处理,谈谈感想。

banq
2009-04-29 09:10
>网上有谈过读写数据库分离技术,就是写数据放到一个库,读数据放到一个库

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

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

详见:http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23121918#23121918

[该贴被banq于2009-04-29 09:10修改过]

usejava
2009-04-29 09:57
需要多少内存?另外当数据库数据变化时,如何同步缓存?

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

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

banq
2009-04-29 11:04
>当数据库数据变化时,如何同步缓存

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

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

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

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

>共享内存肯定需要属于某一个设备,那么设备是否又成为单点

我们有分布式缓存 集群就是本质上分布式缓存,几台服务器内存集群在一起,就象一块大内存,任何一个点失败,都没有单点风险,其他机器顶上。

>这种技术的备份策略以及冗余策略有待于考察

缓存本身就解决了冗余,因为缓存里保存的是领域核心模型,是经常使用的,聚合边界就是解决冗余,保持精简模型。

猜你喜欢
6Go 1 2 3 4 ... 6 下一页