【摘要】
如何拆分数据是一个令人头疼的问题，除了要结合业务拆分外，具体拆分的粒度也是需要关注的。可以在实例级、库级别、表级别、分区级进行拆分，不同层次的拆分各有其利弊。
【作者】
韩锋，
CCIA（中国计算机协会）常务理事，前Oracle ACE，腾讯TVP，阿里云MVP，dbaplus等多家社群创始人或专家团成员。
有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。
曾担任多家公司首席DBA、数据库架构师等职。
在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。
曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。
当企业数据达到一个规模后，不得不面临数据拆分的问题。使用分布式数据库是一个相对“简单”的选择。通过分布式架构可以支撑海量规模，也避免的拆分所带来的各种“麻烦”。当然，分布式数据库也不是“银弹”，会有其适用的场景。如在分布式数据库下无法解决的话，仍然是需要面临拆分问题。但如何拆分数据是一个令人头疼的问题，除了要结合业务拆分外，具体拆分的粒度也是需要关注的。可以在实例级、库级别、表级别、分区级进行拆分，不同层次的拆分各有其利弊。下文针对不同的拆分方式，进行简单的对比分析。
1. 拆分层次：实例级
在实例级拆分，即通过将原有数据拆分到多个数据库实例来承载更大规模。
从架构角度来看，在实例级拆分无疑是比较彻底的，通过增加更多的实例，可以有效增加计算、存储资源。很多分布式数据库的架构，也是采用上层分布式计算层与下层单机存储引擎相结合，原理上就是在架构层拆分更多实例来支撑。每个实例都承载了一部分数据，这种情况会在一定程度上增加数据耦合，需要全部实例可用，才能提供完整的数据服务。
从研发角度来看，实例级拆分无疑是很大的变化，从单一数据源变为多个数据源。针对业务开发来说，不得不去解决多数据源管理及少量跨实例的问题。一般可通过自研或引入三方的数据库访问层来解决问题，减少对开发的影响。针对数据分析类需求，更加建议将数据汇聚到AP层进行处理。无论是哪方面的调整，工作量及工作难度都较之前架构增大及复杂很多。
从运维角度来看，实例级拆分意味着很多运维工作的变化。从资源管理、实例管理、备份恢复、系统优化等，都要从单实例变更为多实例。其划分为多个实例后，还需解决部分数据耦合关系所带来的问题。例如，如何实现跨实例的一致性备份、如何解决监控指标的全局汇总等。针对数据对象本身的管理，则更为复杂。前者多通过运维平台来解决多实例管理带来的工作量增多等问题；后者则通过数据库中间层可有效解决，针对多实例从逻辑上视同单一实例。
从安全角度来看，实例级拆分无疑是不利的。需要解决多实例下或者说分散条件下的安全统一管理、访问能力。通过统一的安全平台或安全框架是可以在一定程度上解决的。
2. 拆分层次：库级
在库级拆分，即通过将原有数据拆分到多个数据库中。不同数据库叫法不太统一，以MySQL为例就是"show databases"看到的结果。通常也被称为不同的Schema。
从架构角度来看，这种拆分方式只是在逻辑层面的一种拆分，并没有真实增加物理资源，因而对计算、存储的扩展上，达不到什么效果。从数据耦合上，还有所增加。这种拆分方式虽然没有增加资源，但是可为未来的扩展打下一定基础。例如，后续拆分给到不同实例，可以简单将某个Schema拆分出去即可，相对简化了很多。
从研发角度来看，较实例级拆分要轻些，需要增加对多Schema的支持。必要的多数据源管理或部分跨Schema的问题时需要解决的。分析类的需求，可通过跨Schema的关联完成。在工作量上有一定增加，但难度相对不大。通过也可以自研或引入三方的数据库访问层来解决。
从运维角度来看，应为没有引入其他实例，从日常运维、备份恢复等没什么变化。对于对象管理，是需要考虑多Schema的支持，至于性能上通过拆分Schema是否有提升不确定。使用更小的访问规模，也许性能有提升；但由于此而引入更多的关联查询，可能造成性能下降。
从安全角度来看，这种方式还是会造成一定管理的复杂度。管理成本的提高跟前面实例相差不大。
3. 拆分层次：表级
表级拆分，是指将原来的单个表，拆成多个分表（表名都发生变化）。物理上从单个对象拆分为多个对象，逻辑上有时可通过诸如视图等重新装饰出一个对象。
从架构角度来看，这种拆分方式是一种逻辑上的拆分，没有引入更多资源。从数据耦合度看，反而变差了。
从研发角度来看，与前面库级拆分类似，都还存在一定的工作量，但相对难度不大。也多可以通过自研或引入三方数据库访问层来解决。
4. 拆分层次：分区级
分区是数据库层面支持的一种技术，通过将数据划分在表中的多个分区，达到数据大而化小的效果。这是一种数据库原生内置的优化能力，较之前的实例级、库级、对象级，更为轻量，且无更多感知。
从架构角度来看，这种方式没有扩展现有资源，与拆分前的架构几乎没有区别。
从研发角度来看，几乎没有变化。将数据存在分区中，从业务层可做到无感。原有的开发逻辑，一般都可以正常使用，只是在个别地方可能需要有所调整。
从运维角度来看，资源、实例层面管理没有变化。差别较大的就是对象管理，分区级拆分提供更为灵活的管理方式，支持如分区合并、分裂、交换、清理等能力，可方便对象管理动作。从性能上看，使用分区后，数据库优化器将针对分区做更多优化动作，相对会有不错的性能提升。当然，这里需要注意下，不同数据库在分区上面的能力差异较大，有些数据库是做的相对不完善，分区可能存在较多限制。
如有任何问题，可点击文末
阅读原文
，到社区原文下评论交流
觉得本文有用，请
转发
或点击“
赏
”，让更多同行看到
欢迎关注社区
"数据库
"
技术主题
，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：
https://www.talkwithtrend.com/Channel/597
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场
