分布式数据划分的技术挑战

对于OceanBase这样的分布式数据库，首先要解决的问题就是数据划分，即如何将数据分散到整个集群中。从分布式系统的角度看，数据划分无外乎几种方式：按照哈希分片，按照数据范围分片，或者这两种分片方式的组合。数据划分的最终目的是负载均衡，尽可能充分利用集群资源。分布式系统中往往也有一个全局管控节点，真正执行负载均衡操作，将划分后的数据分片按照一定策略分散到整个集群。
存储划分
对于普通的存储系统，例如分布式文件系统，分布式Key-Value系统。数据划分的核心在于使得每个分片不大不小。所谓不大，意味着每个分片的数据量不会特别大，也没有访问热点，迁移复制单个数据分片的成本不高，从而便于根据实时负载情况执行动态均衡；所谓不小，意味着每个分片不能特别小，从而减少元数据的存储管理开销。大部分存储系统的分片大小在100MB ~ 1GB之间，部分文件系统的分片大小可以达到几十GB甚至上百GB，这是因为这些文件系统单机的硬盘容量很大（几十TB甚至上百TB），且大部分数据分片不活跃，不怎么需要进行负载均衡操作。
事务划分
对于分布式数据库，除了考虑存储划分，还需要考虑事务的影响。对于无共享（share-nothing）的分布式数据库架构，往往采用JimGray提出的两阶段提交协议来实现跨机分布式事务。然而，相比单机事务，跨机事务的性能有不小的差距。其中，最大的影响莫过于两阶段事务持有锁的时间太长，容易导致热点行/热点账户等一系列问题。对于这个问题，有两个解决思路：一个是尽可能优化两阶段提交事务的性能和可用性，还有一个是在数据划分时尽量使得经常一起操作的数据分布在同一台服务器，降低跨机事务的概率。
AmazonAurora是一种存储、计算分离的共享存储架构，从数据划分的角度看，Aurora的底层存储通过分布式实现了可扩展和高可用，上面的事务层仍然采用单机模式来避免事务划分导致的跨机事务性能问题。Oracle RAC也是一种共享存储架构，和Amazon Aurora不同点在于，Oracle RAC的事务层通过分布式锁、队列和缓存协调机制来实现多机之间的事务状态共享，从而支持多机且对使用者透明。当然，Oracle RAC事务层全局协调的网络开销很大，因此，Oracle RAC强依赖高性能网络，例如InfiniBand。
透明性
Oracle RAC虽然对用户透明，但是成本很高，且可扩展性受限。理想的方案成本很低，构建在普通PC服务器组成的集群之上，通过软件实现容错，同时需要做到对使用者基本透明。对于分布式事务，透明性和性能看起来是矛盾的，如果需要做到对使用者透明，就会更多地引入跨机分布式事务，这里需要做一个取舍。
阿里巴巴的业务往往包含两类角色，用户和客户，用户是互联网服务使用者，客户往往是商家。分布式数据库可以支持表格组（table group）和自动分片这两个特性。其中，表格组用来标识同一个用户/客户经常一起操作的多张表格，并允许这些表格自动执行哈希或者范围分片。通过这两个特性，大部分事务操作都在单机上执行，避免了分布式事务的开销，且使用者学习成本较低，对业务基本透明。当然，这里面还需要解决下面两个性能问题：
单机多表事务的性能：同一个表格组下同一个用户所在的多张表格的分片，往往会调度到同一台服务器，此时，需要能够具备将两阶段提交优化到一阶段的能力，如何自适应地实现这一优化比较关键，尤其是如何处理各种服务器宕机等异常情况；
全局索引的更新性能：虽然可以通过表格组和自动分片来使得同一个事务操作的多张主表的数据分片调度到一台服务器，但是这里并不包含全局索引。从理论上讲，全局索引和主表的数据分布方式总是不同的，如何优化数据分片和索引分片不在一台机器、不在一个机房甚至不在一个城市的全局索引更新性能，是这里的关键。
原生分布式 vs 分库分表
国内数据库市场上也存在大量构建在MySQL分库分表基础之上的分布式中间层解决方案，且号称“分布式数据库”。分库分表和原生分布式数据库看似相同，但是却有着本质差别。分库分表往往是建立在把复杂度暴露给使用者这一前提之上的，而原生的分布式数据库却为了对业务透明而做了大量的努力。举例如下：
全局一致性。分库分表方案将同一个表格对象拆分为多个表格对象分散到多台服务器，这就丧失了全局一致性，可能出现某台机器已经更新了表格schema，另外一台机器还没有更新的情况，无法保证原子性。分库分表方案也无法得到整个系统的全局统一快照。另外，分库分表方案缺少全局索引功能，类似MySQL自增列或者Oracle Sequence这样的全局性功能也都变了味道。
可扩展性。分库分表方案往往采用预先划分的方式，无法做到按需划分，也不支持灵活的数据分片方式。对于快速发展的业务，当实际容量超出预期时，将无法扩展。即使实际容量没有超出预期，分库分表也只能采用双倍扩容的方案，无法根据需要线性扩展，分库分表本身的维护成本也比较高。
事务支持。很多分库分表方案只支持单机事务，不支持跨机事务。即使支持跨机事务，往往也会在功能和异常处理上有所限制。例如，不支持复杂的DML语句; 又如，某互联网巨头分库分表方案虽然支持分布式事务，但是服务器故障时需要手工杀死正在进行的事务。
HTAP处理能力。大部分分库分表方案底层基于MySQL，MySQL本身对OLAP场景支持就不好，再加上基本没有跨机分布式执行计划的优化能力，因此，无法处理HTAP负载，只能在业务上将数据同步到专门的数据仓库系统，大大地增加了业务复杂度。
SQL功能完备性。无论是复杂SQL语句，优化器能力，存储过程，SQL兼容性，还是schema变更操作，分库分表方案都存在各种限制，要求使用者通过修改业务来规避各种“坑”。
。。。
OceanBase的理念是做一个可扩展、高可用、高性能、低成本且对业务透明的原生分布式商业数据库。相比基于MySQL分库分表的中间件解决方案，OceanBase的产品潜力和技术复杂度都要高得多，这就使得OceanBase的研发周期更长，且初期功能缺失会比较多，但随着产品功能逐步补全，它的竞争优势也将逐步发挥出来。
当然，一个系统最终使用何种数据分布方案，上述对比并不是唯一考量点。例如将原系统由MySQL迁到OceanBase时，如果原系统使用分库分表方案，那么为保证平滑迁移，OceanBase中也可以考虑使用分库分表方案。