一文读懂数据分片技术差异

关于数据分片的话题，近期非常火热。一方面是由于用户在海量数据、高并发访问的诉求日益增长；另一方面分布式数据库发展迅速、技术路线各异，难以选择。近期的一篇关于数据分片的文章吸引到我，文中对数据分片从技术角度做了分析归类，提出一种很好的归纳方法。本文尝试延展这一观点，对数据分片进行归类阐述。

原文参考：

http://mysql.taobao.org/monthly/2020/12/01/

1. 从数据分片技术分类

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

沿用文中观点，将数据分片产品根据技术路线做个分类。

❖ Partition None

数据分片最为朴素的原始需求，就是来自于不断增大数据量。在早期的数据库产品，不具备分片能力，例如早期的Oracle、MySQL数据库。此时面对这种需求，普遍的解决方法主要来自两种：一是数据拆分，从根本减少数据规模；二是数据清理与归档，减少活跃数据。前者常见的策略就是垂直拆分、水平拆分，拆分之后的数据规模减小，更好处理。这部分具体可参照之前的文章《行业观察：数据分片哪家强》。后者，则是建立数据全生命周期，通过清理、归档等方式减少活跃数据量，提高数据库处理性能。上述两种方法，直到现在仍然具备普适意义。虽然现在的数据库已经具备各种数据分片能力（如下面描述），但这些能力都是功能有所妥协后的结果。

❖ Partition Disk

随着数据规模持续增加，企业需要一种应对方案，于是Partition Disk方式诞生了。从本质上来讲，这种方式仍是将数据的存储与计算限定在指定资源内。不同的是，从逻辑上数据进行了拆分，可以在更小粒度上进行管理与访问。典型的技术就是分区表，对用户暴露出的仍然是单一表形式，但后台数据是按分区独立存储。产品例如Oracle、MySQL等，均在后续版本中支持了分区表技术。但这种方式的缺点也很明显，就是没有真正意义实现数据的拆分，仍然是复用整体资源。

适用场景：传统架构、成熟稳定

❖ Partition Storage

本地磁盘的容量终究有限，如何突破这一限制，Partition Storage方式诞生了。这种方式，是从存储角度进行了拆分，可较之前架构提供更大的存储容量。比较典型的产品如Oracle RAC，其通过多个计算节点挂载共享存储来实现。整体的承载能力取决于共享存储空间的大小，如传统的集中式存储可提供近千块磁盘、近PB的容量。后期随着存储技术的发展，分布式存储逐渐成熟，其扩展能力又有了进一步的提升。作为类似架构产品，云数据库产品也多采用存储与计算分离技术，底层使用了云端的分布式存储，提供更大的承载能力，且通过对云端底层架构的深度优化及数据库上层的适配，可提供接近传统数据库体验的同时，计算与存储能力得到大幅提升。典型产品如AWS的Aurora、Aliyun的PorlaDB等。

适用场景：成熟稳定、高弹性、简捷管理、上云

❖ Partition Engine

上述产品可满足的数据存储上一定的扩展能力，但对于数据计算无扩展。Oracle RAC算是个例外，其通过对等节点的方式，可满足一定程度的计算资源扩展。当然，其计算能力的扩展有限（Oracle RAC节点不易过多），无法满足非常高的计算需求。随着近些年来网络技术的提升、分布式共识算法的工程落地，为真正意义上的分布式数据库做了很好地铺垫。以2016年Google论文为理论基础，一系列分布式数据库涌现出来。这些产品提供了更大的存储能力及更高的吞吐算力。架构上这些产品实现了将计算部分进行从拆分，提供计算能力的扩展。典型产品，例如Google Spanner、PingCAP的TiDB、蚂蚁的OB及国外的CockroachDB等。其对外暴露的是标准的数据库能力，只是在某些细节能力较传统数据库有所减低。

适用场景：数据规模大、高吞吐高并发、混合负载计算、强高可用

❖ Partition All

作为理想状态，采用Partition Engine的分布式数据库，已经可以完美的解决数据分片问题，但在实际场景中还存在另一些情况。这其实来自于早期互联网的快速发展，当时面临着海量数据的存储问题且没有较为成熟的分布式数据库可支撑。当时的做法是很多互联网公司在内部通过应用改造支持数据分片能力，也很好地满足自身发展。其架构特点是与应用连接更为紧密，可感知数据位置信息，从计算与存储都进行了较为彻底的拆分。理想情况下，整个数据库的各个模块可以全部并发执行起来。当然这种方式的弊端也很明显，就是与应用耦合强、产品化封装差、需要用户侧处理些原本由数据库侧完成的逻辑，如分布式事务、跨片查询等等。后续这一方式产品也基于此进行了大量改进优化，诞生出不少产品或项目。诸如：开源的ShardingSphere、MyCAT或封装为标准数据库产品的如GoldenDB、TDSQL等。近些年来，随着分布式数据库的成熟，这两者的对比成为颇为瞩目的话题。个人看来，这两种方式产品能力在逐步融合，发展上逐步趋同；在细分能力上各有千秋，可满足各自擅长的场景。

适用场景：数据规模巨大、极致高性能、分片定制化、异构计算

2. 从不同角度看待数据分片

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).应用功能角度

上面我从技术上做了简单的分类，那从用户角度来讲，如何看待这几种方式呢？下面从三个维度（兼容性、扩展性、数据规模）进行了简单对比，如下图。其中：

• 兼容性：较单机传统数据库功能兼容度
• 扩展性：数据计算、存储上的扩展能力
• 数据规模：这一架构产品的数据存储容量

从上图可见，标准数据库功能上，不同分片方式产品兼容性整体依次降低。数据库特性的能力，被逐步放弃，更多采用更为标准的数据使用方式。举个简单例子，如存储过程的问题。对于后几种数据分片方式产品来说，已经基本放弃了对其支持。虽然也有产品号称可以实现，但距真正商用还是有不小的差距。从现有发展趋势来看，也是越来越简单地使用数据。从扩展能力来说，从受限于本地磁盘容量、集中/分布式(云)存储容量、分布式架构到应用架构等，其扩展能力逐步提高。扩展能力的提升也进而影响到数据规模，其能承载的数据量也逐步增大。

2).技术实现角度

从技术角度来看，可大致分为如下功能层次，不同类别产品实现层次各有差异。当然各产品间也在逐步融合，产品能力边界日益模糊。当需要了解一款“分片”数据库时，可以尝试从上述角度了解其技术实现。