数据库分库分表漫谈

背景

随着公司业务增长，关系型数据库表慢慢会增长到很大的量，如果不能清理数据的话就需要面对大表CRUD，这是公司成长过程的共同考验

解决方案

根据我的个人经验，目前主要有3种比较主流的方法

1. 分表。分库不常见，比较多的是分表。分表又分为2种：
   • 垂直分表：将表的字段拆分到新表，常用字段留下，少用字段做关联查询。属于冷热分离
   • 水平分表：将表复制多份，结构一致，表名用某种规则分开。这种比较复杂，需要中间件或server端来处理
   • 冷热分表：将比较新的常用的数据留下，将历史数据归档到历史表。如果查不到数据，再去历史表retrieve
2. 使用NoSQL替代，特别是支持集群和sharding的如mongodb，cassandra等。它们原生地支持分布式查询
3. 比较新潮，使用阿里oceanbase，相当于MySQL on NoSQL，支持分布式存储和查询的MySQL

可以购买相关技术书籍，或者关注这方面专家如阿里巴巴沈询等人的微博等，更深入了解分布式存储思想

分表中间件

网上五花八门的介绍文章很多，可以自行搜索。个人认为，评价一个分布式中间件的标准应该是：

1. 对server端无侵入，不需要改写sql，无需判断routing。将所有表都当成单表来操作
2. 对数据分析无侵入，无论是产品方还是分析师，都可以用某种工具，将所有表当成单表来操作
3. 充分支持sql标准，如分布式的group by，sort by等，没有或很少限制

当然，对程序无影响的代价就是对运维有压力，但这也是标准的一部分：

1. 配置简单，能够集中配置
2. 容忍部分节点宕机，部分查询失效不至于全不可用

总结一下

• 通常关系数据库表记录不要大于三千万，否则性能可能面临问题。分表是解决方案之一
• 任何分表方案都不简单，没有out-of-the-box & zero config 的方案。一定是经过评估，必须分表时才上方案
• 分库分表已经成为开发和运维面试热门考点之一，常常会有这种情况，一行数据都还没有的创业公司，要求应聘者规划上亿用户的存储方案。或者非创业公司，要求应聘者用几分钟时间给出分库分表实际解决方案，还必须实用