数据库垂直切分和水平切分

下面笔记记一下对数据库水平切分的理解

我们常见的数据库瓶颈是什么呢？

举个栗子，双十一我们在电商那里购物，十几亿人刷刷刷，秒秒秒，订单越来越多，越来越多。加上我们的历史订单，好几年前的都在。那数据量可是大的惊天地泣鬼神啊，咋办？那可是存在一张表里头的啊。

数据库的读性能瓶颈我们已经靠缓存解决了，那么就只剩下写的性能了对吧。

一般像mysql，百万级的数据都还凑合，上千万就到瓶颈了。那么我们该如何解决这个瓶颈呢？

1.垂直切分

所谓垂直切分就是所谓的AOP化，这个AOP咋这么眼熟呢？java里管这个叫做面向切面编程，大概意思就是说，编程的时候，我们把各个业务逻辑分开，主要业务的运行不受其他杂七杂八的次要业务的干扰，当然次要是相对的。比如说事务啊、日志啊、权鉴啊等等。把这群杂七杂八的业务都各自做成一个服务，独立运行，不影响主业务。OK说了这么多，重要的只有一句，那就是服务化AOP。

那什么是垂直切分能，它又与服务化有什么关系呢？

我们说一东西是庞然大物，要么是因为它太大了，要么是太高了，要么就是又高又大。

横向的“太大”我们就可以用垂直切分，让它“苗条”起来。数据也一样，我们可以把一张表的字段，根据业务或者是功能模块的分成若干张表。这若干张表用主键来联系。这样做的好处不明而喻：

• 数据库的拆分简单明了，拆分规则明确；
• 应用程序模块清晰明确，整合容易；
• 数据维护方便易行，容易定位；

当然了，没有完美的技术，只有更合适的技术。垂直切分的缺点也很明显：

• 部分表关联无法在数据库级别完成，需要在程序中完成（比如说join,count,order by,group by）；
• 单表大数据量仍然存在性能瓶颈（万一是又高又大的庞然大物呢？我们只是把它变得苗条了，但它太高了，也是一种瓶颈，不是吗？）；
• 事务处理相对更为复杂（只要是牵扯到事务就没简单的）；
• 切分达到一定程度之后，扩展性会遇到限制（由于主键的存在，表与表之间耦合性太强，一般耦合性太强的东西，扩展性都太差）；

当我们遇到的是又高又大的庞然大物，我们除了让它变苗条，还要让它变矮。木秀于林，风必摧之。反正不是什么好事。于是乎，我们要将数据库水平切分，就是把里面的数据拦腰斩断，分成好几块（玛雅太血腥了吧），我们一只箱子装不下，我们装几个箱子。当然，里面的数据不能像量子那样玄，那你分成了几份装起来就不可能会有交集。几个数据库的并集就是一份完整的数据。

水平切分的优点

• 解决单表大数据量性能遇到瓶颈的问题；
• 应用程序端整体架构改动相对较少；
• 事务处理相对简单；
• 只要切分规则能够定义好，基本上较难遇到扩展性限制；

水平切分的缺点

1.切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则

首先是主键ID的拆分问题：

水平切了，主键就不能用数据库自己的ID生成方式了，不然很难保证各个库同表的ID唯一性

UUID也不是好办法，因为它太长了。小伙伴要是做过数据库调优就知道，那么长的东西根本不适合做ID,这会给建立索引和根据索引查询带来很大的性能问题，而且还影响写的速度。下面引用网友的解释

nnodb 中的主键是聚簇索引，会把相邻主键的数据安放在相邻的物理存储上。如果主键不是自增，而是随机的，那么频繁的插入会使 innodb 频繁地移动磁盘块，而影响写入性能。

至于解决办法可以参考twitter的分布式自增ID算法Snowflake；

2.后期数据的维护难度有所增加，人为手工定位数据更困难；

3.应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。

未完待续...

本文原创，如需转载请注明出处。