DBLog：一种基于水印的变更数据捕获框架（论文翻译）

摘要

应用程序通常会使用多个异构数据库，每个数据库都用于服务于特定的需求，例如存储数据的规范形式或提供高级搜索功能。因此，对于应用程序而言，将多个数据库保持同步是非常重要的。我们发现了一系列尝试解决此问题的不同方式，例如双写和分布式事务。然而，这些方法在可行性、稳健性和维护性方面存在局限性。最近出现的一种替代方法是利用变更数据捕获（CDC）框架，从数据库的事务日志中捕获变更的行，并以低延迟将它们传递到下游系统。为了解决数据同步的问题，还需要复制数据库的完整状态，而事务日志通常不包含完整的变更历史记录。同时，某些应用场景要求事务日志事件的高可用性，以使数据库尽可能地保持同步。

为了解决上述问题，我们开发了一种用于数据库的新型CDC框架——DBLog。DBLog采用基于水印的方法，可以将直接从表中选择的行与事务日志事件同时处理，以捕获完整状态。我们的解决方案可以在处理选择操作时，让日志事件继续进行而不会陷入停滞。选择操作可以在任何时候对所有表、特定表或表的特定主键进行触发。DBLog将选择操作分成若干个片段，并跟踪它们的进度，允许暂停和恢复操作。基于水印的方法不会使用锁，并对数据源的影响很小。目前，DBLog已经在Netflix的数十个微服务中投入了生产使用。

关键词

数据库、复制、变更数据捕获（CDC）

1. 简介

Netfix在数据层面上每天执行数万亿个操作，使用数百个微服务。由于没有一种单一的数据库设计适用于所有需求，因此每个微服务都可以利用多个异构数据库。例如，一个服务可以使用MySQL、PostgreSQL、Aurora或Cassandra进行管理数据，而使用Elasticsearch进行索引功能。为了能够保持多个数据库同步，我们开发了一种数据增强和同步平台，即Delta [^7]。其中一个关键需求是从源到衍生存储的传播延迟要低，并且事件流高度可用。为了实现这一点，一个关键要求是具有变更数据捕获（CDC），它可以几乎实时地从数据库中捕获更改行，并最终将这些行传播到下游消费者[^11]。CDC在需要保持多个异构数据库同步的用例中越来越受欢迎[^8][^12][^16]，并解决了传统技术（如双写和分布式事务）存在的挑战[^13]。

在数据库系统中，事务日志通常具有有限的保留期限，并且不能保证包含完整的更改历史记录。因此，还需要捕获数据库的完整状态。在Netflix的操作数据同步过程中，我们确定了一些完整状态捕获的需求。首先，我们希望可以随时触发完整状态捕获。这是因为完整状态可能不仅需要在最初时期捕获，而且随后任何时间都可能需要。例如，如果从备份中恢复数据库或进行修复，如果下游数据出现数据丢失或损坏等情况。其次，我们需要能够在任何时候暂停或恢复完整状态捕获，以便在重启过程后不需要重新开始从头捕获大表的完整状态。此外，我们需要在不卡住事务日志事件和完整状态的情况下同时捕获它们，以保证高可用性和最小的复制延迟。另外，我们需要防止时间旅行，通过保留历史事件的顺序来传输到衍生数据存储中，从而避免出现较早版本的数据在后续版本之后被传递的情况。此外，我们需要将其作为平台提供，并最大限度地减少对源数据库的影响。最后，为了跨多种关系数据库管理系统（RDMBS）（例如MySQL、PostgreSQL、Aurora[^19]等）运作，我们需要避免使用特定于供应商的功能。

根据这些需求，我们开发了DBLog。DBLog作为一个进程运行，并使用基于水印的方法，以捕获数据库的完整状态。该方法允许将事务日志事件与我们从表中直接选择的行同时进行，以允许日志事件在执行查询时继续进展，而不会卡住。可以随时触发查询，包括所有表、特定表或特定表的主键。DBLog以块的形式处理查询，并在状态存储（当前使用Zookeeper）中跟踪进度，从而允许查询可以暂停和从上次完成的块继续。此外，该水印方法不使用表锁，对源数据库的影响最小。DBLog使用相同的格式将捕获的事件传递到输出中，无论事件是来自事务日志还是表选择。输出可以是流式数据，如Kafka [^21]，如果有多个事件的消费者，则Kafka是一个常见的选择。但是，DBLog也可以直接将捕获的数据写入数据存储或API。此外，DBLog设计时也考虑到高可用性（HA），采用主动-被动架构，其中一个DBLog进程处于活动状态，而多个被动进程处于待机状态，可以在需要时接管工作。这样，下游消费者就可以放心地在源数据更改后很快收到行数据。图1展示了DBLog的高层架构。

