大数据量的存储分表

 

 

参考财务帐套都是按年度的，有专门的设计规范。

 

帐套就是把数据分开保存的一个标志了
比如帐套表

ztid  zt
1    2002年帐套
2    2003年帐套
3    2004年帐套


根据这个把数据分类。也就是说所有的数据必须指定所属帐套。帐套即存储在电子计算机存储设备或介质中的用以记录一套帐务数据用的电子计算机电子文件的集合.

   故在设计时主要考虑：
1、在技术上实现数据据的自动建立功能；
2、在用户需求方面考虑：
   a)系统服务器参数配置；
   b)数据库参数配置；
   c)业务信息参数配置；

 

 

 

当一个应用的数据量大的时候，我们用单表和单库来存储会严重影响操作速度，如mysql的myisam存储，我们经过测试，200w以下的时候，mysql的访问速度都很快，但是如果超过200w以上的数据，他的访问速度会急剧下降，影响到我们webapp的访问速度，而且数据量太大的话，如果用单表存储，就会使得系统相当的不稳定，mysql服务很容易挂掉。所以当数据量超过200w的时候，建议系统工程师还是考虑分表.

 

以下是几种常见的分表算法。

 

1.按自然时间来分表/分库;

 

如一个应用的数据在一年后数据量会达到200w左右，那么我们就可以考虑用一年的数据来做为一个表或者库来存储，例如，表名为app，那么2010年的数据就是app_2010，app_2011;如果数据量在一个月就达到了200w左右，那么我们就可以用月份来分，app_2010_01，app_2010_02.

 

2.按数字类型hash分表/分库;

 

如果我们要存储用户的信息，我们应用的注册量很大，我们用单表是不能满足存储需求的，那么我们就可以用用户的编号来进行hash，常见的是用取余操作，如果我们要分30张表来存储用户的信息，那么用户编号为1的用户1%30=1，那么我们就存在user_01表里，如用户的编号为500，那么500%30=20，那么我们就将此用户的信息存储在user_20的表里.

 

3.按md5值来分表/分库;

 

我们假设要存储用户上传的文件，如果上传量大的话，也会带来系统的瓶颈问题，我们做过试验，在一个文件夹下如果超过200个文件的话，文件的浏览效率会降低，当然，这个不属于我们本文讨论的范围，这块也要做散列操作.我们可以用文件的用户名来md5或者用文件的md5校验值来做，我们就可以用md5的前5位来做hash，这样最多我们就可以得到5^5=3125个表，每次在存储文件的时候，就可以用文件名的md5值的前5位来确定这个文件该存那张表.

 

4.实例:某微博的url加密算法和存储策略的猜想.

 

现在好多微博都用这样的url来访问，如果他们的域名为www.example.com，那么如果你发微博的时候，你会发现你所发的url都变成了http://t.cn/Mx4ja1，这样的形式，他们是怎么进行这样的转换呢?我猜想就是用到了我们上面讲的md5的存储和查找规则，用你发的url来进行md5，得到md5值之后，如我们例子来说，就会用前6位来进行分表.

 

5.分表所带来的问题.

 

分表也会带来一系列的问题，如分页的实现，统计的实现，如果我们要做一个所有数据的分页，那么我们得每张表都得遍历一遍，这样访问效率会很低下.之前我尝试过用mysql的代理来实现，最终用tcsql来实现了.

 

6.分表算法的选择.

 

首先，分表适合于没有大的列表的应用来使用，要不然，会为这部分做好多额外的工作，如果你的应用数据量不是特别大的话，最好别用分表。呵呵，以前在做项目的时候，一项目经理要我们设计了一个千万级别的分表算法，而应用的pv不会超过100，总有点大炮打蚊子的感觉，而且因为分表，把整个项目的工期拖延了不少，得不偿失。