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

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

各个博客之间没什么关系，采用分库＋分表的方法应该是比较好的。
都不用按常用不常用分，简单地将博客分组就好了。

另外，因为业务逻辑比较简单，要处理千万记录以及数万活跃用户，
我觉得还是用JDBC＋mysql，自已从头构建一个应用服务器更好些。。

MySQL 5.1已经支持表分区了，拿100万行的表测试过（采用的是HASH），查询速度非常理想。

可以使用velocity模板，直接发布为html。

另外，je2里面有很多静态页面，不知道是如何自动生成的。看起来效果不错。
http://www.iteye.com/static.html

去mysql网站看了一下，PARTITION 的确很强，可以很好的利用磁盘，也方便mysql进行优化。待成熟后可以尝试使用到mysql节点上。

mysql帮助文档：http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-types

我以前用httpclient读页面，然后写成本地文件，少量的效果还不错（速度和静态页面效果都不错）。项目要定时循环读，结果后来因为任务多了quartz调度不了那么快，造成内存溢出。

没用过java，表是肯定要分的，具体怎么分要看你们的具体应用需求，分表后对外的读取接口可以封装起来，内部处理数据定位问题。cache尽量走内存少走文件，否则数量和访问量上去以后io也够受的。系统的几大模块间尽量独立，互相用消息队列异步通信。