今天早上我在上班的路上开始思考这篇文章。7点20进办公室开始写作。我在8:40完成了它。才用了一个多小时，难免有些意见没有考虑好。请原谅我。如今，国内的分布式数据库市场非常热闹。仅事务型关系数据库就有近百种。大家在选择数据库的时候很容易迷茫。之前也写过一篇文章讨论，没有完美的数据库，用户应该根据自己的场景和应用需求，选择适合自己的数据库产品。数据库架构也是一个重要的选择因素，尤其是对于分布式数据库。不同架构的优缺点非常明显。一些分布式数据库的缺陷由于架构问题而难以解决。因此，了解一个分??布式数据库，了解该数据库属于哪种架构，有哪些优缺点是非常重要的。分布式数据计算主要有两种形式，一种是分区SHARDING，另一种是全局一致的HASH。根据分布式数据计算的不同类型，衍生出两种类型的分布式计算：存储计算分离和存储计算集成。数据库架构。又细分出一系列子类，比如点对点模式、代理模式、插件模式等。SHARDING模式下最典型的分布式数据库是Oceanbase。下面是OB的架构图：每个Observer都是一个独立的计算和存储一体的服务，有SQL引擎、事务引擎和存储引擎，存储部分碎片化数据（partition）。OB采用点对点模式，客户端连接任意一个OBSERVER都可以使用功能齐全的数据库。OBSERVER会自动生成分布式执行计划，将算子分发给其他参与协同计算的OBSERVER，完成分布式计算。管理整个集群的RootService只存在于部分Observer中，全局只有一个是master，其他都是standby。实际上，每一个OBSERVER都构成了一个完整的数据库。如果所有的数据都存储在一个OBSERVER上，我们的访问方式就类似于一个中心化的数据库。该架构下的数据分区采用高可用。一条数据写入主副本（Leader）后，会自动同步到N个备份副本。OB采用Paxos分区选举算法实现高可用。其备用副本可用于只读或弱一致性读（副本数据延迟时），以充分利用多个副本的资源。实际上，不同分布式数据库的主从副本在使用上存在很大差异。一些分布式数据库的二级副本平时不能提供读写，只能用于高可用。看到这里，你可能会觉得OB的结构还是不错的，各种问题都考虑的比较周到。但是还是那句话，没有完美的分布式数据库架构，SHARDING存储要求分布在每个SHARDING分区的分区表都有一个SHARDINGKEY，根据SHARDINGKEY进行分片。虽然SHARDING模式对于一般的数据库操作没有问题，但是如果在复杂的查询语句中没有SHARDINGKEY，那么就没有办法基于SHARDINGKEY做分区剪枝。这个算子必须分布到集群中存储这个表分区的所有OBSERVER上，这种情况称为SHARDING数据库的读放大。对于使用SHARDING模式的数据库系统，需要区分其技术等级。重点看readamplification的措施是否完善，以及你的应用系统能否采用这些方案来让readamplification的影响变小。其实OB在这方面做了大量的工作。我们今天不讨论太空问题。既然存储和计算一体化的SHARDING模式有这个缺陷，那么是否可以采用存储和计算分离的方案呢？我们来看看TIDB的架构：TIDB采用存储计算分离，计算引擎TIDB和存储引擎TIKV是分离的，所以TIDB不存在存储计算一体的SHARDING分布式数据库的读放大问题。看来TIDB还得更上一层楼，完美解决OB等SHARDING数据库的问题。但其实并没有那么简单，就像我上大学时我的老师陈道柱老师说的，“好东西都是有价格的”。问题。那就是计算节点的局部缓冲问题。由于在大规模分布式计算环境中实现缓冲区融合的成本极高，每个TIDB节点只能有一个本地缓冲区，不能有全局缓冲区。因此，TIDB的SQL引擎上没有全局的DB缓存，TIDB的数据缓存只能建立在TIKV和TIFLASH上。SQL引擎->DBCACHE->存储路径->数据存储介质传统数据库的数据读取模式变成了SQL引擎->本地缓冲区->存储路径（网络）->存储节点缓冲区->存储介质这种模式。其效率大大降低。为了解决这个问题，采用这种架构的数据库系统必须使用更快的存储介质来解决缺少全局DBCACHE支持的问题。当然，这个问题也不是无解的。大部分问题都可以通过更细化的算子下推和像ORACLE的SMARTSCAN这样的技术来解决。事实上，国内分布式数据库最常用的架构并不是以上两种，而是基于SQL代理的存储计算分离架构。本架构采用的数据存储方式也是SHARDING方式，但是使用了一个SQLPROXY。腾讯TDSQL、热扑HOTDB、中兴GOLDENDB、百度GAIADB、京东STARDB、openGauss分布式计算框架等著名的分布式数据库都采用了类似的架构。TDSQL由三个核心组件组成：调度器、网关、Agent加MySQL。scheduler用于调度分布式计算，内部分为zookeeper和schedulerserver。接入网关是一个SQL代理，应用连接到接入网关上。对其执行SQL操作。代理与MySQL实例一起构成数据节点。多个数据节点构成一个服务单元SET。每个SET都是一个高可用组，由一主多备组成。数据按照SET进行SHARDING分区。该架构中的存储引擎是一个完整的数据库。大多数采用这种架构的分布式数据库都以MYSQL作为存储引擎的核心。这是因为MYSQL管理起来相对轻量级，大多数问题都是孤立的。失败或重启实例即可解决。这种架构在网关（代理）层具有分布式计算的能力。在这一层对SQL进行分解，生成分布式执行计划，然后将分解后的SQL分发给所有参与本次计算的存储节点，由存储节点执行SQL，获取需要的数据集，传送给网关，网关进行聚合计算。该架构底层包含完整的数据库引擎，因此主要的研发精力可以放在网关SQL引擎上，大大降低了开发难度。但是，虽然很多数据库产品都采用了这种架构，但是每个厂商的技术能力都不同，所以生产出来的产品在性能和SQL支持能力上都有很大的差距。在存储层使用完整的数据库引擎也是一把双刃剑。如果数据库引擎的优化器没有做很大的优化，数据库引擎的性能弱点会损害整个分布式数据库的性能，优化是个大问题。投入工作。两全其美也是不可能的。此外，高可用方面的主从选择和主从算法的实现程度也会影响该架构数据库的用户体验。最初，这类架构的主从切换类似于MYSQL的主从切换，对前端应用的影响很大。如果主DN在业务高峰期出现故障，那将是灾难性的。现在一些龙头企业在这方面做了很大的优化，用户体验也有了很大的提升。也有一些分布式数据库使用了SQLONHADOOP架构，比如EasyJingJie。它的存储引擎是经过优化的HBASE兼容引擎，整个分布式数据库系统都建立在它之上。这种架构的好处是底层采用了非常成熟的分布式存储系统HDFS和分布式数据库HBASE，自然对大数据量的计算和物联网场景的应用有更好的支持。但是由于HADOOP本身并不是为低延迟高并发的OLTP场景甚至HTAP场景设计的，存储引擎很可能成为未来数据库的瓶颈。2017年在贵州见到易经界CTO丁宏先生时，他也认为易经界要脱胎换骨，必须重写存储引擎，使其更适合HTAP应用场景。时间紧迫，今天的聊天到此结束，看来我们还没有聊完。其实对于这篇文章的标题“没有完美的分布式数据库架构”，我们不妨先把关于我们的分布式数据库架构好坏的争论搁置一旁。每个人都应该考虑自己架构的不足，想办法弥补自己的不足。它对用户负责。解决分布式计算的问题，在分布式SQL引擎优化、算子下推、避免读放大、主副本切换、读写分离、提升运维可观察性等方面，都需要认真持续改进。选择分布式数据库，光看架构是不够的，更重要的是数据库厂商有没有对我们的应用场景进行优化，产品是否能够满足我们应用场景的需求。
