这是“没有完美”系列的第三篇，以前我写过《没有完美的数据库》，《没有完美的存储引擎》，今天我们来聊聊目前最为热门的分布数据库架构。大家要注意今天我们讨论的不是分布式数据库本身，而是分布式数据库架构。分布式数据库太复杂了，也太多了，要想简单分析一下够一篇万字长文了，今天我们重点来分析一些目前最常见的国产分布式数据库架构，即使缩小到这个话题，实际上也是十分复杂的，我们今天只做一些粗略的分析。如果有朋友觉得这篇文章还算有点价值，并且对其中某些点希望进一步分析，请留言通知，我找时间写一些。这篇文章是今天早上在上班路上开始思考的，7点20进入办公室开始写，8点40写完，只用了一个多小时，因此难免一些观点有些考虑不周，请读者见谅了。现今国产分布式数据库市场十分热闹，仅仅是交易型关系型数据库就有近百款，大家在选择数据库的时候也容易挑花了眼。以前我也写文章讨论过，没有完美的数据库，用户应该根据其场景和应用需求来选择合适自己的数据库产品。数据库架构也是其中的一个重要的选择要素，特别是分布式数据库，不同的架构其优缺点十分明显，某些分布式数据库存在的缺陷因为架构问题，是较难解决的，因此了解某个分布式数据库属于哪种架构，有哪些优点和缺点十分重要。分布式数据计算最主要有两种形式，一种是分区SHARDING，一种是全局一致性HASH，根据这种分布式数据计算的种类不同，衍生出存算分离和存算一体这两种分布式数据库架构。进一步再分出一系列子类别，比如对等模式，代理模式，外挂模式等。
每个Observer是一个计算存储一体化的独立服务，带有SQL引擎，事务引擎和存储引擎，并存储一部分分片数据（分区）。OB采用的是对等模式，客户端连接到任何一个OBSERVER都可以全功能使用数据库。OBSERVER会自动产生分布式执行计划，并将算子分发到其他参与协同计算的OBSERVER上，完成分布式计算。管理整个集群的RootService只在部分Observer中存在，并全局只有一个是主的，其他都是备的。实际上每个OBSERVER就组成了一个完整的数据库，如果所有的数据都存储于一个OBSERVER上，我们的访问方式类似于一个集中式数据库。这种架构下的数据分区采用了高可用，一个数据写入主副本（Leader）后会自动同步到N个备副本，OB采用Paxos分区选举算法来实现高可用。其备副本可以用于只读或者弱一致性读（当副本数据存在延迟时），从而更为充分的利用多副本的资源。实际上不同的分布数据库的主备副本的使用方式存在较大的差异，有些分布式数据库的备副本平时是不能提供读写的，只能用于高可用。大家看到这里，可能觉得OB的架构不错，各种问题都考虑得比较周到了。不过还是那句话，没有完美的分布式数据库架构，SHARDING存储需要分布在各个SHARDING分区中的分区表要有一个SHARDING KEY,根据SHARDING KEY来做分片处理。SHARDING模式虽然应对一般的数据库操作是没问题了，不过如果一条复杂的查询语句中没有关于SHARDING KEY，那么就没办法根据SHARDING KEY去做分区裁剪，必须把这个算子分发到集群中存储这张表的分区的所有OBSERVER上，这种情况被称为SHARDING数据库的读放大。采用SHARDING模式的数据库系统，你要区分其技术水平，重点要看针对读放大的措施是否完善，你的应用系统能否采用这些方案来让读放大的影响变得更小。 「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
