当今的应用程序（包括企业应用程序）需要始终开启且始终可用，并且通常必须为全球用户提供服务，这些用户无论身在何处都希望获得几乎即时的响应时间。
应对这些挑战不仅仅意味着让用户更满意：每个能够解决低延迟和超高可用性的根本问题的企业都会获得直接的底线收益。由于数据库在每个应用程序技术堆栈中都发挥着基础作用，因此解决这些问题最合理的位置是数据库层。实现这一目标的最佳且最具成本效益的方法之一是在分布式关系数据库之上部署应用程序。
我们首先考虑数据延迟的问题。许多应用程序都使用位于单个数据中心或云区域的单个数据库实例运行。靠近数据库运行位置的用户将看到快速响应时间，但位于对面海岸或大洋彼岸的用户将看到更慢的响应时间。对于电子商务应用程序，页面加载缓慢会导致销售损失，因为买家会失去耐心并转到竞争对手的网站或重新考虑购买。对于 SaaS 应用程序，用户体验受损可能会导致客户流失。
分布式“多主”数据库可以配置为在地理上分布的节点集群中运行，每个节点都可以接受读写流量。这使得可以策略性地将数据库副本放置在更靠近用户连接网络的位置。这显着减少了数据延迟，始终实现更快的页面加载，并防止销售损失和客户流失。
现在让我们看看超高可用性。我们这么说是什么意思？显然，应该避免停机，因为这意味着客户的沮丧和业务的损失，具体取决于停机的时间和范围。如果应用程序能够在硬件和数据中心中断后继续运行，则该应用程序具有高可用性。许多应用程序和数据库架构师将在一个或多个地理上分离的数据中心中配置和读取其数据库的副本，以便在主系统停机时进行故障转移。
这种方法存在几个问题。首先，在云中，只读副本可能位于同一区域的附近可用区中。云提供商确实有时会出现整个区域发生数小时故障的情况。事实上，最近几周，AWS 的 us-east-1 区域（最大的）和 Google 的 europe-west-9 区域都发生了这种情况，导致完全依赖它们的应用程序出现数小时的停机时间。架构和实施多区域故障转移解决方案可能很困难，这是许多组织尚未这样做的主要原因。此外，对于许多流行的开源数据库（例如Postgres）来说，在不关闭整个系统的情况下不可能进行软件维护和升级。
完全分布式的多主数据库解决了这些缺点。由于有多个节点处理读取和写入流量，因此一个节点发生故障只需将数据库请求重定向到任何幸存的节点即可。由于系统被设计为地理分布式，因此跨多个区域运行非常简单。软件升级可以逐个节点执行，避免了可怕的“计划维护”窗口。
也许您一直处于尴尬的境地，必须向您的首席执行官或董事会解释为什么当您的云提供商发生区域中断时您的应用程序会关闭。当他们吸收了云区域的概念后，你不可避免地会被问到为什么应用程序无法跨多个区域运行。使用分布式多主数据库，可以简单且经济高效地实现这一点。顺便说一句，如果您是 SaaS 公司的首席执行官或董事会成员，您可能想询问您的团队该公司的应用程序是否可以承受云区域中断！
最后，为什么我们在这里专门讨论关系数据库呢？毫无疑问，分布式数据库的优势在 NoSQL 世界中已经存在很多年了。然而，许多现有的企业应用程序都是建立在关系数据库之上的，关系数据库更加灵活，并且有更多的工具和人才来支持它们。通过将现有应用程序重新部署到分布式关系数据库之上，通常只需对应用程序代码进行有限的更改，即可为现有应用程序带来上述好处。这种迁移可以与从昂贵的遗留数据库解决方案迁移到 Postgres 等开源数据库一起完成，从而节省大量许可费用。Postgres 现在是开发人员中最流行的开源数据库，因此这将使您的开发人员和用户都满意。
总而言之，将应用程序迁移到分布式多主关系数据库可以带来巨大的收益。这些好处的形式是通过降低延迟来减少销售损失和客户流失，或者通过多主分布式架构避免停机。而且，如果您也转向开源数据库，您将拥有更满意的用户和客户以及更满意的开发人员，这几乎是一个额外的好处。
作者：Michael Bogan