image-20230402134526062

2. 相关解决方案对比

我们评估了一系列现有的解决方案，例如：Databus [^8]、Debezium [^10]、Maxwell [^22]、MySQLStreamer [^15]、SpinalTap [^6]和Wormhole [^16]。现有解决方案在从事务日志中捕获事件方面相似，并利用与MySQL的binlog复制协议或PostgreSQL的复制插槽相同的底层协议和API。捕获的事件被序列化为专有的事件格式并发送到通常为Kafka的输出。像SpinalTap和Wormhole这样的解决方案仅提供日志处理，没有内置捕获数据库完整状态的功能，在这种情况下，需要通过外部处理方式捕获完整状态。已经存在的解决方案具有内置捕获完整状态的能力。由于事务日志通常具有有限的保留期限，因此不能用于重建完整的源数据集。现有的解决方案以不同的方式处理这个问题，并具有不同的权衡：

Databus [^8]具有一个引导服务，它从源中读取事务日志事件并将它们存储在一个单独的数据库中。下游消费者可以访问引导服务，如果它们需要初始化或进行修复。引导完成后，消费者开始处理来自引导之前时间的日志事件，以便有重叠，没有事件被遗漏。从日志中追赶可能会导致时间旅行，因为来自引导的行状态可能具有更近期的行状态，并且在此之后从日志中捕获了较旧的状态。最终，最新的状态将从事务日志中被发现。

Debezium [^10]通过使用表锁和在一个事务中跨所有表运行select来为MySQL和PostgreSQL捕获一致的快照。在选择了所有现有行之后，从事务日志中捕获来自事务的事件。根据实现和数据库，此锁定的持续时间可能很短，也可能在整个选择过程中持续，例如MySQL RDS [^10]。在后一种情况下，写流量会被阻塞，直到所有行都被选择，这对于大型数据库可能需要很长时间。

在Maxwell [^22]中，通过暂停事务日志处理来执行转储，然后从所需的表中选择行。之后，日志事件处理继续。这种方法容易出现时间旅行，其中select可能会返回一个行的更近期值，然后之后从日志中捕获一个较旧的值。最终，最新的状态将从日志中被消费。

MySQLStreamer [^15]在源上创建每个表的副本，即一个复制表。然后，从原始表中选择行并将它们分块插入到复制表中，从而生成插入的事务日志条目。复制表使用MySQL黑洞引擎创建，以便插入不占用表空间，同时仍然生成事务日志事件。使用锁定确保不违反历史顺序。然后，MySQLStreamer服务从事务日志中消费事件，并能够检测到来自复制表的事件，将其标记为原始表的事件。这样，下游消费者可以接收每个表的事件，这些事件要么来自实际应用程序更改，要么来自复制表。

表格1记录了我们在第1节中列举的捕获完整状态的要求，并在现有方案之间进行了比较。我们发现没有现有方法可以满足所有要求。一些限制是由设计隐含的，例如首先尝试选择一致的快照，然后捕获日志事件。选择特定供应商的功能（例如MySQL黑洞引擎）是另一个观察到的问题，禁止跨数据库重用代码。一些解决方案还使用表锁，这可能会短时间或长时间阻塞应用程序写入流量。基于这些观察结果，我们决定实现一种新的处理转储的方法，以满足我们所有的要求。

image-20230402135023671

3. DBLOG

DBLog是一个基于Java的框架，能够从数据库的事务日志中捕获更改的行，也能通过对表执行选择来捕获数据库的完整状态。DBLog会将选择操作分成块，并与日志事件交错处理，避免了日志事件处理过程中的长时间等待。DBLog采用了一种基于水印的方法来实现这一点。用户可以通过API在运行时执行选择操作。这使得用户可以在任何时候启动DBLog的输出，并从中获取完整状态数据，例如数据库的备份、修复操作等。如果输出是启用了日志压实功能的Kafka，那么用户可以通过读取Kafka中包含完整数据集的事件来初始化DBLog的输出，并通过不断追加来自源的更改行来保持更新。对于只有一个消费者的情况，DBLog还可以将事件直接发送到数据存储或API。

