在今年早些时候的一篇文章中，我谈到了分布式数据库的一般比较。在为您的用例选择合适的数据库时，所有这些考虑因素都很重要。然而，今天让我们关注功能的一个特定方面：数据库是否非常适合事件流架构。
从面向批处理的处理到事件流架构的过渡是下一个技术周期发生根本性变化的核心。Kafka最初于2011年发布，与早期的NoSQL数据库处于同一时代。Pulsar稍晚，于2013年由Yahoo发明。许多数据库架构早在事件流媒体革命之前就已经存在，其基本设计决策可能是与事件流媒体一起使用的反模式。
数据库是为特定类型的数据、特定类型的工作负载和特定类型的查询而设计的。数据库在设计和实现过程中可能与您所期望的实用程序保持多大的一致性或与您的特定用例的距离决定了系统的阻力。因此，您可以使用各种数据库来完成从未设计过的任务，但您应该这样做吗？
对于适合事件流的数据库，它需要支持“实时”管理随时间变化的数据更改，以一位数毫秒或更少的时间度量。
数据更改的速度可以达到每秒数十万或数百万个事件。（未来利率甚至会更高。）
在查看数据库是否适合其事件流用例时，组织需要考虑四个主要轴：
-
本地云
-
内在品质
-
事件驱动设计
-
最适合用例
让我们更详细地了解一下其中的每一项。
本地云
今年早些时候，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不会很快消失-高可用性系统通常更适合事件驱动架构，具有高度异步性，并针对实时响应进行了优化。
如果适用于现代云原生环境，可服务性还包括其他基本特性，如可观察性、可管理性、可用性、便利性等。你的数据库设计得让你知道它在做什么吗？相反，如果它表现不正常，你能告诉它该怎么办吗？可用性是采用的关键因素。现代分布式数据库并不“容易”。它们需要数据和查询建模、操作和管理方面的专业知识。但你的系统是不是不必要的不透明和迟钝？如果是这样，那么您可能会发现您的团队不愿意学习与当前知识或行为完全正交的东西，如果不是完全积极反对采用的话。
对我来说，“设施”不仅仅是“可用的”。它会问，“它易于使用和管理吗？”经营它是一种乐趣，还是让组织像不断遭受低烧的毒气一样痛苦？
年度堆栈溢出调查就是一个例证，该调查询问了成千上万的开发人员他们最喜欢和最害怕的数据库是什么。那些觉得目前的选择是一件可怕的杂务的开发人员将寻找一些东西，任何东西，以减轻他们的痛苦。那些喜欢自己工作的人不太可能转向新技术，或者放弃他们认为落后于时代的组织。喜欢他们部署的技术的用户不必过多考虑。数据库变得“看不见”，使他们能够专注于他们试图解决的技术问题。
性能也是这一关键因素的关键部分。让我们从事件驱动架构的阻抗匹配的具体方面来详细了解这一点。
事件驱动
现在，让我们关注一下数据库是否真的是为事件驱动架构设计的。它的特性和功能真的有助于您从面向批处理的世界发展到实时流媒体现实吗？
这有两个方面：汇（消费者）和源（生产者）。
作为消费者（接收器）似乎很简单—只是数据摄取，但其中有许多微妙之处。系统如何处理时间序列数据？它是如何对这些数据进行分区并在系统内分发的？所有的写操作都会转移到一个随着吞吐量而融化的热碎片上吗？其他碎片是否持有本质上“只写一次，很少读”的“陈旧”数据（在只允许一个节点作为可写入的先导节点的主副本系统上，这可能会特别成问题；其他所有节点都是只读副本。）
作为生产者（源代码），还有更多必要的基础设施工作，例如支持变更数据捕获（CDC），以便将对数据库的更改发布到主题。CDC的实施可以有很大的差异，其中一些是经过精心设计和设计的；高效和全面。然而，其他的可能是事后考虑或事后补强，会对性能产生重大影响，并且在实施过程中会出现失误。当您在支持的特性列表中看到“CDC”一词时，您确实想双击它，因为没有两个数据库供应商的实现是相同的。
此外，虽然这很微妙，但重要的是要注意，要真正成为一个“事件源”解决方案，数据库需要记录所有数据状态，一个事件接一个事件。因此，您可能需要保留数据记录的前值和后值；不仅仅是差异。另外，您的用例将决定这些记录需要保留多长时间。
事件流中的阻抗匹配对于保持组织数据的“最新”流动而无阻力或信号丢失非常重要
要真正与您的事件流系统配对，您正在使用的数据库和您正在实现的事件流体系结构都需要具有“阻抗匹配”。如果数据库太轻或太慢，无法跟上您事件流的数量，它将很快变得超负荷和不可用。相反，如果您的事件流无法跟上运营事务数据库的更新速度，您可能会发现您的企业的其余部分无法与您的真实来源中发生的最新变化保持同步。
最适合用例
仅仅因为你熟悉一个特定的数据库并不意味着它最适合这份工作。也许你熟悉SQL。但是，这个用例的数据结构、高可用性和吞吐量是否要求您考虑使用NoSQL数据库？您熟悉NoSQL吗？但实际上，对于这个高度一致的用例，您需要表和联接以及第三个规范化表单？这听起来像是SQL的一项工作。
在这里，用户应该考虑他们正在设计什么样的应用程序。他们有什么样的吞吐量和延迟要求。数据集缩放（GB？TB？PB？），总体和随时间增长。
然后，他们应该研究所需的数据模型和数据查询语言，以最高效、最容易地获得他们所寻找的数据结果。这是一个读写繁重的工作负载，还是混合读写？是事务更新，还是分析范围扫描或全表扫描？数据处理必须以多快的速度进行？结果需要在亚毫秒、毫秒、秒甚至分钟+范围内吗？
速度也可以用吞吐量来衡量。您每秒有数百个查询，还是数千个或一百万个以上？吞吐量本身可以被视为每秒的操作数或事务数，也可以根据总容量或有效负载进行查看。因为全表扫描的结果集将与单个对象或行结果查询有很大不同。
最后，也是所有人最关心的问题，组织愿意为此解决方案承担的价格/成本是多少？它有什么样的TCO或ROI目标？因为出于表演目的，听起来很可爱的东西可能会让你在每月账单到期时脸色发白。
例如，DBaaS选项似乎比开源更昂贵（“它是免费的，对吗？”），但从长远来看，商业服务可能具有实际上可以为您的组织节省更多运营或管理开销的功能。
考虑到所有这些因素，您现在有了一个通用的量规，可以根据它为您的用例的选项列表打分。
NoSQL数据库的事件流之旅：ScyllaDB
因此，让我们看看这个量规是如何“评分”ScyllaDB的，在我们自己寻求成为您的活动流架构的最佳数据库的过程中。这并不是说我们是衡量所有其他数据库的完美典范。我在评估时会尽量做到公平和坦率。如果您使用的是不同的数据库，只需考虑一下您自己的技术选择是如何组合起来的。
首先，让我们看看 ScyllaDB是从哪里开始走向事件流媒体的。2015年，ScyllaDB的工作正式开始，进入了活动流媒体时代。其创始人认识kafka和Pulsar，早在 ScyllaDB（和Confluent）的历史上，博客就谈到了连接kafka与 ScyllaDB的优点。
原因很简单：“ScyllaDB”是建立在“好骨头”之上的。kafka是一个高度可伸缩、性能优良的事件流架构，而 ScyllaDB是一个具有高度可伸缩性、性能优良、NoSQL数据库。
ScyllaDB的设计目的是以每秒数百万次操作的速度获得单位数P99延迟。它不仅可以扩展到任意数量的服务器，而且由于其基于Seastar框架，还可以扩展到每台服务器的任何核心数量。
其对等主动主动拓扑意味着领先副本设计不存在单点故障或吞吐量瓶颈。 ScyllaDB从一开始就具有高可用性、拓扑感知和多数据中心设计。
最重要的是，它与Cassandra CQL以及后来的Amazon DynamoDB兼容，因此对于熟悉其查询语言和数据模型的人来说，它已经很舒服了。
因为它与Apache Cassandra兼容，所以它立即继承了现有的生态系统连接器。
我们的客户，例如Numberly，开发了自己的系统来集成ScyllaDB和Kafka。幸运的是， ScyllaDB和kafka已经合作得很好。
我们可以做得更好
虽然这足以让用户启动并运行 ScyllaDB与Apache Kafka的连接，但我们知道，用户将真正受益于我们自己设计和实现的独特功能。例如，构建我们自己的自定义接收器和源连接器。
水槽是两个中比较容易的，而且看起来很简单。但即便如此，你也有微妙之处。例如，ScyllaDB的Kafka Sink Connector远非“普通”连接器。它利用了ScyllaDB’s shard per core设计，具有碎片感知能力，不仅将写入定向到正确的节点，而且定向到与群集中数据分区关联的正确vCPU。这将跨CPU通信量降至最低，从而实现最快的写入效率，降低延迟并最大限度地提高吞吐量。它还具有其他功能，例如在向数据库中写入主题时，可以管理 ScyllaDB中的模式，甚至可以对正在写入的数据设置生存时间（TTL）。
然而，要成为一个事件源，需要对 ScyllaDB进行一些相当激进的工作，这需要花费相当长的时间。首先是变更数据捕获的实现。我们在2020年反复谈到了设计和实施，后来又在2020年，然后在2021 CDC的最佳实践上，当它正式上市，然后在2021，我们在Debezium上构建了kafka源连接器。总而言之，我们花了两年多的工程时间才真正实现了客户满意的CDC实施。
ScyllaDB的活动流媒体之旅——从kafka开始
到2021年底，由于信源连接器和信源连接器以及CDC接口完全稳定且性能良好，系统之间的集成是双向的，并且是完整的。
这解决了开源Apache Kafka和企业Confluent Kafka的问题，但这并不是事件流媒体世界的唯一选择。幸运的是，Redpanda与Kafka兼容，因此它立即继承了与现有连接器的兼容性。
ScyllaDB的事件流媒体之旅-与Pulsar合作
Apache Pulsar怎么样？还是商业化的Pulsar，如StreamNative平台？幸运的是，现成的Pulsar配备了Cassandra Sink Connector接收器连接器。虽然这不像Kafka那样是一个碎片感知接收器连接器。使用Pulsar Producer，您可以对其进行包装或调整，以接收来自Kafka主题的数据。然而，无可否认，Pulsar包装器是一种“需要一些组装”的解决方案。
因此，未来的潜在发展包括本地Pulsar碎片感知消费者和本地CDC Pulsar生产者。
总结
读者可以使用本文提出的想法来比较现有或建议的数据库对他们自己的事件流架构的适用性。
事件流是一种趋势，这一趋势是显而易见的，而且还在不断发展，目前许多用户将事件流与大型企业级数据库并行部署。这对于ScyllaDB的用户来说尤其如此，比如Numberly、Grab、Nauto、Amdocs等等。
ScyllaDB是与事件流媒体革命同时创建的，并随着其发展和成熟。ScyllaDB具有强大、高效的“变更数据捕获”实现，使用户可以灵活地使用ScyllaDB中的数据。它与Apache Kafka的集成包括高性能和高级的接收器和源连接器。然而，尽管ScyllaDB与Apache Pulsar的Apache Cassandra连接器兼容，但ScyllaDB缺少本机连接器，这仍然是未来实现更高性能和更易于部署的考虑因素。
您如何在组织中使用事件流？
如果你是一个自学成才的人，请随意阅读关于如何集成Kafka的文档，或者在ScyllaDB大学免费学习Kafka和变化数据捕获课程。或者如果Pulsar的速度比你快，请查看连接Cassandra和Pulsar教程。它对ScyllaDB也应该起同样的作用。
我们很想了解您是如何与ScyllaDB一起在您的组织中实施活动流的，或者了解您在开始时的问题。有两种方式可以与我们联系。您可以通过我们的在线表单或聊天功能私下联系我们，也可以加入我们Slack社区中的数据库怪兽伙伴。
原文标题：Distributed Database Design Decisions to Support High Performance Event Streaming
原文作者：Peter Corless
原文链接：https://www.scylladb.com/2022/09/21/distributed-database-design-decisions-to-support-high-performance-event-streaming/
