对于应用高并发，DB千万级数量该如何设计系统哪？

[b]背景：[/b] 博客类型的应用，系统实时交互性比较强。各种统计，计数器，页面的相关查询之类的都要频繁操作数据库。数据量要求在千万级，同时在线用户可能会有几万人活跃。系统现在是基于spring + hibernate + jstl + mysql的，在2千人在线，几十万记录下没有什么压力。可对于千万记录以及数万活跃用户没什么经验和信心。 对于这些，我的一点设计想法与问题，欢迎大家指导： [b]一. 加强cache[/b] 由于web2类型的网站，用squid反向代理可能不是很适用；由于这种情况下需要cluster，jvm上作过多cache可能会引起其他问题；所以比较合适的应该是采用静态发布的方式，把数据发布成xml文件，然后通过xml + xslt 拼接各模块(div)显示。（直接发布成html文件用jstl感觉不是很方便，也没用过，请有经验的介绍下），主要目的就是把压力拦截在Apache上。或者用memcached cache文章内容，用户资料等对象。 [b]二. 数据库分库[/b] 分库有两种，一种是分表，把经常访问的放一张表，不常访问的放一张表。 好比对于博客，文章表可以分为文章基本信息（标题，作者，正文……）不常改动的信息，和文章统计信息（阅读次数，评论次数……）经常变动的信息，以期望update统计信息之类的可以快一点（这个东西实践起来弊端也会比较明显：查询文章时需要多查询一次统计信息表，到底能不能提高性能还没有具体数据，欢迎有经验的给点数据：） ）。 对于记录过多，好比千万级，这样的分法显然也解决不了问题，那么就需要归档处理了。归档大致就是创建一个同样的表，把旧内容（好比三个月以前的）都移到旧表里面，保持活跃的表记录不多。（mysql本身有一个archive引擎，看资料感觉对解决大量数据没什么用处，连索引都不支持，用过的朋友可以给点建议）。归档带来的最大问题就是：归档以后的数据如何访问哪？如果用户要访问以前的数据就会比较麻烦了。（mysql的merge查询？）大家这方面有没有好的practice？我还没想到好的办法。 分库的另外一种方式是物理的分，就是装他几十台mysql服务器，然后按照某种方式把数据分散到不同的服务器上，这种方式也有利于备份恢复和系统的稳定性（一台数据库宕了，也只会影响一部分功能或用户）。例如对于博客应用，比较理想的分库模式可以按照用户分，好比我把用户id在1…10万的资料都存到mysql1上，把10万。。。20万的存到mysql2….，依次类推，通过线性增加服务器的方式解决大数据问题。 呵呵，还算完美吧~~，就是给统计排名带来了麻烦…… 按照第二种分库方式，数据库连接将发生变化，如果数据达到千万，10几个mysql应该是需要的，这时候连接池就要废掉了，采用每次查询取链接的方式。或者需要改造出一个特别的连接池了。 [b]三．采用Ibatis[/b] 把hibernate废掉，改用ibatis，毕竟ibatis可以很方便的进行sql优化，有什么问题优化起来方便多了（还没有用过ibatis，只是感觉）。另一方面，如果物理分库有效果，好像严格的sql优化意义也就不大了。这应该也是一个优化方面。 总结一下我的结构：把文章，用户资料，各种分类，tag, 链接，好友之类的进行静态化（xml + xslt 读取显示） + 物理分库 + ibatis sql优化 + JVM短暂性的cache总的用户数，在线用户数等极个别数据，其他的全部不cache（包括关闭hibernate二级缓存，如果用hibernate）