数据库真的成为瓶颈了
不知道大家对此有何高见，当访问量突增时如何应付庞大的数据量。是否使用双主库，或者多主库来解决呢？而外国的这种高并发系统是如何实现的，也是这样的吗？希望大家多多谈谈意见
不知道大家对此有何高见，当访问量突增时如何应付庞大的数据量。是否使用双主库，或者多主库来解决呢？而外国的这种高并发系统是如何实现的，也是这样的吗？希望大家多多谈谈意见
另一种可能更容易实现的方式是划分数据库，比如每10000个客户使用一个数据库，平行部署多个数据库然后使用一个负载均衡前端。
2009年11月04日 14:17 "IceQi"的内容
最根本的方式是摆脱数据库的束缚，使用类似云的缓冲模式直接进行内存试的数据操作。
另一种可能更容易实现的方式是划分数据库，比如每10000个客户使用一个数据库，平行部署多个数据库然后使用一个负载均衡前端。
能否具体说一下，如何使用类似云的缓冲模式？
如果不是用数据库，如何来保证数据的完整性，以及能够生成复杂的报表等
[该贴被admin于2009-11-05 07:53修改过]
http://www.jdon.com/jivejdon/thread/37460
CAP原理回答了关于一致性问题。碎片划分数据库缺点：
Sharding会消耗很多关系数据库本身的优点，Sharding侵扰了业务逻辑，对业务逻辑设计进行了干涉
下面是分布式缓存 数据库碎片划分产品和非关系型的分布式key-value性能比较图：
[该贴被banq于2009-11-05 13:44修改过]
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，不过我有种跟好的想法，就是让一般数据库使用固态硬盘，这样就可以减少内存与硬盘的速度匹配问题，也可以达到内存数据库的效果，甚至更好，这个方案我还没有机会尝试。
如果有可能,尽量不要发生磁盘上的I/O,费用昂贵.
有兴趣的话,,可以看看豆瓣的洪强宁在InfoQ做的分享, 应该其中有很多可以借鉴的地方..
对业务部分做切分? 尽可能先切分耦合性较低的业务模块, 再将数据库中较大的字段如大文本(LOB)或者Text字段迁移到分布式文件系统上, 再在Web主机与数据库之间搭建一定的MemCached集群来降低大部分的读IO,
通过上述方式基本上就可以解决大部分网站的性能问题了,,Scalability是很重要, 但是在系统并不需要很高的Scalability的时候, 通过利用NoSQL或者类似的方案可能代价非常高昂, 重要的是设计的时候考虑将来可能如何走, 而不是在不需要的时候就急急的迁移上去..
2. 考虑索引，SQL优化，数据库数据及存储过程缓存
3. 考虑将数据表及索引分布到多个磁盘上，增加并发
4. 考虑连接池性能优化
5. 考虑在应用服务器端做数据库数据缓存，减少connection的数据传输。
6. 考虑Web server cache，例如，使用oscache缓存部分数据。
7. 考虑文本数据压缩传输。
8. 更细节的考虑还包括：设计及优化数据库缓存替换算法、数据预读取等等。
[该贴被starrabbit于2010-09-17 01:35修改过]
[该贴被starrabbit于2010-09-17 01:40修改过]