转载

大型网站架构改进历程：存储的瓶颈（六）

【编者按】本文转自博客园的夏天的森林，在看这篇之前，大家可以移步看大型网站架构改进历程：存储的瓶颈（一）、（二）、（三）、（四）（五）。

在讲数据库水平拆分时候，我列出了水平拆分数据库需要解决的两个难题，它们分别是主键的设计问题和单表查询的问题，主键问题前文已经做了比较详细的讲述了，但是第二个问题我没有讲述，今天我将会讲讲如何解决数据表被垂直拆分后的单表查询问题。

要解决数据表被水平拆分后的单表查询问题，我们首先要回到问题的源头，我们为什么需要将数据库的表进行水平拆分。下面我们来推导下我们最终下定决心做水平拆分表的演进过程，具体如下：

第一个演进过程：进行了读写分离的表在数据增长后需要进行水平拆分吗？回答这个疑问我们首先要想想进行读写分离操作的表真的是因为数据量大吗？答案其实是否定的。最基本的读写分离的目的是为了解决数据库的某张表读写比率严重失衡的问题，举个例子，有一张表每天会增加1万条数据，也就是说我们的系统每天会向这张表做1万次写的操作，当然也有可能我们还会更新或者删除这张表的某些已有的记录，这些操作我们把它归并到写操作，那么这张表一天我们随意定义个估值吧2万5千次写操作，其实这种表的数据量并不大，一年下来也就新增的几百万条数据，一个大型的商业级别的关系数据库，当我们为表建立好索引和分区后，查询几百万条数据它的效率并不低，这么说来查询的效率问题还不一定是读写分离的源头。

其实啊，这张表除了写操作每天还承受的读操作可能会是10万，20万甚至更高，这个时候问题来了，像oracle和mysql这样鼎鼎大名的关系数据库默认的最大连接数是100，一般上了生产环境我们可能会设置为150或者200，这些连接数已经到了这些关系数据库的最大极限了，如果再加以提升，数据库性能会严重下降，最终很有可能导致数据库由于压力过大而变成了一个巨锁，最终导致系统发生503的错误，如是我们就会想到采用读写分离方案，将数据库的读操作迁移到专门的读库里，如果系统的负载指标和我列举的例子相仿，那么迁移的读库甚至不用做什么垂直拆分就能满足实际的业务需求，因为我们的目的只是为了减轻数据库的连接压力。

第二个演进过程：随着公司业务的不断增长，系统的运行的压力也越来越大了，我们已经了解了系统的第一个瓶颈是从存储开始了，如是我们开始谈论方案如何解决存储的问题，这时我们发现我们已经做了读写分离，也使用了缓存，甚至连搜索技术也用上了，那么下个阶段就是垂直拆分了，垂直拆分很简单就是把表从数据库里拆出来，单独建库建表，但是这种直截了当的方案想想就能感到这样的做法似乎没有打中系统的痛点，那么系统的痛点到底是什么呢？根据数据库本身的特性，我们会发现痛点主要是三个方面组成：

第一个方面：数据库的连接数的限制 。原库的某些表可能承担数据库80%的连接，极端下甚至可以超过90%的连接，而且这些表的业务操作十分的频繁，当其他小众业务的表需要进行操作时候，搞不好因为连接数被全部占用而不得不排队等待空闲连接的出现，那么这个时候我们就会考虑把这张表做垂直拆分，这样就减轻了原数据库连接的压力，使得数据库连接负载变得比较均衡。

第二个方面是数据库的读操作，第三个方面是数据库的写操作 ，虽然把读和写分成两个方面，但是这两个方面在我们做垂直拆分时候要结合起来考虑。首先我们要分析下数据库的写操作，单独的写操作效率都是很高的，不管我们的写是单条记录的写操作，还是批量的写操作，这些写操作的数据量就是我们要去写的数据的大小，因此控制写的数据量的大小是一件很容易很天然的操作，所以这些操作不会造成数据库太大负担，详细点的话，对于数据库而言，新增操作无非是在原来数据后面追加些记录，而修改操作或者删除操作一般都是通过建立了高效索引的字段来定位数据后再进行的操作，因此它的性能也是非常高的。

而读操作看起来比写操作简单（例如：读操作不存在像事务这些乌七八糟因素的干扰），但是当读操作面对海量数据时候就严重挑战着数据库和硬盘的极限能力，因此读操作很容易产生瓶颈问题，而且这个瓶颈不管问题表是否读写失衡都会面临的。前文里我详细列举了一个交易表设计的案例，其中我们可以看到数据库垂直拆分在实际应用里的运用，在例子里我们首先根据业务特点将交易表分成了实时交易表和历史交易表，这个做法其实就是将原交易表的读和写进行分离，但是这种分离和纯粹的读写分离相比会更加有深意，这个深意就是拆分实时和历史交易表也就是在分拆原表的读写操作的关联性，换句话说，如果我们不这么做的话，那么交易表的每次写和每次读几乎等价，这样我们没法单独解决读的性能问题，分出了历史交易表后我们再对历史交易表来做读的优化，那么这也不会影响到写操作，这样把问题的复杂度给降低了。

在案例里我们对历史交易表进行了业务级别的水平拆分，但是这个拆分是以如何提升读的效率进行的，因此前文讲到的水平拆分里主键设计方案基本上派不上用场，因为这两种水平拆分的出发点是不同的，那么使用的手段和达到效果也将不一样。

正文到此结束