数据库真的成为瓶颈了

09-11-03 forest3000
                   

自从工作后,有机会接触到了高并发,大数据量的系统。最近由于业务量的突增,数据量变的很大,我们的系统是1个主数据库带多个从库。插入和删除都要在主库上进行,而查询的时候则随机使用主库和从库。最近由于数据量的突增,因此主库变成了瓶颈,为了能够支撑系统,只能使用更好的主机。目前进行了测试,虽然更换了很好的主机,但是性能提高并不是很明显,所以比较郁闷。

不知道大家对此有何高见,当访问量突增时如何应付庞大的数据量。是否使用双主库,或者多主库来解决呢?而外国的这种高并发系统是如何实现的,也是这样的吗?希望大家多多谈谈意见

                   

1
IceQi
2009-11-04 14:17

最根本的方式是摆脱数据库的束缚,使用类似云的缓冲模式直接进行内存试的数据操作。

另一种可能更容易实现的方式是划分数据库,比如每10000个客户使用一个数据库,平行部署多个数据库然后使用一个负载均衡前端。

forest3000
2009-11-04 19:09

2009年11月04日 14:17 "IceQi"的内容
最根本的方式是摆脱数据库的束缚,使用类似云的缓冲模式直接进行内存试的数据操作。

另一种可能更容易实现的方式是划分数据库,比如每10000个客户使用一个数据库,平行部署多个数据库然后使用一个负载均衡前端。

能否具体说一下,如何使用类似云的缓冲模式?

如果不是用数据库,如何来保证数据的完整性,以及能够生成复杂的报表等

[该贴被admin于2009-11-05 07:53修改过]

banq
2009-11-05 09:29

见这篇新文章:

http://www.jdon.com/jivejdon/thread/37460

CAP原理回答了关于一致性问题。碎片划分数据库缺点:

Sharding会消耗很多关系数据库本身的优点,Sharding侵扰了业务逻辑,对业务逻辑设计进行了干涉

下面是分布式缓存 数据库碎片划分产品和非关系型的分布式key-value性能比较图:

[该贴被banq于2009-11-05 13:44修改过]


tuhaitao
2010-01-09 00:59

1.查看下数据库最大连接数是否够用,mysql默认是100,并发量大的时候不够用

2.查看下你的连接池,是否有限制,Jboss一般默认是10个,这是很大的瓶颈

3.给你的JVM多分配点内存,一般是物理主机的3/4,前提是这台物理机器只跑jvm

4.查看下你的sql是不是都按照索引查找数据,或者已经做了索引的数据被频繁更新,这会造成数据库维护索引开销增大

(可以考虑换字段查数据)

5.给你的Tomcat或者Jboss更多的工作线程,tomcat,jboss web默认都是200的线程池,很不够用

6.如果你的静态文件过多,可以考虑apache或者nignx做前端负载均衡,后边挂多个tomcat或jboss

7.如果并发量还是大apache与nignx不能满足简单负载均衡,或者反响代理,可以采用更底层的LVS在ip层负载,如果公司舍得烧钱,用F5-BIG + LVS + DNS轮训,跑并发是没有问题了看己集群的数量

8.数据库做那种主从实在是看不过去,太土了,而且抗灾性能超差,可以考虑在底层共享存储比如向NFS或者GFS这样的,如果有钱可以搞磁阵+交换机。

9.如果数据库还是慢,你可以考虑采用内存数据库,比如Oracle 2005年收购的timesden,处理sql的速度是Oracle的1/1000,而且支持sql,HA,并且能自动同步后台Oracle DB,不过我有种跟好的想法,就是让一般数据库使用固态硬盘,这样就可以减少内存与硬盘的速度匹配问题,也可以达到内存数据库的效果,甚至更好,这个方案我还没有机会尝试。

2Go 1 2 下一页