认为系统中的数据远比构成它的实际应用程序更有价值，这有点陈词滥调。这些应用程序被更新、变异、退役和替换，但数据仍然存在。对于许多企业来说，这些数据是他们最重要的资产。过去很简单。您拥有_该_组织的数据库。只有一个地方可以存储组织所做和知道的所有事情，并且您可以去那里满足所有需求。一个用于管理、监控、优化、备份等的数据库——管理整个组织的数据需求。
随着组织的发展，有越来越多的数据，因此更多的需求和要求被添加到数据库中。在某些时候，你达到了你能做的绝对极限。您不能再使用单个数据库了；您必须将您的系统和数据库分解为独立的组件。在本文中，我将讨论如何管理数据范围和大小的增长。
共享数据库的消亡：为什么我们无法获得更大的机器
虽然并不常见，但目前使用具有数十亿条记录的 TB 级数据库并不少见。那么问题是什么？问题不在于特定数据库引擎的技术限制。这是将所有东西（包括至少两个厨房水槽和一个生日蛋糕）放入单个数据库的组织重量。例如，在我合作过的一家公司，_数据库_中有超过 30,000 个表。视图和存储过程的数量要高得多。我们不会谈论触发器的数量。
没有任何用于处理数据库的工具可以处理这么多的表。通过任何 GUI 工具连接到数据库通常会导致该工具一次冻结几分钟，同时它会在很短的时间内读取模式描述。绝对没有人真正知道该数据库内部发生了什么，但数据和围绕它的流程对于组织的成功至关重要。唯一的选择是要么停滞不前，要么开始将数据库分成可管理的块。
那是很多年前的事了，行业格局已经发生了变化。今天，在考虑数据时，我们有更多的问题需要处理，例如：
- 属于欧洲公民的个人数据，这意味着与他们相关的任何数据也必须实际居住在欧盟并受 GDPR 规则的约束。
- 医疗保健信息（直接或间接），需要遵循一套全新的规则（例如，HIPAA、HITECH 或 ENISA 规则）。
数据隐私和出处等问题更为重要，例如能够审计和分析谁访问了特定数据项，以及为什么它在许多领域都是一项硬性要求。将组织中的所有信息存放在一个存储桶中的概念不再可行。
另一个重要的巨变是常见的建筑模式。我们现在不再使用单一的单一系统来管理组织中的所有内容，而是将系统分解为更小的组件。这些组件有不同的需求和要求，按不同的时间表发布，并使用不同的技术。当您需要进行更改时，尝试在所有这些团队之间进行协调的巨大开销是您想要对系统进行更改时的一大障碍。这么多团队和组件之间的协调成本实在是太高了。
通常使用独立应用程序数据库的概念，而不是使用单个共享数据库。这是一个更大的建筑概念的重要组成部分。通常，您会在术语微服务和面向服务的架构下遇到这种情况。
应用数据库作为实施决策
从单个共享数据库迁移到一组应用程序数据库之间最重要的区别之一是我们没有拆分共享数据库。数据库级别的适当分离是关键。一组共享数据库将具有完全相同的协调问题，厨房里有太多厨师。应用程序数据库在适当分离时将使我们受益，它允许我们为每个任务选择最佳数据库引擎、本地化更改并减少通信更改的开销。这种方法的缺点是我们将在生产中支持更多系统。
让我们更深入地谈谈共享数据库和应用程序数据库之间的区别。很容易出错，如图 1 所示，例如：
图 1：从单个共享数据库到多个（仍然共享）数据库的错误迁移路径
虽然共享数据库是您实现的东西，因为没有其他选项，但应用程序数据库是一种内部选择，除了应用程序之外的任何人都不能_访问_。与我们在面向对象编程中的封装相同的意义上，使用隐藏我们状态的私有变量，应用程序数据库非常明确地是应用程序之外没有人关心的问题。我对这件事感觉很强烈。
当您编写代码时，您就_知道_直接使用其他对象的私有状态是错误的。您可能违反了不变量；您_将使_未来的维护和开发复杂化。这已经被大量敲定，以至于大多数开发人员几乎本能地不愿意这样做。当您直接接触另一个应用程序的数据库时，也会发生完全相同的情况，但这种情况非常普遍。
在某些情况下，我对数据库中所有表和列的名称进行了加密，以表明您不应该查看_我的_数据库。应用程序数据库是应用程序的内部关注点，没有其他人。这个想法很简单。如果应用程序之外的任何实体需要一些数据，他们需要向应用程序询问。他们不能直接进入应用程序的数据库来解决问题。这是询问“你在和谁说话”和查看他们所有的通话记录和消息之间的区别。理论上这是一个很好的方法，但是您需要考虑到您的应用程序很少是系统的应用程序。您必须与生态系统的其他部分集成。问题是你如何做到这一点。
如果此处描述的系统听起来很熟悉，那是因为您可能以前听说过它。它最初是作为 DCOM/COBRA 系统的一部分，后来称为面向服务的架构，现在称为微服务。
假设我们系统中处理运输的应用程序需要访问一些客户数据来完成其任务。它将如何获取这些数据？使用共享数据库时，直接查询客户表。当拥有客户应用程序的团队需要添加列或重构数据时，_您的_系统就会崩溃。它们之间没有封装或分离。直接依赖另一个团队的实现细节的路径会导致毁灭、停滞和不断增加的复杂性。我不是粉丝，如果你不能说。
使用全局数据
运输应用程序可以（通过已发布的服务接口）要求拥有客户数据的应用程序获取所需的详细信息。这通常通过从一个应用程序到另一个应用程序的 RCP 调用来完成。这里的问题是，这在两个应用程序之间建立了牢固的联系。如果客户的应用程序因维护而停机，则运输应用程序将无法工作。再加上几十个这样的应用程序及其相互依赖性，你就有了解决僵局的秘诀。我们需要考虑一种更好的方法来处理这种情况。
我的建议是从另一个方向进行整个过程。我们将反转事物，而不是运输应用程序查询客户的应用程序以获取相关数据。作为客户应用程序服务接口的一部分，我们可以决定要向组织的其他部分公开什么样的信息。
需要注意的是，我们发布的数据绝对是服务合同的一部分。我们不支持对我们数据库的直接访问。应用程序应将其数据发布到外部世界。这可以是上传到 FTP 站点或 GraphQL 端点的每日 CSV 文件，以选择两种截然不同的技术和语义。
我在 FTP 上包含了 CSV，以特别指出这种数据共享的_方式_是不相关的。重要的是，有一种从应用程序发布数据的既定方式，因为这种架构风格的一个关键方面是我们不会在需要时_查询_数据。相反，我们将其_摄取_到我们自己的系统中。我希望清楚为什么运输应用程序不只是打开到客户每日 CSV 转储文件的 FTP 连接来查找一些详细信息。同样，它不应该将 GraphQL 端点作为其正常例程的一部分进行查询。
相反，我们有一个既定的机制，通过该机制发布客户的数据（客户的应用程序已向组织的其他部分公开）。这由系统中的其他应用程序摄取，当他们需要查询客户的详细信息时，他们可以从自己的系统中进行。您可以在图 2 中看到它的样子。
图 2：客户的应用程序发布数据供运输应用程序使用
在每个应用程序中，数据可以以不同的方式存储和表示。在每种情况下，这对于他们的场景来说都是最佳的。
发布应用程序还可以以他们选择的任何方式处理数据。数据库之间的服务边界和数据发布方式允许自由修改内部细节，而无需与外部系统协调。
另一种选择是采用两阶段流程，如图 3 所示。客户的应用程序不会将其更新发送到运输应用程序，而是将其发送到组织数据湖。以这种方式，每个应用程序都将他们希望公开的数据发送到一个中心位置。其他应用程序可以将他们需要的数据从数据湖复制到自己的数据库中。
图 3：从每个应用程序发布到数据湖并将数据拉取到每个应用程序
最终结果是一个共享数据的系统，但没有应用程序和服务之间的时间依赖性。它还确保了不同团队和系统之间的边界。只要发布的接口保持不变，就不需要协调或复杂性。
在现实世界中应用这种架构风格
让我们深入探讨一些关于如何应用这种架构方法的具体建议。您可以通过在服务总线上发出事件或发布每日文件来全局发布数据。您可以发布特定场景的数据，例如从客户数据库到运输数据库的 ETL 流程。确切的_方式_并不重要，只要我们有适当的边界，我们可以改变我们的做法，而不会产生全球协调成本。
这种操作方式仅在我们需要引用数据或对不相关的数据做出决策时才有效。如果我们需要对数据进行或协调更改，则此方法无关紧要。一致性无关紧要的场景的一个很好的例子是从他们的 ID 中查找客户的姓名。如果我们有旧名称，那不是主要问题。它很快就会自行修复，我们不会根据客户的姓名做出决定。同时，我们可以在应用程序范围内运行所有计算并完全在本地工作，这是一个很大的优势。
当我们需要做出决定或修改数据时，一致性很重要。例如，在海运场景中，如果我们需要收取超重运费，我们需要确保客户账户中有足够的资金（并且我们需要扣除运费金额）。在这种情况下，我们无法对自己的数据进行操作。毕竟，我们不拥有账户中的资金。我们也不能直接改变它。在这种情况下，我们需要去客户的申请中，要求扣除这些资金，如果资金不足，则提出错误。请注意，如果客户无法付款，我们希望运输过程失败。
我们的应用程序不再部署到单个服务器甚至单个数据中心。如今，在边缘系统（例如移动应用程序或物联网设备）上运行应用程序是很常见的。将所有这些数据推送到我们自己的系统可能会导致我们存储_大量_数据。这种数据封装和只发布我们希望向其他方公开的细节的架构风格在这种情况下表现得非常好。
无需将所有信息复制到中心位置，我们可以将数据存储在边缘，并从边缘设备接收足够的数据，以便能够做出决策并操作系统的全局状态。除其他优点外，这种方法使用户可以控制他们的所有数据，我认为这是一个主要优点。
总结
在架构中使用应用程序数据库和显式发布数据有几个原因。首先，这意味着这些行动是利用当地资源和最少的协调进行的。反过来，这意味着操作将更快、更可靠。其次，它减少了全面的协调开销，这意味着我们可以根据需要独立部署和更改每个应用程序。
最后，这意味着我们可以独立地为每个场景选择最佳选项。我们可以为每个选项选择最好的品种，而不是迎合最低公分母。例如，我们可以使用文档数据库来存储运输清单，但将历史数据放入数据湖中。
每个应用程序都是独立且相互隔离的，我们可以为每个场景做出最佳的技术选择，而无需考虑任何全局约束。结果是一个更容易改变的系统，由更小的组件组成（因此更容易理解），而且更加敏捷。
这是 DZone 的 2022 年数据库系统趋势报告中的一篇文章。阅读报告
原文标题：Data Management in Complex Systems
原文作者：Oren Eini
原文地址：https://dzone.com/articles/data-management-in-complex-systems
