对于适合事件流的数据库，它需要支持“实时”管理数据随时间的变化——以个位数毫秒或更短的时间测量。
并且可以以每秒数十万或数百万个事件的速度对数据进行更改。（未来还会有更高的利率。）
在查看数据库是否适合其事件流用例时，组织会考虑四个主要方面：
云原生
内在品质
事件驱动设计
最合适
让我们更详细地介绍其中的每一个。
云原生
今年早些时候，Foundry（前身为 IDG Communications）的一项研究发现，一半的组织仍然将大部分工作负载大部分放在本地。另外三分之一是“主要是云”，但仍然有一些本地服务。只有 7% 的组织是“全云”。
这种向云的转变正在迅速进行。“未来 18 个月，全云计算的数量预计将增加约 250%，达到 17% 的人计划将他们拥有的一切都转移到云端。”
即使用户不打算使用“全云”，他们也知道他们的系统至少需要与他们的云服务集成。他们需要在未来证明他们的技术选择。因此，“72% 的 IT 领导者表示，他们的组织在升级或购买新技术能力时默认使用基于云的服务。”
这种本地服务和云服务集成的关键是与事件流集成的能力。事实上，事件流服务被视为在不同系统之间保持多云和混合云部署的关键组件。
这对分布式数据库选择意味着什么？
对于许多人来说，这意味着询问供应商是否有数据库即服务 (DBaaS) 产品。如果他们这样做了，一个组织可以运行精益。他们可以专注于开发他们的应用程序，而不必配备数据库管理专家。如果他们不这样做，就会在采用方面产生组织摩擦。
组织还想知道解决方案是否被锁定在单个云供应商中，或者它是否是云中立的——可在任何地方部署。因为尽管少数组织仍然愿意专门致力于单一云供应商战略，但在 2022 年 Flexera 调查中，约90% 的受访者表示他们的团队已经制定了多云战略。因此，单一的云供应商数据库对采用来说是另一个障碍——它成为一种锁定，直接与他们的战略灵活性目标相矛盾。
下一个问题是是否或如何部署分布式数据库——仅在单个区域集群中，或跨多个数据中心和区域。
拥有真正的多数据中心架构与通过某种拼凑而成的跨数据中心更新机制保持系统跨区域同步之间存在巨大差异。前者设计为可靠、安全、双向（多向）；后者可能只是单向的，一个主数据中心将更新流向其他副本。当然，还需要一些组装，这会增加操作复杂性和安全问题。
“需要一些组装。”
云原生对不同的人来说意味着很多事情。它还可以推断出诸如弹性（动态配置以及根据需要扩展或缩减吞吐量和/或存储容量的能力）、运行无服务器（无需担心特定的底层硬件）或云编排 (Kubernetes) 等功能。基于各种角色和观点，从 DevSecOps 和 SRE，到性能和平台工程，还有很多考虑因素。
虽然许多供应商会声称自己是“云原生”，但他们可能的意思是，他们已经提升并转移了他们的开源或企业数据库，以便在云中运行，并在顶部涂上一层薄薄的“云”。这与从头开始实施不同，也不是为了确保从 API 和微服务集成、生态系统连接、SRE 和 DevOps 工具到帐户管理、计费和治理旨在使系统易于实施和使用。
内在品质
下一个考虑因素是所讨论数据库的内在质量。这些都是过去被概括为RAS 或 RASP的所有关键“能力” ——可靠性、可用性、可服务性和性能。虽然这个首字母缩略词让人联想到前云硬件时代，但它和许多其他品质都可以为这个云原生技术周期重新定义。
可靠性是最吸引站点可靠性工程师的关键品质。数据库将满足其服务水平协议 (SLA) 和服务水平目标 (SLO)。您不能依赖的数据库有什么好处？您甚至可以深入了解“可靠性”的含义，因为它还可以代表“耐用性”——系统对中断的恢复能力。或者它可能包含的反熵机制，例如优雅地处理中断或从中断中恢复、修复数据，甚至使用提示切换来赶上节点以应对暂时中断的能力。
如果您将数据推入一个大而快速的管道，而您的目的地处于离线状态，您会怎么做？这就是事件溯源很重要的原因——因此您可以逐步回顾事件流的所有阶段并找出您的结果应该是什么。但至关重要的是，您的生产数据库首先不会让您质疑它作为事实来源的可行性。
可用性（高可用性）是 ScyllaDB 等数据库和CAP 定理定义的所有“AP”模式数据库类的核心。虽然在事件流世界中肯定仍然存在强一致性（“CP”模式）数据库——SQL RDBMS 不会很快消失——但高可用性系统通常更适合事件驱动架构，高度异步并针对实时响应进行了优化。
像 ScyllaDB 这样的“AP”模式数据库通常更适合事件驱动架构
可服务性，如果采用现代云原生环境，则包含其他基本品质，例如可观察性、可管理性、可用性、设施等。您的数据库是否经过设计，以便您可以知道它在做什么？相反，如果它的行为不正常，你能告诉它该怎么做吗？可用性是采用的关键因素。现代分布式数据库并不“容易”。他们需要数据和查询建模、操作和管理方面的专业知识。但是您的系统是否不必要地不透明和迟钝？如果是这样，那么您可能会发现您的团队不愿学习与当前知识或行为完全正交的东西，即使不是完全积极地反对采用。
对我来说，“设施”不仅仅是“可用”。它问：“它易于使用和管理吗？” 跑步有防弹的感觉吗？或者它是一只脾气暴躁的野兽？运行它是一种乐趣，还是让组织像不断遭受低烧的瘴气一样痛苦？
这可以通过年度 Stack Overflow 调查来说明，该调查询问了数以万计的开发人员他们最喜欢和最害怕的数据库是什么。觉得他们当前的选择是一件可怕的苦差事的开发人员会寻找一些东西，任何东西，以随着时间的推移减轻他们的痛苦。那些享受工作的人不太可能转向新技术，或者放弃他们认为落后于时代的组织。喜欢他们部署的技术的用户不必考虑太多。数据库变得“不可见”，使他们能够专注于他们试图解决的技术问题。
性能也是这一关键因素的关键部分。让我们更具体地了解一下事件驱动架构的阻抗匹配。
事件驱动
现在让我们关注数据库是否真正为事件驱动架构而设计。它的特性和功能是否真的可以帮助您从面向批处理的世界发展到实时流媒体现实？
这有两个方面：接收器（消费者）和源（生产者）。
充当消费者（接收器）似乎很简单——这只是数据摄取，对吧？——但其中涉及许多微妙之处。系统如何处理时间序列数据？它如何对这些数据进行分区并在系统内分布？所有的写入都转到一个随吞吐量融化的热分片吗？其他分片是否保存“过时”数据，本质上是“一次写入，几乎从不读取”？（这在只允许一个节点成为可以写入的领导者的主副本系统上尤其成问题；所有其他节点都是只读副本。）
作为生产者（来源），还有更多必要的基础设施工作，例如对变更数据捕获 (CDC) 的支持，以便可以将对数据库的更改发布到主题。CDC 的实现可以有很大的不同，有些是经过精心设计和设计的；高效而全面。还有一些可能是事后的想法或补充，对性能有显着影响，并且在实施中是杂乱无章的。当您在支持的功能列表中看到“CDC”一词时，您真的想双击它，因为没有两个数据库供应商的实现是相同的。
此外，虽然它很微妙，但重要的是要注意，要真正成为“事件溯源”解决方案，数据库需要记录所有数据状态，事件后的事件。因此，您可能需要保留数据记录的前值和后值；不仅仅是差异。另外，您的用例将决定这些记录需要保留多长时间。
事件流中的阻抗匹配对于保持组织数据的“当前”流动而没有阻力或信号丢失非常重要
要真正与您的事件流系统配对，您使用的数据库和您正在实施的事件流架构都需要具有“阻抗匹配”。如果数据库太轻量级或太慢而无法跟上事件流的容量，它很快就会变得不堪重负且无法使用。相反，如果您的事件流无法跟上您的操作事务数据库的更新速度，您可能会发现您无法使企业的其他部分与事实来源中发生的最新变化保持同步。
最适合用例
仅仅因为您熟悉特定数据库并不意味着它最适合这项工作。也许你熟悉 SQL。但是这个用例的数据结构和高可用性和吞吐量是否需要您考虑使用 NoSQL 数据库？您是否熟悉 NoSQL，但实际上，对于这种高度一致的用例，您将需要表和连接以及第三规范化形式？那么这听起来像是 SQL 的工作。
在这里，用户应该考虑他们正在设计什么样的应用程序。他们有什么样的吞吐量和延迟要求。数据集扩展（千兆字节？太字节？拍字节？），包括总量和随时间的增长。
然后，他们应该查看最有效和最容易获得他们正在寻找的数据结果所需的数据模型和数据查询语言。这是读取或写入繁重的工作负载，还是混合读写？是事务更新，还是分析范围或全表扫描？数据处理的速度有多快？是否需要亚毫秒、毫秒、秒甚至分钟+范围内的结果？
速度也可以用吞吐量来衡量。您每秒有数百个查询，还是数千个或一百万个或更多？吞吐量本身可以被视为每秒的操作或事务，也可以根据总容量或有效负载来查看。因为全表扫描的结果集将与单个对象或行结果查询大不相同。
最后，也是所有人最关心的问题，组织愿意为这个解决方案承担的价格/成本是多少？它有什么样的 TCO 或 ROI 目标？因为出于性能目的听起来很可爱的东西可能会让您在到期时对每月账单感到茫然。
例如，DBaaS 选项可能看起来比开源更昂贵（“它是免费的，对吗？”），但从长远来看，商业服务可能具有实际上可以为您的组织节省更多成本的功能，无论是在运营还是管理开销方面.
考虑到所有这些考虑因素，您现在有了一个通用的量规，您可以根据该量规对您的用例选项的简短列表进行评分。
NoSQL 数据库的事件流式处理之旅：ScyllaDB
那么让我们看看这个标准是如何给开源 NoSQL 数据库 ScyllaDB 打分的。如果您使用不同的数据库，请自行考虑您自己的技术选择如何叠加。
首先，让我们看看 ScyllaDB 是从哪里开始的事件流之旅。ScyllaDB 的工作于 2015 年正式开始——进入事件流时代。它的创始人认识到 Kafka 和 Pulsar，并且在 ScyllaDB（和 Confluent）历史早期的博客中谈到了连接 Kafka 和 ScyllaDB 的优点（请参见此处、此处、此处和此处）。
原因很简单：Kafka 是一个高度可扩展、高性能的事件流架构，而 ScyllaDB 是一个高度可扩展、高性能的 NoSQL 数据库。
ScyllaDB 旨在以每秒数百万次操作获得个位数的 P99 延迟。它不仅可以扩展到任意数量的服务器，而且基于 Seastar 框架的基础，还可以扩展到每台服务器的任何核心数。
它的点对点主动-主动拓扑意味着领导者-副本设计不存在单点故障或吞吐量瓶颈。（如果您想更熟悉 ScyllaDB 的架构，可以在这里阅读更多内容。）
此外，它与 Cassandra CQL 以及后来的 Amazon DynamoDB 兼容，因此对于熟悉其查询语言和数据模型的人来说已经很熟悉了。
因为它与 Apache Cassandra 兼容，所以它立即继承了已有的生态系统连接器。
Numberly 等用户开发了自己的系统来集成 ScyllaDB 和 Kafka。幸运的是，ScyllaDB 和 Kafka 已经很好地结合在一起了。
我们可以做得更好
虽然这足以让用户启动并运行将 ScyllaDB 与 Apache Kafka 连接起来，但我们知道用户可以真正受益于我们自己的设计和实现所独有的功能。例如，构建我们自己的自定义 Sink 和 Source 连接器。
水槽是两者中较容易的，而且看起来很简单。但即便如此，你也有微妙之处。例如，ScyllaDB 的Kafka Sink Connector远非“普通”。它通过分片感知来利用 ScyllaDB 的每核分片设计，不仅将写入定向到正确的节点，而且定向到与集群中的数据分区关联的正确的 vCPU。这最大限度地减少了跨 CPU 流量，以实现最快的写入效率、降低延迟并最大限度地提高吞吐量。
但是，要成为事件源，需要在 ScyllaDB 上进行一些非常激进的工作，这需要花费相当多的时间。首先是变更数据捕获的实施。我们在 2020 年反复谈论了设计和实施，然后在 2020 年再次谈到了 2021 年CDC的最佳实践，然后在 2021 年我们在 Debezium 上构建了 Kafka 源连接器。总而言之，我们花了整整两年多的时间才真正实现了我们知道客户会满意的 CDC 实施。