二者如何区分并没有明确定义，就算业内人士也多是观点不一，原因无非就是总没有人承认自家的产品是分库分表架构，总牵强附会的往原生分布式上靠。就像当初HTAP概念比较火的时候，一夜之间市面上所有数据库厂商都给自家产品打上了HTAP的标签。

目前两种技术架构的市场规模都存在且还在增长，如果业务系统能够进行改造，去除分布式事务，那么分库分表架构的性能是最好的，否则原生分布式数据库就是迁移与开发最方便的选择，所以两种技术本没有什么高低贵贱，只有业务应用上的合适与不合适。

我有一个简单的区分方式，如果某产品是基于MySQL（或PG）单机数据库实现的，计算过程中MySQL引擎起主要作用，并且数据又最终存储到MySQL库里面，那么你还说这是原生分布式，那就太过于“掩耳盗铃”“自欺欺人”了呢！

通过对OceanBase、TiDB、 CRDB这3个典型的原生分布式数据库分析，我们来看一下原生分布式数据库应该具备的三个最基础特征：

1，通过LSM-Tree的KV引擎存储数据

如今，存储设备已经从旋转磁盘过渡到SSD固态存储和NVME非易失性内存。传统的B树存储引擎是在旋转式机械磁盘IOPS和吞吐量不足的情况下，为了提升离散读写效率而设计的，在新的硬件设备上写入速度是非常有限的。面对现在普遍的海量数据、高并发交易产生的写入密集型业务，新一代的分布式数据库更喜欢采用LSM-Tree架构。

LSM-Tree 架构中将数据分为静态数据（放在SSTable中）和动态数据（放在MemTable中）两部分；

其中 SSTable 是只读的，一旦生成不会被用户直接修改，存储于磁盘；MemTable 支持读写，存储于内存。

数据库 DML 操作插入、更新、删除等首先写入 MemTable，只要memtable+log写完成，事务即可提交，写入性能大大提升；

等到 MemTable 达到一定大小时转储到磁盘成为 SSTable。SSTable也是多层存储结构，不同层级之间可能存在重复数据，当某一层数据量达到一定程度时就会发生向下层合并；这就是一种典型的用空间换时间的解决办法，所以lsmtree会有写放大的问题，但并不影响性能（因为合并是在事务提交以后进行的）。

在进行查询时，首先会访问MemTable ，在没有获得目标数据时，会依次逐层访问 SSTable，这就导致lsmtree读放大问题，而这是会影响性能的，通常数据库厂商为了解决这一问题，会为分布式数据库增加额外的数据缓存结构，减少系统对SSTable的直接访问。

2，通过一致性协议管理数据多副本

一致性协议是原生分布式数据库解决多副本一致性的技术，OB用的是paxos协议，TiDB和CRDB用的raft协议。

虽然两种协议在原生定义中实现方式有很大不同，但是确保副本数据一致性和性能体验的目标是一致的，这就使厂商必须对原生协议进行改造（例如multi-paxos，multi-raft），经过一系列工程实现，最终结果就是不管用raft还是paxos，都有比较趋同的实现效果，例如：

事务提交流程：都将数据副本分为leader和follower角色，然后使用一致性协议同步Leader的日志到 Follower，当有超过半数以上副本成员接收日志并落盘成功后，Leader 上的事务即可提交。

数据一致性保障：只有leader数据能够进行读写操作，follower在某些特殊设置下能够提供弱一致性读服务；leader通过租约lease进行维护，过期进行重新选主，实际上如果没有意外故障、触发自动优化机制，或者人为干预，leader角色一般不会发生变更。

高可用性保障：一旦leader发生故障，会对连接当前leader的业务产生影响，此时follower之间会自动进行选主，业务只需要重新连接数据库即可；如果少数follower发生故障，则对业务没有影响。

3，提供分布式SQL事务引擎。

分库分表有一个很大的缺陷，由于过于依赖MySQL等单机数据库引擎来处理事务，所以在跨节点做分布式事务处理时，要么性能严重下滑，要么就完全不支持；尤其对一些子查询等复杂SQL，甚至视图、存储过程等无法支持；因为在这些复杂对象、语法中很容易产生跨物理节点的事务。而原生分布式数据库对支持ANSI SQL标准，同时与分库分表架构相比，SQL语法几乎是没有限制的，这也正是“原生分布式”定义的由来，即从一开始就是为了处理分布式事务设计的数据库产品。

而OceanBase、TiDB、 CRDB这3者虽然都是原生分布式架构，但彼此之间还有多架构区别和专属特征，适合不同的客户和业务场景使用，一旦选错了也会让自己产生很多麻烦，这个我们下回再说~