在过去的三个十年中，数据库的发展一直是全球各个行业和各种规模企业技术创新的重要组成部分。在 1990 年代末到 2000 年代初，数据库遇到了性能瓶颈。难的。互联网的成功，加上应用程序开发的爆炸式增长，导致了海量数据和前所未有的数据扩展速度。当时摄取这些数据导致了主要的数据库瓶颈。延迟增加和吞吐量降低是常见问题，这些问题破坏了业务生产力的齿轮，最终减缓了收入增长。这些问题从未真正消失。
这个巨大的数据库困境的核心是弹性问题——能够按需增加或减少数据库容量——同时保持高性能和理想情况下的低成本。运营团队和数据库工程师试图通过发展多种方法来应对扩展挑战，其中许多方法仍然存在于企业中。只有从这些方法的缺点中学习，我们才能找到一个不强制取舍的解决方案：分布式 SQL。
分片和NoSQL的问题
使用数据库之外的代码解决问题：分片或分区的概念，其中单个逻辑数据集可以拆分并存储在多个数据库中，以增加总存储容量并处理额外的请求，最终进入不同的数据库系统。但事实证明，分片是一种复杂而脆弱的方法，难以维护，工程成本高，允许有限的交易，并带有查询限制。对真正弹性的探索仍在继续。
然后，大约十年前，出现了一场引人注目的运动：NoSQL 热潮，沮丧的创新者提供了关系数据库的替代方案。从技术上讲，这种非表格方法自 1960 年代后期就已存在，但并未以任何广泛的方式针对业务用例。21 世纪初期的 NoSQL 方法让数据库行业退后一步，完全重新思考和改造存储和访问数据，以解决可扩展性问题。
虽然该方法确实消除了一些数据库和数据摄取问题，但它是有代价的。NoSQL 意味着放弃许多使关系数据库如此有用的关键东西——比如维护和跟踪数据完整性以及能够利用 ACID 事务。NoSQL 方法所需的原始查询、复杂的数据建模、低于标准的数据完整性、有限或不存在的 ACID 事务支持以及专门的工具使 NoSQL 成为大多数企业和中小型企业的首选。
关系革命：分布式 SQL
分布式 SQL提供 SQL 和 NoSQL 的最佳优势，以及关系和非关系数据库的优势，尤其是在高性能扩展方面。分布式 SQL 是由多个数据库实例或节点组成的单个逻辑数据库。
这个想法是，有了这个节点集群，开发人员可以简单地按需添加或删除节点，以适应存储和访问需求的变化。顾名思义，数据本身是分布式的，分成多个分区并跨多个节点复制。分布式 SQL 实现了无共享架构，集群中的单个节点满足每个更新请求，消除节点之间的争用，因为它们独立访问相同的内存或存储。
。。。
像MariaDB 的 Xpand这样的分布式 SQL 选项的架构是让所有节点一起工作以形成一个单一的逻辑分布式数据库，所有应用程序都可以指向它，而不管预期的用例如何。
如今，很多事情都被认为是革命性的或改变游戏规则的，但分布式 SQL 实际上配得上这些绰号。
banq评：画饼的同时不要忘记CAP定理