Tractian是一家提供工业监控系统的机器智能公司。去年，我们面临着将我们的实时机器学习（ML）环境和分析仪表板升级以支持数据吞吐量的大幅增长的挑战，因为我们成功地将客户数据库和数据量扩大了10倍。

我们意识到，在快节奏的实时机器学习领域保持领先地位，我们需要一个灵活、可扩展且高性能的数据基础设施。我们相信ScyllaDB将为我们提供我们所缺乏的能力，使我们能够将产品和算法推向新的水平。

但你可能想知道为什么ScyllaDB是最佳选择。我们想向你展示我们是如何改变工程流程，专注于改善产品性能的。我们将介绍为什么决定使用ScyllaDB，由此产生的积极结果以及在过渡过程中遇到的障碍。

我们如何比较NoSQL数据库

在讨论数据库时，脑海中会浮现出许多选项。然而，我们首先决定将重点放在具有最大社区和应用的数据库上。这留下了三个直接的选择：两个市场巨头和一个令竞争对手感到惊讶的新进入者。我们研究了这些数据库的四个特征：数据模型、查询语言、分片和复制，并将这些特征作为我们下一步决策的标准。

首先，让我们通过定义的标准更深入地了解这三个数据库：

MongoDB NoSQL

数据模型：MongoDB采用面向文档的数据模型，数据以二进制JSON（BSON）格式存储。集合中的文档可以具有不同的字段和结构，提供了很高的灵活性。面向文档的模型使得几乎可以对任何数据建模或关系建模。
查询语言：MongoDB使用自定义的查询语言MongoDB Query Language（MQL），受SQL的启发，但有一些差异以匹配面向文档的数据模型。MQL支持各种查询操作，包括过滤、分组和聚合。
分片：MongoDB支持分片，即将大型数据库划分为较小的部分，并将这些部分分布在多个服务器上。分片是在集合级别执行的，可以对数据的放置进行精细的控制。MongoDB使用配置服务器存储有关集群的元数据，包括分片键和分片分布的信息。
复制：MongoDB提供自动复制，允许数据在多个服务器之间自动同步，以实现高可用性和灾难恢复。复制是使用复制集进行的，其中一个服务器被指定为主成员，其他服务器被指定为从属成员。在故障的情况下，从属成员可以接管为主成员，实现自动故障恢复。

ScyllaDB NoSQL

数据模型：ScyllaDB采用宽列族数据模型，类似于Apache Cassandra。数据按列和行组织，每列都有自己的值。该模型旨在处理具有高写入和读取性能的大量数据。
查询语言：ScyllaDB使用Cassandra查询语言（CQL），类似于SQL，但有一些差异以匹配宽列族数据模型。CQL支持各种查询操作，包括过滤、分组和聚合。
分片：ScyllaDB使用分片，即将大型数据库划分为较小的部分，并将这些部分分布在多个节点（甚至是个别核心）上。分片是自动执行的，可以随着数据的增长进行无缝扩展。ScyllaDB使用一致性哈希算法将数据分布在节点（和核心）上，确保数据和负载均衡均匀分布。
复制：ScyllaDB提供自动复制，允许数据在多个节点之间自动同步，以实现高可用性和灾难恢复。复制是使用复制数据库集群进行的，每个节点都有数据的副本。可以配置复制因子，以控制存储在集群中的数据副本数量。

PostgreSQL

数据模型：PostgreSQL使用关系数据模型，将数据组织成具有行和列的表。关系模型通过约束和事务提供对数据一致性和完整性的强力支持。
查询语言：PostgreSQL使用结构化查询语言（SQL），这是与关系数据库交互的标准语言。SQL支持广泛的查询操作，包括过滤、分组和聚合。
分片：PostgreSQL不直接支持分片，但可以通过扩展和第三方工具实现。在PostgreSQL中，可以在数据库、表甚至行级别进行分片，以精细控制数据的放置。
复制：PostgreSQL提供同步和异步复制，允许将数据在多个服务器之间进行同步，以实现高可用性和灾难恢复。复制可以使用多种方法进行，包括流复制、逻辑复制和基于文件的复制。

我们对性能的比较结果如下：

在性能方面，ScyllaDB针对高性能和低延迟进行了优化，采用无共享体系结构和多线程技术，提供高吞吐量和低延迟。

