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

发布时间：2023-03-06 12:52:04 所属栏目：大数据来源：

导读：当企业数据规模达到一定水平,我们就必须处理数据分割。使用分布式数据库是一个相对“简单”的选择。通过分布式架构可以支撑海量规模，也避免的拆分所带来的各种“麻烦”。当然，分布式数据库也不

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

1. 拆分层次：实例级

在实例级拆分，即通过将原有数据拆分到多个数据库实例来承载更大规模。

❖ 架构

从架构角度来看，在实例级拆分无疑是比较彻底的，通过增加更多地实例，可以有效增加计算、存储资源。很多分布式数据库的架构，也是采用上层分布式计算层与下层单机存储引擎相结合，原理上就是在架构层拆分更多实例来支撑。每个实例中包含有一定的数据,这样的情况会造成一定的数据耦合,而要为完整的数据服务提供数据,则需要全部的实例可用。

❖ 研发

从研发角度来看，实例级拆分无疑是很大的变化，从单一数据源变为多个数据源。针对业务开发来说，不得不去解决多数据源管理及少量跨实例的问题。一般可通过自研或引入三方的数据库访问层来解决问题，减少对开发的影响。针对数据分析类需求，更加建议将数据汇聚到AP层进行处理。无论是哪方面的调整，工作量及工作难度都较之前架构增大及复杂很多。

2. 拆分层次：库级

在库级拆分，即通过将原有数据拆分到多个数据库中。不同数据库叫法不太统一，以MySQL为例就是"show databases"看到的结果。通常也被称为不同的Schema。

❖ 架构

从架构角度来看，这种拆分方式只是在逻辑层面的一种拆分，并没有真实增加物理资源，因而对计算、存储的扩展上，达不到什么效果。从数据耦合上，还有所增加。这种拆分方式虽然没有增加资源，但是可为未来的扩展打下一定基础。例如，后续拆分给到不同实例，可以简单将某个Schema拆分出去即可，相对简化了很多。

❖ 研发

从研发角度来看，较实例级拆分要轻些，需要增加对多Schema的支持。必要的多数据源管理或部分跨Schema的问题时需要解决的。分析类的需求，可通过跨Schema的关联完成。在工作量上有一定增加，但难度相对不大。通过也可以自研或引入三方的数据库访问层来解决。

3. 拆分层次：表级

表级拆分，是指将原来的单个表，拆成多个分表(表名都发生变化)。物理上从单个对象拆分为多个对象，逻辑上有时可通过诸如视图等重新装饰出一个对象。

❖ 架构

从架构角度来看，这种拆分方式是一种逻辑上的拆分，没有引入更多资源。从数据耦合度看，反而变差了。

❖ 研发

从研发角度来看，与前面库级拆分类似，都还存在一定的工作量，但相对难度不大。也多可以通过自研或引入三方数据库访问层来解决。

4. 拆分层次：分区级

分区是数据库层面支持的一种技术，通过将数据划分在表中的多个分区，达到数据大而化小的效果。这是一种数据库原生内置的优化能力，较之前的实例级、库级、对象级，更为轻量，且无更多感知。

❖ 架构

从架构角度来看，这种方式没有扩展现有资源，与拆分前的架构几乎没有区别。

❖ 研发

从研发角度来看，几乎没有变化。将数据存在分区中，从业务层可做到无感。根据原有的开发逻辑，开发人员一般都可以正常使用，只是在开发人员的个别地方用户可能很多的需要不可避免的有所调整。

（编辑：汽车网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!