分布式SQL可以解决的三个NoSQL挑战

2022年7月7日

在本节中，我们将探讨使用当代NoSQL数据库的三个挑战：操作复杂性、令人沮丧的应用程序开发和不一致的客户体验。

1.NoSQL操作复杂性

如前一节所述，数据库已经演变为云托管，但远不是云原生的。组织机构当前的运营复杂性使其难以最大限度地利用现代云基础设施的弹性和地理冗余。除此之外，NoSQL最终一致性的核心增加了隐藏成本。这些问题包括损害性能的后台修复和不可预测的内存密集型压缩风暴。事实上，大多数企业在其持久数据库的旁边还运行一个独立的缓存层（如Redis或Memcache），这使得所有操作挑战变得加倍困难。

在最初需要以与应用层相同的阶段和速度移动数据层的情况下，上述操作的挑战使这种移动几乎不可能。如果运营团队强制这样做，那么这意味着业务损失，表现为不可预测的停机时间和手动、易出错的作战室。

2.令人沮丧的应用程序开发

应用程序开发人员渴望ACID事务的简单性。这样，他们就可以很容易地推理数据库客户端代码的读/写行为。关系数据库支持多行ACID，其中多个相关行以全有或全无且一致的方式更新或流动。然而，大多数NoSQL数据库甚至不支持单行ACID事务。这是因为（NoSQL）的最终一致性导致“C”（即一致性)在远程副本上妥协。

许多NoSQL数据库开始意识到强一致性的优势。因此，它们允许最终一致性的系统调整到基于仲裁的强一致性设置。然而，事实证明，这种形式的可调一致性在许多情况下并不真正强大。其中包括写入失败后的脏读和最后一个写入器获胜后的不可预测读。使用这种方法的开发人员深圳需要花更多的时间测试他们的应用程序，以保证可预测的行为。

还存在保持独立内存缓存层与底层持久数据库层一致的挑战。应用程序需要仔细处理缓存失效和缓存填充，以避免糟糕的性能。最后，由于大多数数据库只适合特定应用程序的需要，开发人员承担了评估新数据库的负担。

3.客户体验不一致

错误情况是不可避免的。这是开发人员为在最终一致的NoSQL数据库上构建强一致的OLTP/HTAP应用程序所做的所有调优工作。在这些错误情况下，不一致性会向最终客户显示。

例如，零售商的产品目录删除了一些商品，因为它们不再可用。但是，当数据发送给客户时，这些删除不被接受。这是因为节点尚未应用删除。

另一个示例涉及忽略一些时间序列度量数据。该数据计算时间序列监控和物联网（IoT）用例警报中的聚合。根据不正确的数据在清晨叫醒团队成员是不划算的。类似地，如果用户的隐私偏好没有立即得到尊重，则她的行为可能会出现在同一帐户中的其他用户。

使用分布式SQL解决NoSQL挑战

一个分布式SQL 数据库是部署在服务器集群上的单个逻辑关系数据库。数据库自动在多个服务器上复制和分发数据。这些数据库具有很强的一致性，支持云中可用性和地理区域的一致性。

分布式SQL数据库至少具有以下特征：

用于访问和操作数据和对象的SQL API
在集群中的节点之间自动分发数据
以高度一致的方式自动复制数据
支持分布式查询执行，因此客户端不需要了解数据的底层分布
支持分布式ACID事务

为什么是分布式SQL？

商业创新正在给传统的记录系统带来压力。这迫使公司更快地交付高价值应用程序和服务，同时通过法规遵从降低IT成本和风险。

但这些微服务形式的应用程序、云原生应用程序、边缘(计算)和物联网工作负载需要一种新的数据库类型，即：

具有故障恢复弹性并持续可用：关键服务在节点、区、区域和数据中心故障以及系统维护期间保持可用，并具有快速故障切换功能
水平可扩展：运营团队可以轻松扩展，即使在重载情况下也不会停机。他们可以通过简单地将节点添加到集群中并在负载减少时将其缩小来实现这一点
地理分布：运营商可以利用同步和异步数据复制和地理分区，以地理分布配置部署数据库
SQL和RDBMS功能兼容：开发人员不再需要在云原生系统的水平可伸缩性和传统RDBMS的ACID保证和强一致性之间进行选择
混合和多云就绪：组织可以在任何地方部署和运行数据基础设施，避免锁定任何特定的云提供商。