聊聊分库分表

如果您正面临着分库分表的问题，那么恭喜您，您的业务量正在高速增长。

分库分表的必要性

首先我们来了解一下为什么要做分库分表。在我们的业务（web应用）中，关系型数据库本身比较容易成为系统性能瓶颈，单机存储容量、连接数、处理能力等都很有限，数据库本身的“有状态性”导致了它并不像Web和应用服务器那么容易扩展。那么在我们的业务中，是否真的有必要进行分库分表，就可以从上面几个条件来考虑。

单机储存容量。您的数据量是否在单机储存中碰到瓶颈。比如饿了么一天产生的用户行为数据就有24T，那么在传统的单机储存中肯定是不够的。
连接数、处理能力。在我们的用户量达到一定程度时，特定时间的并发量又成了一个大问题，在一个高并发的网站中秒级数十万的并发量都是很正常的。在普通的单机数据库中秒级千次的操作问题都很大。
所以在我们进行分库分表之前我们最好考虑一下，我们的数据量是不是够大，并发量是不是够大。如果您的回答是肯定的，那我们就开始做吧。

分库分表的几种方法

在分库分表中，我们有几种不同的划分方式：垂直分表、垂直分库、水平分表、水平分库分表。分的方式大同小异，主要思想都是化大为小，且可以融合使用。

垂直分表

垂直分表在日常的开发和设计中比较常见，简单来讲就是“大表拆小表”，拆分是基于关系型数据库中的列进行的。我们在基础数据库课程中老师就教导我们，一个表的字段不要太多，就算数据量没有那么大，为了表的合理性我们也会做。比如，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中。
比如在一张产品表中（id, name, price, company, ），我们将常用的（id, name, price, company）字段放在一个表中，而不常用的（）字段放在拓展表中，那我们查询时优先查询常用字段，在有必要时才查询拓展字段。可以有效的提高效率，同时减少字段后我们在一个表中可以容纳的数据数量也提高了。
垂直分表还有一个好处，能使得我们的微服务的关注点更加明确。
Note：分表的操作最好在数据库设计阶段就做完，如果在后续开发过程中再拆分，则可能需要大量的更改SQL语句。

垂直分库

垂直分库的基本思路便是我们按照不同的业务模块来划分出不同的数据库。垂直分库在“微服务”盛行的今天已经非常普及了。就像我们上面所说的，这能使得我们的微服务的关注点更加明确。也就是业务逻辑更加清晰。
比如在我们的业务中，User, Product, Company等都属于不同业务模块，便可将其放在不同的数据库。

水平分表

水平分表的思想很简单，就相当于一摞烙饼一百个，然后我每十个放一个篮子。在数据库中的表现就是，我一个User表有100万条数据，那么我0-10w放在一个表中，10-20w放一个表中，类推（当然这只是其中一种分布规律）。这样可以降低单表的数据量，优化查询性能。
水平分表能够降低单表的数据量，在一定程度上能够缓解查询性能的瓶颈。但其本质上还是在一个数据库中，所以当查询上升到数据库级，其IO瓶颈并没有得到好的解决。所以并不推荐单纯的水平分表做法。

水平分库分表

水平分库分表与水平分表的思想相同，即将同一表中的大量数据分层次的储存，不同的在于将分出来的表放在不同的数据库中。在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入的硬件成本也会更高。同时，这也会带来一些复杂的技术问题和挑战（例如：跨分片的复杂查询，跨分片事务等）。

这次我们谈了几种分库分表的方案，下次我们谈谈不同方案会遇到的问题及解决方案