我们设计了这个框架，使其对数据库的影响最小化。查询可以在需要时暂停和恢复。这对于失败恢复和在数据库达到瓶颈时停止处理都是相关的。我们还避免在表上使用锁定，以避免阻塞应用程序的写入。我们使用Zookeeper [^1] 存储与日志事件处理和块选择相关的进度。我们还使用Zookeeper进行领导者选举，以确定活动进程，而其他进程则作为被动待机。我们选择Zookeeper是因为它的成熟度、读写低延迟、支持必要时进行可线性读取[^20]、并且如果有一组可达节点，则可用于写入。我们构建DBLog时考虑了可插拔性，允许按需替换实现，例如将Zookeeper替换为其他数据存储。

以下各小节详细解释了交易日志捕获和完整状态捕获。

3.1 事务日志捕获

DBLog的事务日志捕获机制要求数据库在提交顺序上为每个更改行生成一个事件。在MySQL和PostgreSQL中，存在一个复制协议，通过TCP套接字将事件在提交时间后不久传递给DBLog。一个事件可以是创建、更新或删除类型。对于我们的用例，我们假设一个事件包含操作发生时的所有列值。尽管如此，如果只需要捕获一部分列，DBLog也可以使用。对于每个事件，我们假设有一个日志序列号（LSN），它是事务日志上该事件的偏移量，并以8字节单调递增的数字进行编码。

每个事件都被序列化为DBLog事件格式，并追加到输出缓冲区中，该缓冲区是DBLog进程的一部分并保存在内存中。另一个线程从输出缓冲区中消费事件并按顺序将它们发送到实际的输出目标中。输出接口非常简单，允许插入任何目标，例如流、数据存储或通常具有API的任何类型的服务。

我们还捕获模式更改。不同的数据库捕获模式更改的方式有所不同，因此日志中可能存在模式更改增量，或者数据库在每个发出的事件中包含模式信息。在DBLog中处理模式捕获的方法由于篇幅限制在本文中未详细介绍。

3.2 完整状态捕获

由于事务日志通常具有有限的保留期限，因此不能用它们来重构完整的源数据集。尝试解决这个问题时，两个主要的挑战是确保日志处理不会停滞，并且保留历史顺序。解决这个问题的一种现有解决方案是在源数据库中创建每个表的副本，并按块填充它，以便复制的行以正确的顺序出现在事务日志中。然后可以消费事务日志事件并接收所有行的最新状态以及已更改的行。然而，这种解决方案会在源处消耗写入I/O，并需要额外的磁盘空间。可以使用特定于供应商的功能来防止占用额外的表空间，例如MySQL黑洞引擎。

我们开发了一种解决该问题的方法，该方法仅使用常见的数据库特性，并尽可能少地影响源数据库。我们选择从表中分块地选择行，并将这些块的位置存储在内存中，与我们从事务日志中捕获的事件相邻。这样做的方式可以保留日志事件的历史记录。

我们的解决方案允许通过 API 在任何时候提取所有表、特定表或特定主键的表的全状态。选择语句是针对每个表和每个配置大小的块执行的。块通过按升序排序表并包含主键大于上一个块的最后一个主键的行来选择。为了最小化对源数据库的影响，必须使此查询高效地运行。因此，DBLog 要求数据库提供一个高效的主键范围扫描，并且我们只允许在具有主键的表上进行选择。图2用一个简单的例子说明了块选择的过程。

image-20230402135845555

DBLog使用水印（watermark）来保证全量数据采集的顺序和完整性，从而避免选择一个旧的数据来覆盖更新的数据。为此，DBLog创建了一个专用于水印的表，将其存储在数据库的一个专用命名空间中，以避免与应用表发生冲突。该表只有一行数据，用于存储通用唯一标识符(UUID)值。每次更新这个行的UUID值时，就会产生一条变更事件，这个事件最终会被DBLog捕获并作为水印来标记数据的采集顺序。每次执行一批数据行的采集操作后，DBLog会将最后一行数据的主键值存储在Zookeeper中，以便后续可以在该点暂停或恢复操作。

