mysql 垂直拆分 原因_数据库垂直拆分与水平拆分的方式和问题

上篇文章中我们提到，按照数据特性上，将数据按照水平拆分和垂直的方式进行拆分，这种方式如何进行衡量以及面临的种种问题？今天就来具体介绍下。

衡量标准数据量预估：数据容量预估，需要对业务上整体规划数据量的大小。衡量方式标准是日增长量预估、月增长量预估、年增长量预估，个方面进行衡量。每日增长的服务在百级别、千级别、万级别、十万基本、百万级别、千万级别的量级，评估出对应的月增长以及年增长预估，结合业务需要，就可以评估出确定采用分库Or分表。

硬件资源：单个机器中可以存储的数据量大小。在并发操作负载的情况下磁盘I/O的性能压力。目前大部分DB资源机器为固盘，I/O性能一般不会成为瓶颈。

有效时间：数据在业务上的有效时间，有效期为月、季度、年度的方式进行评估。

一般业务数据增长服务较小，常用于表的拆分，增量流水记录等常用于库的拆分。日增长数据量在W级别以上，建议拆库处理(需要结合硬件存储空间、业务数据的有效期限制)。业务上的数据有效可以有效时间限最大长度为1-2年左右(结合实际业务上需要)。

拆分多少算合适？

基于以上标准，我们决定了是按照表拆分还是库的方式拆分，拆分的数量常用于2的N次幂(N>3)，这样方便业务上数据量再进行拆分时，便于数据的迁移，避免数据再次拆分后数据有交互存储。单个数量拆分1个拆分为2个，2个拆分为4个，4个到8个，每一次相当于对数据进行了再次拆分，避免在拆分的过程中1个拆分2个，2拆分3个，数据上造成混淆重洗.

按照什么维度拆分？

拆分的维度，主要是按照业务的维度进行拆分，结合业务上的主要查询场景进行拆分，如果不按照业务上的主要查询场景进行拆分，后续处理起来比较麻烦，涉及到跨数据体系访问，分页问题、多次查询数据等一一难以解决。我们需要明确数据的实时在线查询场景，是按照什么维度进行查询，也就是我们的主要服务业务群体。比如我们的财务系统对应的财务流水可以按照用户的维度进行拆分，广告的消费流水可以按照广告的维度拆分等。

数据倾斜如何处理

我们业务上选的拆分维度，可能在业务上数据的冷热程度不同，可能会造成数据拆分后的严重倾斜问题，这种问题我们如何解决呢？

业务上按照简单的Hash的拆分方式，或者按照维度进行取模的方式，这种方式天然的会存在数据上的倾斜，业务上的不同业务数据操作特性差异性比较大，只有部分业务数据的频率较高，产生了大量的业务数据，导致整体上的数据倾斜，另外一种导致数据倾斜的原因是Hash的维度对应的数据唯一主键，比如我们的UserId在生成的过程中存在一定的随机性策略，没有强顺序的处理。还有一种原因，数据量的存在一定的不确定性。这种拆分方式简单、高效，同时也带来数据倾斜的问题，这种方式这里简单成为静态拆分。

如何达到数据均匀呢？现实生活中我们排队办理业务时，有的经验丰富业务人员办理比较效率，相对业务新手可能处理效率大打折扣，这种情况下我们为了保证整体排队人员的等待时间一致，会有专人根据现场处理情况进行动态的调整新排队的人进入到哪个业务人员进行业务办理，这种也就是这里叫做动态调整的方式。在数据请求的过程中，通过中间关系维护，对应的数据应该Hash到哪个数据集合中。针对新来的数据可以动态的调整对应的Hash方式。

静态拆分如果对数据进行添加拆分维度的话，需要对数据进行迁移重Hash，动态调整可能不需要数据进行重新hash，只需要对新数据添加到新的表中，同时动态拆分对应的维护成本和时间成本的增加，中间关系通常采用K-V型存储的方式。

数据主键如何生成？

数据上我们在存储上做了拆分，要保证数据的全局唯一性，切忌使用数据库的表的自增主键的方式，关于主键生成策略有：twitter开源分布式生成id算法

zookeeper生成id等策略

UUID

数据库批量生成id

关于这几种方式，可以结合技术成本和业务复杂度进行选择。后续我们单独介绍。