MongoDB针对易用性和灵活性进行了优化，提供更易于使用和开发者友好的体验，并拥有庞大的社区来帮助解决未来的问题。

另一方面，PostgreSQL针对数据完整性和一致性进行了优化，强调事务一致性和ACID（原子性、一致性、隔离性、持久性）的合规性。它是需要强大的数据可靠性和安全性的应用程序的常见选择。它还支持各种数据类型和高级功能，如存储过程、触发器和视图。

在选择PostgreSQL、MongoDB和ScyllaDB之间，必须考虑到你的具体用例和需求。如果你需要一个功能强大和可靠的关系型数据库，具有高级数据管理功能，那么PostgreSQL可能是更好的选择。然而，如果你需要一个灵活易用、具有庞大生态系统的NoSQL数据库，那么MongoDB可能是更好的选择。

但是我们正在寻找的是一种高度可扩展和高性能的NoSQL数据库。答案很简单：ScyllaDB更适合我们的用例。

MongoDB vs. ScyllaDB vs. PostgreSQL：性能对比

经过研究过程，我们团队对仅依靠书面信息来做出塑造产品未来的决策持怀疑态度。我们开始深入挖掘，以确保我们的决策在实践中是正确的。

首先，我们建立了一个环境来复制我们的数据采集流程，但我们进行了激进的测试。我们创建了一个脚本来模拟比当前数据流量更大的数据流。当时，我们的吞吐量约为每秒16,000次操作，并且我们以每秒160,000次操作的速度测试了数据库（基本上是10倍）。

为了确保准确性，我们还测试了不同格式和数据结构的写入和读取响应时间；其中一些与我们当时已经使用的类似。

可以在下面看到我们的结果，使用ScyllaDB进行新的最佳配置，并使用MongoDB的配置（我们的旧设置）应用上述测试：

结果令人震惊。在相似的基础设施成本下，我们实现了更好的延迟和容量；决策是明确且经过验证的。我们面临着一项庞大的数据库迁移任务。

从MongoDB迁移到ScyllaDB NoSQL

一旦我们决定开始实施，我们就面临现实世界中的困难。有一些重要的事情需要提及。

在这次迁移中，我们添加了新的信息和格式，这影响了直接或间接使用这些数据的所有生产服务。它们需要通过在流程中添加适配器或重新创建部分处理和操作逻辑来进行重构。

在迁移过程中，由于无法使用停机事件来在旧版本和新版本之间进行交换以验证我们的流程，因此必须对服务和数据库进行复制。这是你在关键的实时系统中必须处理的问题之一：即使在修复或更新系统时，也不能发生停机。

重构过程应该经过数据科学模型，以便它们可以利用新的格式，提高准确性和计算性能。

在这些指导原则的基础上，我们创建了两个团队。一个团队负责管理和维护旧的数据库和架构。另一个团队对我们的数据湖进行了大规模的重处理，并重构了模型和服务以适应新的架构。

从设计结构到最终部署和生产环境切换的整个过程耗时六个月。在此期间，需要进行调整和重大修正。你永远不知道在过程中会学到什么教训。

NoSQL迁移的挑战

ScyllaDB之所以能够实现如此出色的性能，是因为它被设计用于充分利用高端硬件和非常具体的数据建模。最终的结果令人惊讶，但要达到这样的结果需要一些时间。硬件对性能有很大影响。ScyllaDB针对现代多核处理器进行了优化，利用所有可用的CPU核心来处理数据。它使用AVX2（高级向量扩展2）和AES-NI（高级加密标准新指令）等硬件加速技术；它还依赖于存储设备的类型和速度，包括固态硬盘和NVMe（非易失性内存表达）驱动器。

在我们早期的测试中，我们弄乱了一些硬件配置，导致性能下降。当这些问题得到修复后，我们又遇到了另一个问题：数据建模。

ScyllaDB使用Cassandra数据模型，这对查询的性能产生了重大影响。如果你对数据结构、查询或数据量做出了错误的假设，就像我们在开始时做的那样，性能将受到影响。

实际上，在某些情况下，第一个提出的数据格式超过了ScyllaDB分区的推荐最大大小，导致数据库性能不佳。

我们主要的困难在于理解如何将我们旧的数据建模转化为适用于ScyllaDB的建模方式。我们不得不将数据重新组织成多个表和分区，有时还要复制数据以实现更好的性能。