算法1描述了基于水印的方法来选择下一个特定表的块。只要该表还有剩余的块，就会重复执行该算法。首先，暂停日志事件处理（步骤1）。通过更新水印表来生成水印（步骤2和4）。块选择发生在两个水印之间，并且块存储在内存中（步骤3）。在写入高水印后，我们恢复日志事件处理，将接收到的日志事件发送到输出，并在日志中等待低水印事件。一旦接收到低水印事件，我们开始删除在水印之间发生变化的所有主键的内存中的块行（步骤6）。一旦接收到高水印事件，我们最终将所有剩余的块条目追加到输出缓冲区中，然后再以顺序方式处理日志事件（步骤7）。

image-20230402140112385

我们在步骤3中进行的块选择需要返回代表特定历史时刻已提交更改的状态。换句话说，该选择在事务日志的特定位置上执行，考虑到那一点上提交的事务。数据库通常不会公开 select 在事务日志上的执行位置（MariaDB 是一个例外[^9]）。我们方法的核心思想是确定一个包含块选择的事务日志窗口。该窗口是通过编写低水印打开的，然后执行选择，然后通过编写高水印关闭。由于选择的确切位置是未知的，因此必须删除所有在该窗口内与日志事件发生碰撞的选择的块行。这确保了块选择不会覆盖日志更改的历史记录。为使其正常工作，我们必须从低水印写入时或之后的时间读取表状态（包括在低水印写入后提交但在读取之前提交的更改）。更一般地说，要求块选择看到在其执行之前提交的更改。我们将这种能力定义为“非陈旧读取”。另外，由于高水印是后面写入的，我们要求选择在其之前执行。

图3a和3b说明了水印算法的块选择过程。我们提供了一个具有主键k1到k6的表的示例。每个更改日志条目代表主键的创建、更新或删除事件。图中的步骤对应于算法1中的标签。在图3a中，我们展示了水印生成和块选择的过程（步骤1到4）。在步骤2和4中更新水印表会创建两个更改事件（用粗体突出显示），这些事件最终通过更改日志接收到。在图3b中，我们重点介绍了从结果集中删除的选定块行，这些行对于在水印之间出现的主键进行了排除（步骤5到7）。

image-20230402140401763

需要注意的是，在低水位标记和高水位标记之间可能会出现大量的日志事件，如果一些事务在它们之间提交了大量的行更改。在第4步之后，日志事件的处理会逐个进行，最终发现水位标记，而不需要缓存日志事件条目。步骤2-4预计是快速的：水位标记更新是单个写操作，并且块选择在具有限制的主键索引上运行。一旦在第7步收到了高水位标记，非冲突的块行按顺序附加到输出缓冲区中，并最终传递到输出。将块行附加到输出缓冲区是一个非阻塞操作，因为输出传递在单独的线程中运行，允许在第7步之后恢复常规日志处理。

图4以与图3a和3b相同的示例来说明事件写入输出的顺序。首先添加低水印之前的日志事件，然后添加选择的块中剩余的行（下划线条目），最后是高水印之后的日志事件。这说明了日志和完整数据提取事件的交错。

image-20230402140822708

3.3 数据库支持

为了使用DBLog，数据库需要按照提交顺序从线性历史记录中发出更改行，并支持非陈旧读取。这些条件被MySQL、PostgreSQL、MariaDB等系统所满足，因此该框架可以在这些数据库之间进行统一使用。

到目前为止，DBLog已经支持MySQL、PostgreSQL和Aurora数据库。在所有这些数据库中，日志事件都按提交顺序提供[^2] [^4]，通过read committed隔离级别可以实现非陈旧读取[^3][^5]。对于MySQL，我们使用MySQL二进制日志连接器[^17]来集成日志事件。对于PostgreSQL，我们使用具有wal2json插件的复制插槽[^18]。更改是通过PostgreSQL Java Database Connectivity（JDBC）驱动程序实现的流复制协议接收的。在MySQL中，确定每个捕获更改的模式会有所不同。在PostgreSQL中，wal2json包含列名和类型以及列值。在MySQL中，模式更改增量作为binlog事件接收。

全状态捕获是通过使用 SQL 和 JDBC 进行集成的，只需要实现块选择和水印更新即可。相同的代码用于 MySQL 和 PostgreSQL，并且也可用于其他支持 JDBC 的数据库。转储处理本身不依赖于 SQL 或 JDBC，并且允许集成满足 DBLog 框架要求的数据库，即使它们不是关系型数据库。

4. DBLOG生产实践

