漫谈“数据拆分层次对比”

字数 2275阅读 1205评论 0赞 1

内容摘要：

数据拆分层次对比：实例级拆分增加资源，研发、运维、安全都有挑战；库级拆分逻辑上拆分，未来扩展有基础，运维相对简单；表级拆分逻辑上拆分，数据耦合度变差；分区级拆分轻量，对象管理更灵活，性能提升，安全无变化。

当前摘要为AI生成

当企业数据达到一个规模后，不得不面临数据拆分的问题。使用分布式数据库是一个相对“简单”的选择。通过分布式架构可以支撑海量规模，也避免的拆分所带来的各种“麻烦”。当然，分布式数据库也不是“银弹”，会有其适用的场景。如在分布式数据库下无法解决的话，仍然是需要面临拆分问题。但如何拆分数据是一个令人头疼的问题，除了要结合业务拆分外，具体拆分的粒度也是需要关注的。可以在实例级、库级别、表级别、分区级进行拆分，不同层次的拆分各有其利弊。下文针对不同的拆分方式，进行简单的对比分析。
![](/home/attachment/202403/14/1228765_171040236583611.png)

##1. 拆分层次：实例级 
 在实例级拆分，即通过将原有数据拆分到多个数据库实例来承载更大规模。
 ❖ 架构
 从架构角度来看，在实例级拆分无疑是比较彻底的，通过增加更多地实例，可以有效增加计算、存储资源。很多分布式数据库的架构，也是采用上层分布式计算层与下层单机存储引擎相结合，原理上就是在架构层拆分更多实例来支撑。每个实例都承载了一部分数据，这种情况会在一定程度上增加数据耦合，需要全部实例可用，才能提供完整的数据服务。
 ❖ 研发
 从研发角度来看，实例级拆分无疑是很大的变化，从单一数据源变为多个数据源。针对业务开发来说，不得不去解决多数据源管理及少量跨实例的问题。一般可通过自研或引入三方的数据库访问层来解决问题，减少对开发的影响。针对数据分析类需求，更加建议将数据汇聚到AP层进行处理。无论是哪方面的调整，工作量及工作难度都较之前架构增大及复杂很多。
 ❖ 运维
 从运维角度来看，实例级拆分意味着很多运维工作的变化。从资源管理、实例管理、备份恢复、系统优化等，都要从单实例变更为多实例。其划分为多个实例后，还需解决部分数据耦合关系所带来的问题。例如，如何实现跨实例的一致性备份、如何解决监控指标的全局汇总等。针对数据对象本身的管理，则更为复杂。前者多通过运维平台来解决多实例管理带来的工作量增多等问题；后者则通过数据库中间层可有效解决，针对多实例从逻辑上视同单一实例。
 ❖ 安全
 从安全角度来看，实例级拆分无疑是不利的。需要解决多实例下或者说分散条件下的安全统一管理、访问能力。通过统一的安全平台或安全框架是可以在一定程度上解决的。

##2. 拆分层次：库级 
 在库级拆分，即通过将原有数据拆分到多个数据库中。不同数据库叫法不太统一，以MySQL为例就是"show databases"看到的结果。通常也被称为不同的Schema。
 ❖ 架构
 从架构角度来看，这种拆分方式只是在逻辑层面的一种拆分，并没有真实增加物理资源，因而对计算、存储的扩展上，达不到什么效果。从数据耦合上，还有所增加。这种拆分方式虽然没有增加资源，但是可为未来的扩展打下一定基础。例如，后续拆分给到不同实例，可以简单将某个Schema拆分出去即可，相对简化了很多。
 ❖ 研发
 从研发角度来看，较实例级拆分要轻些，需要增加对多Schema的支持。必要的多数据源管理或部分跨Schema的问题时需要解决的。分析类的需求，可通过跨Schema的关联完成。在工作量上有一定增加，但难度相对不大。通过也可以自研或引入三方的数据库访问层来解决。
 ❖ 运维
 从运维角度来看，应为没有引入其他实例，从日常运维、备份恢复等没什么变化。对于对象管理，是需要考虑多Schema的支持，至于性能上通过拆分Schema是否有提升不确定。使用更小的访问规模，也许性能有提升；但由于此而引入更多的关联查询，可能造成性能下降。
 ❖ 安全
 从安全角度来看，这种方式还是会造成一定管理的复杂度。管理成本的提高跟前面实例相差不大。

##3. 拆分层次：表级 
 表级拆分，是指将原来的单个表，拆成多个分表（表名都发生变化）。物理上从单个对象拆分为多个对象，逻辑上有时可通过诸如视图等重新装饰出一个对象。
 ❖ 架构
 从架构角度来看，这种拆分方式是一种逻辑上的拆分，没有引入更多资源。从数据耦合度看，反而变差了。
 ❖ 研发
 从研发角度来看，与前面库级拆分类似，都还存在一定的工作量，但相对难度不大。也多可以通过自研或引入三方数据库访问层来解决。
 ❖ 运维
 从运维角度来看，与前面库级拆分也类似，差别不大。
 ❖ 安全
 从安全角度来看，与前面库级拆分也类似，差别不大。

##4. 拆分层次：分区级 
 分区是数据库层面支持的一种技术，通过将数据划分在表中的多个分区，达到数据大而化小的效果。这是一种数据库原生内置的优化能力，较之前的实例级、库级、对象级，更为轻量，且无更多感知。
 ❖ 架构
 从架构角度来看，这种方式没有扩展现有资源，与拆分前的架构几乎没有区别。
 ❖ 研发
 从研发角度来看，几乎没有变化。将数据存在分区中，从业务层可做到无感。原有的开发逻辑，一般都可以正常使用，只是在个别地方可能需要有所调整。
 运维
 从运维角度来看，资源、实例层面管理没有变化。差别较大的就是对象管理，分区级拆分提供更为灵活的管理方式，支持如分区合并、分裂、交换、清理等能力，可方便对象管理动作。从性能上看，使用分区后，数据库优化器将针对分区做更多优化动作，相对会有不错的性能提升。当然，这里需要注意下，不同数据库在分区上面的能力差异较大，有些数据库是做的相对不完善，分区可能存在较多限制。
 ❖ 安全
 从安全角度来看，分区级拆分与拆分前没有太大变化。

信创数据库分布式数据库数据分层

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

漫谈“数据拆分层次对比”

添加新评论0 条评论

文章目录收起目录

作者其他文章

相关文章

相关问题

相关资料