阻抗失配测试：您的数据层是否一团糟？

“大多数信息都是无关紧要的，大部分努力都白费了，但只有专家知道该忽略什么。” — James Clear，Atomic Habits 您有一个包含许多不同系统的精美数据管道。表面上看起来很复杂，但实际上它的引擎盖下是一团复杂的混乱。连接不同的部件可能需要大量的管道工作；它可能需要持续监控；它可能需要一个拥有独特专业知识的大型团队来运行、调试和管理它。您使用的系统越多，您复制数据的位置就越多，数据不同步或过时的可能性就越大。此外，由于这些子系统中的每一个都是由不同公司独立开发的，它们的升级或错误修复可能会破坏您的管道和数据层。如果您不小心，您可能会遇到以下三分钟视频中描述的情况。我强烈建议您在继续之前观看它。复杂性的出现是因为即使每个系统表面上看起来很简单，但它们实际上将以下变量带入您的管道并可能增加大量复杂性： 协议——系统如何传输数据？ （HTTP、TCP、REST、GraphQL、FTP、JDBC）。迁移——系统是否提供了一种将所有数据迁移到系统中或从系统中迁移出的简单方法？数据格式、模式和协议等变量加起来就是所谓的转换开销。性能、持久性和可扩展性等其他变量加起来就是所谓的管道开销。总之，这些分类导致了所谓的“阻抗失配”。如果我们可以测量它，我们就可以计算复杂性并使用它来简化我们的系统。我们稍后会讲到。

现在，您可能会争辩说，您的系统虽然看起来很复杂，但实际上是满足您需求的最简单的系统。但是你怎么能证明呢？换句话说，您如何真正衡量和判断您的数据层是真正简单还是复杂？其次，当您添加更多功能时，您如何估计您的系统是否会保持简单？也就是说，如果您在路线图中添加更多功能，您是否还需要添加更多系统？这就是“阻抗失配测试”的用武之地。但让我们首先看看什么是阻抗失配，然后我们将进入测试本身。该术语起源于电气工程，用于解释电阻抗不匹配，导致能量从 A 点传输到 B 点时损失能量。简单地说，这意味着您拥有的与您需要的不匹配。要使用它，您需要将现有的东西转化为您需要的东西。因此，存在与修复不匹配相关的不匹配和开销。现代企业依赖于实时数据的力量。借助 Redis Labs，组织可以以高度可靠和可扩展的方式提供即时体验。 Redis Labs 是 Redis 的所在地，Redis 是全球最受欢迎的内存数据库和 Redis Enterprise 的商业提供商。在我们的案例中，您拥有某种形式或数量的数据，您需要先对其进行转换，然后我们才能使用它。转换可能会发生多次，甚至可能会在两者之间使用多个系统。

转换开销：系统处理或存储数据的方式不同于数据的实际外观或您对它的看法。例如：在您的服务器中，您可以灵活地将数据存储在多种数据结构中，例如集合、流、列表、集合、数组等。它可以帮助您自然地对数据进行建模。但是，您随后需要将此数据映射到 RDBMS 或 JSON 文档存储中的表中以存储它们。然后做相反的读取数据。请注意，面向对象语言模型和关系表模型之间的特定不匹配称为“对象-关系阻抗不匹配”。管道开销：您在服务器中处理的数据量和数据类型与您的数据库可以处理的数据量不同。例如：如果您正在处理来自移动设备的数百万个事件，您的典型 RDBMS 或文档存储可能无法存储它，或提供 API 来轻松聚合或计算这些事件。所以你需要特殊的流处理系统，比如 Kafka 或 Redis Streams 来处理它；而且，也许是一个数据仓库来存储它。测试的目标是衡量整个平台的复杂性，以及随着您将来添加更多功能，复杂性是增加还是减少。测试的工作方式是使用“阻抗失配得分”(IMS) 简单地计算“转换开销”和“管道开销”。这将告诉您您的系统相对于其他系统是否已经很复杂，以及随着您添加更多功能，该复杂性是否会随着时间的推移而增加。该公式只是简单地将两种类型的开销相加，然后将它们除以特征数量。这样，您将获得总开销/功能（即复杂性分数）。为了更好地理解这一点，让我们比较四种不同的简单数据管道并计算它们的分数。其次，让我们假设我们正在分两个阶段构建一个简单的应用程序，以便我们可以看到随着时间的推移添加更多功能时 IMS 分数如何变化。假设您从移动设备收到数百万个按钮点击事件，如果有任何下降或峰值，您需要警报。此外，您正在考虑将这整个事情视为大型应用程序的一个功能。