DBLog 是 Netflix 公司 MySQL 和 PostgreSQL 连接器的基础。这两个连接器用于我们的数据同步和增强平台 Delta [^7]。DBLog 自 2018 年以来一直在生产环境中运行，截至本文写作之时，已在 Netflix 的约 30 个生产服务中部署。这些用例涵盖了异构数据复制、数据库活动日志记录和模式迁移等领域。

「异构数据复制」：为了跟踪作品，搜索与电影相关的所有数据至关重要。这涉及由不同团队管理的数据，每个团队都拥有不同的业务实体，例如剧集、人才和合约。这些服务使用MySQL或PostgreSQL在AWS RDS中存储其数据。DBLog部署到每个涉及的数据存储中，捕获完整数据集和实时更改到输出流中。然后将流连接并摄入到ElasticSearch中的通用搜索索引中，提供跨所有涉及实体的搜索。

「数据库活动日志记录」：DBLog 还用于记录数据库活动，以便可以查看数据库发生了什么样的变化。在这种情况下，捕获更改的行并将其传递到一个流中。然后，流处理器会将事件传播到 ElasticSearch（用于短期存储）和 Hive（用于长期存储）。在 ElasticSearch 中使用 Kibana 构建活动仪表板，以便团队可以检查每个表上发生的操作数量。这用于检查数据变异模式，可以关键地检测到出现了意外模式，例如在新的服务代码出现错误后，从表中删除插入操作。

「模式迁移」：当一个团队正在将一个 MySQL 数据库迁移到另一个数据库并且第二个数据库使用了新的表结构时，需要在旧数据库上部署 DBLog 来捕获完整状态以及新的更改，并将它们写入流。然后，一个 Flink 作业消费这些数据，将它们转换为新的表结构格式，并将它们写入新数据库。这样，新数据库的读取可以在已填充的新模式上进行验证，而写入仍然发生在旧模式中。在随后的步骤中，写入流量也可以发生在新模式中，而旧数据库上的流量可以停止。

5. 结论

本文介绍了一种基于水印的CDC框架DBLog。DBLog不仅可以从数据库事务日志中实时提取更改行，还可以作为集成式产品提取数据库的全部状态。此外，DBLog提供端点让用户随时请求并执行全状态，而不会阻塞日志事件处理。通过分块执行表上的选择操作并将获取的行与日志事件交错，从而实现这一点，以使两者均能进展。同时，由于基于水印的方法，始终保留原始历史记录的顺序，而无需在源数据库上使用锁。此外，还设置了控件，允许节流分块选择或在需要时暂停和恢复。当在非常大的表上捕获全部状态并且过程崩溃时，这特别重要，因此无需从头开始重复该过程。DBLog旨在将事件传递到任何输出，无论是数据库、流还是API。这些功能在同步多个数据系统方面开辟了新途径。

由于 Netflix 运营着数百个具有独立数据需求的微服务，DBLog 已成为 Netflix 数据同步和增强平台的基础。它消除了应用程序开发人员在维护多个数据存储方面的复杂性。DBLog 及其基于水印的方法旨在适用于 RDBMS 数据库。下一步，我们正在开发其他 CDC 框架，以支持不属于 DBLog 框架的数据库，例如 Apache Cassandra 等多主 NoSQL 数据库。目标是支持与 DBLog 类似的功能，即：随时捕获完整状态，与日志事件交错，并对源的影响最小。

参考

[^1]: 2010. Apache Zookeeper. https://zookeeper.apache.org/

[^2]: 2020. MySQL 5.7 Reference Manual - 5.4.4 The Binary Log. https://dev.mysql.com/doc/refman/5.7/en/binary-log.html.

[^3]: 2020. MySQL 5.7 Reference Manual - Consistent Nonlocking Reads. https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html.

[^4]: 2020. PostgreSQL 9.6 Documentation - Logical Decoding Output Plugins. https://www.postgresql.org/docs/9.6/logicaldecoding-output-plugin.html.

[^5]: 2020. PostgreSQL 9.6 Documentation - Transaction Isolation. https://www.postgresql.org/docs/9.6/transaction-iso.html#XACT-READ-COMMITTED.

[^6]: Airbnb. 2018. Change Data Capture (CDC) service. https://github.com/airbnb/SpinalTap.

