超大记录量数据库设计

以前没考虑过相关问题,刚开始想一个表保存用户,一个表保存操作记录等...随之问题就来了

初步估算如下:

初步估计每天活动用户2万,由于记录用户动态,

估计每个用户最少会产生20条以上行踪记录(里面包括很多东西,不描述)

最简单的估计每天都有40万记录,几年下来,呜呼哀哉~,表定挂.(没啥责任心的程序员估计也就按一个表做上去了.呵呵)

结果想的第一简单实现的方法被PK,

正郁闷的时候想了下,用户的这些动态基本上过了一定时间别人也可以不用知道啦,就是这些数据有时效性咯,马上上第二个解决方法,

根据当前时间,在原有表的名字上加上一个年月,按每个月一份表来储存,程序端判断表是否已建立,没建立建一个表.

这样估算即使每个月有1000多万数据也是没有问题的,因为这个数字在平稳过渡

这个刚搞定,用户留言等问题又出来了,因为留言没有哪个时效性,如果把留言这样来分割数据,那数据没法查了,加上在老的数据也要保存啊,完了,

上面的方法到用户交流这块有堵住了,在回想下,其实,无非就是不让一个表的数据过于庞大,而实现不要过于庞大的方法就是分割表,

(其实不少程序员把分割表的任务交给数据库管理员来实行,让他们去分割表,但我不想,呵呵),仔细想下,评论或留言的,肯定是对一个人或事物来的,

比如对一个人的留言,有了这个东东事情就好办了,我先对留言对象进行哈希(MD5),取得前一个字符(肯定是数字或字母),在原来留言这类的表名加上这个字符,

这样就把以前一个表保存的数据分到了36个表里面(估计会有多有少,没法了),表的记录会明显下降,实际取记录的时候在根据那个留言对象进行哈希得到表在去取记录

现在上面的问题都搞定了,现在发现还有一个问题,搜索,当要去搜索一个东东的时候发现很麻烦了,但搜索留言又要这个功能,发现要么就搜全文检索36个表,

要不然就做关键字列表,然后在弄个关键字与记录的权重关系表(TNND,这个表又大了,想在用上面的方法分表,呵呵),通过关键字来做搜索,但搜索这一块还没实现,麻烦~~

谁有更好的办法,给我提供下.万分感激~~~