案例 1：假设您只是使用 RDBMS 来存储这些事件，尽管这些表可能不适合。案例 2：假设您使用 Kafka 处理这些事件，然后将它们存储在 RDBMS 中。案例 3：假设您使用 Kafka 处理这些事件，然后将它们存储到 KsqlDB 管道开销 = 1 您只有一个系统（Kafka + KSqlDB）。请注意，我们忽略了 Zookeeper。案例 4：假设您使用 Redis Streams 处理这些事件，然后将它们存储到 RedisTimeseries 中。 （两者都是 Redis 的一部分，并且与 Redis 一起本地工作）。我们在这个例子中比较了四个系统，发现Case 3 或Case 4 是最简单的，IMS 为1。在这一点上，它们都是相同的，但是当我们添加更多功能时，它们会保持不变吗？让我们为我们的系统添加更多功能，看看 IMS 的表现如何。

假设您正在构建相同的应用程序，但希望确保它们仅来自列入白名单的 IP 地址。现在您正在添加一个新功能。案例 1：假设您只是使用 RDBMS 来存储这些事件，尽管表可能不适合，并且他们使用 Redis 或 MemCached 进行 IP 白名单。转换开销 = 1 对于 IP 白名单，您不需要任何转换。但是，您需要将事件流转换为表。转换开销 = 1 对于 IP 白名单，您不需要任何转换。此外，Kafka 可以轻松处理流。管道开销 = 3 你有 Redis + Kafka + RDBMS。注意：我们忽略了 Kafka 也需要 Zookeeper。如果你加上它，这个数字会进一步下降。转换开销 = 0 对于 IP 白名单，您不需要任何转换。此外，Kafka 和 KsqlDB 可以轻松处理流。管道开销 = 2 你有 Redis + (Kafka + KsqlDB)。注意：在这种情况下，我们正在考虑同一系统的 Kafka + KsqlDB 部分。

转换开销 = 0 对于 IP 白名单，您不需要任何转换。此外，Redis Streams 和 RedisTimeseries 可以轻松处理流和警报。管道开销 = 1 你有 Redis + Redis Streams + Redis TimeSeries。注意：在这种情况下，所有三个都是同一系统的一部分。因此，在我们的示例中，IMS 得分最低之一的案例 4 实际上随着我们添加新功能而变得更好，最终得分为 0.5。请注意：如果您添加更多或不同的功能，案例 4 可能不是最简单的。但这就是 IMS 分数的想法。只需列出所有功能，比较不同的架构，看看哪一个最适合您的用例。为了使其更易于使用，我们为您提供了一个计算器，您可以在一个简单的电子表格中使用它来计算 IMS 分数。对于每个数据层或数据管道，只需列出： 路线图中的功能。这很重要，因为您希望确保您的数据层可以继续支持即将推出的功能，而不会产生任何额外的开销。对不同系统的管道重复步骤 2 和 3 以比较和对比它们。

转换开销（你需要转换你的存储方式吗？你需要一个 lambda 函数来转换吗？） 管道开销（你需要多少个新系统？如果没有新系统，输入 0） 转换开销（你需要转换你的存储方式吗？存储？你需要一个 lambda 函数来转换吗？） 管道开销（你需要多少个新系统？如果没有新系统，输入 0） 很容易被冲昏头脑并构建一个复杂的数据层而不考虑后果。创建 IMS 分数是为了帮助您意识到自己的决定。您可以使用 IMS 分数轻松比较和对比您的用例的多个系统，并查看哪个系统最适合您的功能集。您还可以验证您的系统是否能够承受功能扩展并尽可能保持简单。 “大多数信息都是无关紧要的，大部分努力都白费了，但只有专家知道该忽略什么。” — James Clear，原子习惯