今天的话题有两层含义，第一层是说相对于我们所熟知的集中式数据库来说，分布式数据库是与之不同的。在做数据库选型的时候，我们要充分的了解其间的不同，才能做出较为科学的决策。我想很多数据库从业人员都了解其中的不同，不幸的是，他们不是数据库选型的决策者，大多数决策者并不了解这一点。
关于分布式数据库与集中式数据库的不同，我上周已经发文讨论过了，今天我要讲的是另外一个问题，那就是不同的分布式数据库产品也是不同的。
2013年，我和一些准备开发一款分布式数据库的朋友在讨论这个产品的时候，实际上大家对数据库，特别是分布式数据库都不太了解。我们给这款数据库提出的目标是：
图片
首先是超大规模，都分布式数据库了，肯定是要能解决集中式数据库的容量不足的问题的，因此超大是必须的，超大规模的数据库可以解决存储容量、计算容量与超大规模计算的速度等一系列问题；可动态扩展，不够用了就扩节点；无需备份，自动容灾，自动故障切换；有了上面这一条，那么保证永远在线，永不出错也就不是难事了。不过实际上今天看来，当时对数据库的了解太粗浅了，十年过去了，我还没看到这个数据库产品出现。
目前的分布式数据库产品种类繁多，技术路线也各有不同，我今天不准备对其做准确的分类，而是从几个小角度来看看这些数据库产品之间的不同。首先是从存算分离和对等分布式这两种最为典型流派说起。分布式数据库要么采用存算分离架构，要么采用对等分布式架构。其典型产品就是TiDB和OceanBase。
存算分离，顾名思义，其计算引擎和存储引擎是完全分离的，计算引擎负责SQL的执行，存储引擎负责管理被存储的数据。彻底的存算分离的数据库，其最典型的特点是创建数据表的时候不需要SHARDING KEY，数据存储的分片是数据库内部自动管理的。当SQL引擎需要访问某个数据的时候，会根据元数据信息以及分片逻辑，自动找到所需要访问的数据。存算分离的数据库，计算节点可能只有一个，也可以是一个读写节点，多个只读节点，甚至也可以是多个全功能对等的读写节点。比如TiDB，其TiDB节点是计算节点，多个计算节点是对等模式的，全功能读写的。其TiKV是存储节点，负责存储所有的数据。
对于存算分离的分布式数据库，计算节点生成SQL的执行树后，会把算子下推到多个存储节点进行并行的数据扫描或者访问。算子的并行化程度以及能够下推的粒度决定了执行的效率。因此此类数据库的性能取决于SQL执行计划的水平与可下推的算子的粒度。
有些存算分离的数据库，其存储节点是一个独立的数据库实例，这种情况下，大部分算子是以子SQL的形式下推到存储节点的，其效率相对是较低的。当然，数据库厂商也可以就其数据库引擎的核心进行改造，使之能够接受更细小的算子的下推，从而提高执行性能。有些基于Postgresql等开源代码的分布式数据库，比如Gaussdb就是这么做的。
谈到Gaussdb，这里就多说几句，实际上Gaussdb是一种存算分离的分布式数据库，其CN是计算节点，DN是存储节点。不过Gaussdb与TiDB虽然说都是采用存算分离，但是其实现方式差异很大。Gaussdb的CN/DN实际上都包含了一个全功能的RDBMS实例，甚至客户端可以直接连接到DN上去做SQL的执行。而TiDB的计算与存储引擎的功能是完全分离的，必须二者合体才能完成SQL执行的任务。对于Gaussdb来说，一个SQL可以将其子查询全面下发到DN上，CN只做简单的汇聚，CN也可以下推更细粒度的算子到DN上，由CN完成更多的计算。基于Gaussdb的架构，如果我们要将一张表分布到多个DN上，那么我们就必须指定Sharding Key。
那么这两种存算分离架构哪个更优呢？还真的不太好说，TiDB可以像我们使用普通的集中式数据库一样来使用分布式数据库，这方面TiDB似乎更胜一筹，不过实际上并非如此。因为TiDB的完全存算分离，导致了计算节点的本地数据缓冲无法实现了，所有的数据访问都不能直接从本地缓冲里获取，而都必须通过存储节点获取。这导致了一些对延时要求较高的OLTP系统的性能无法满足，这就是所谓的“稳定的慢”。
对于一些复杂的表关联，大查询，其性能虽然说与架构相关，但是最终决定性能的还是CBO优化器的执行计划的效率，以及算子分解与并行下推的能力。因此存算分离的分布式数据库，能够以何种粒度下推算子与优化器的功力决定了最终的性能。对于存储节点是一个独立的数据库实例的分布式数据库而言，在最初的技术实现上，肯定下推的只是子SQL。下推比SQL粒度更小的算子必须在SQL引擎的核心上做工作，因此对技术要求更高。当然随着产品的发展，这种工作是必须要做的。不过目前很多采用此类架构的分布式数据库的存储引擎采用了MySQL,对于此类数据库的核心代码的修改，如果不开源，是否违反了GPL协议，我一直百思不得其解。
分布式数据库的另外一个主要流派就是对等分布式，其代表是OceanBase。此类数据库是采用分片技术的，每个分片是一个完整的rdbms实例，具有计算引擎，并带有存储引擎，用于管理本地的数据。客户端连接到任何一个分片，都可以执行SQL，不需要通过一个计算节点。这种架构的缺点是如果要把一张表打散到分布式集群中，这张表必须指定Sharding Key。不过优点是每个节点都可以通过本地缓存来提高本地数据的访问性能。
今天的讨论我主要想让读者了解，没有完美的分布式数据库架构，如果我们要来看一个分布式数据库的水平，不仅仅要看起实现架构，更重要的是要看其SQL引擎、CBO优化器和分布式执行器的能力。谁家的产品把这些做好了，就能脱颖而出。
