超大数据量存储常用数据库分表分库算法总结

数据库  /  管理员 发布于 6年前   166

当一个应用的数据量大的时候，我们用单表和单库来存储会严重影响操作速度，如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.分表算法的选择.

如果你的应用数据量不是特别大的话，最好别用分表。