[^7]: Andreas Andreakis, Falguni Jhaveri, Ioannis Papapanagiotou, Mark Cho, Poorna Reddy, and Tongliang Liu. 2019. Delta: A Data Synchronization and Enrichment Platform. https://netflixtechblog.com/delta-a-data-synchronization-andenrichment-platform-e82c36a79aee.

[^8]: Shirshanka Das, Chavdar Botev, Kapil Surlaker, Bhaskar Ghosh, Balaji Varadarajan, Sunil Nagaraj, David Zhang, Lei Gao, Jemiah Westerman, Phanindra Ganti, Boris Shkolnik, Sajid Topiwala, Alexander Pachev, Naveen Somasundaram, and Subbu Subramaniam. 2012. All aboard the Databus!: Linkedin’s scalable consistent change data capture platform.. In SoCC, Michael J. Carey and Steven Hand (Eds.). ACM, 18. http://dblp.uni-trier.de/db/conf/cloud/socc2012.html#DasBSGVNZGWGSTPSS12

[^9]: Maria DB. 2020. Enhancements for START TRANSACTION WITH CONSISTENT SNAPSHOT. https://mariadb.com/kb/en/enhancements-for-start-transactionwith-consistent-snapshot

[^10]: Debezium documentation. 2020. Debezium Connector for MySQL. Snapshots section. https://debezium.io/documentation/reference/1.2/connectors/mysql.html#how-the-mysql-connector-performs-database-snapshots_debezium.

[^11]: Martin Kleppmann. 2017. Designing Data-Intensive Applications. O’Reilly, Beijing. https://www.safaribooksonline.com/library/view/designing-dataintensive-applications/9781491903063/

[^12]: Martin Kleppmann, Alastair R. Beresford, and Boerge Svingen. 2019. Online event processing. Commun. ACM 62, 5 (2019), 43–49. https://doi.org/10.1145/3312527

[^13]: Kleppmann, Martin. 2015. Using logs to build a solid data infrastructure (or: why dual writes are a bad idea). https://www.confluent.io/blog/using-logs-to-builda-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea.

[^14]: Avinash Lakshman and Prashant Malik. 2010. Cassandra: a decentralized structured storage system. ACM SIGOPS Operating Systems Review 44, 2 (2010), 35–40.

[^15]: Prem Santosh Udaya Shankar. 2016. Streaming MySQL tables in real-time to Kafka. https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-inreal-time-to-kafka.html.

[^16]: Yogeshwer Sharma, Philippe Ajoux, Petchean Ang, David Callies, Abhishek Choudhary, Laurent Demailly, Thomas Fersch, Liat Atsmon Guz, Andrzej Kotulski, Sachin Kulkarni, Sanjeev Kumar, Harry Li, Jun Li, Evgeniy Makeev, Kowshik Prakasam, Robbert Van Renesse, Sabyasachi Roy, Pratyush Seth, Yee Jiun Song, Benjamin Wester, Kaushik Veeraraghavan, and Peter Xie. 2015. Wormhole: Reliable Pub-Sub to Support Geo-replicated Internet Services. In 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15). USENIX Association, Oakland, CA, 351–366. https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/sharma

[^17]: Stanley Shyiko. 2010. MySQL Binary Log Connector. https://github.com/shyiko/mysql-binlog-connector-java.

[^18]: Euler Taveira. 2014. wal2json - JSON output plugin for changeset extraction. https://github.com/eulerto/wal2json.

[^19]: Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, and Xiaofeng Bao. 2017. Amazon aurora: Design considerations for high throughput cloud-native relational databases. In Proceedings of the 2017 ACM International Conference on Management of Data. 1041–1052.

[^20]: Paolo Viotti and Marko Vukoliundefined. 2016. Consistency in Non-Transactional Distributed Storage Systems. ACM Comput. Surv. 49, 1, Article 19 (June 2016), 34 pages. https://doi.org/10.1145/2926965

[^21]: Guozhang Wang, Joel Koshy, Sriram Subramanian, Kartik Paramasivam, Mammad Zadeh, Neha Narkhede, Jun Rao, Jay Kreps, and Joe Stein. 2015. Building a Replicated Logging System with Apache Kafka. Proc. VLDB Endow. 8, 12 (Aug. 2015), 1654–1655. https://doi.org/10.14778/2824032.2824063

[^22]: Zendesk. 2014. Maxwell’s daemon, a MySQL-to-JSON Kafka producer. https://github.com/zendesk/maxwell