工控系统如何为其实时机器学习环境选择最佳数据库？
当谈论数据库时，人们会想到很多选项。然而，我们首先决定关注那些拥有最大社区和应用程序的人。这就留下了三个直接选择：两个市场巨头和一个令竞争对手感到惊讶的新来者。我们研究了这些数据库的四个特征——数据模型、查询语言、分片和复制——并将这些特征用作我们下一步的决策标准。
首先，让我们使用定义的标准让您更深入地了解这三个数据库：
MongoDB NoSQL
- 数据模型： MongoDB 使用面向文档的数据模型，其中数据以 BSON（二进制 JSON）格式存储。集合中的文档可以具有不同的字段和结构，从而提供高度的灵活性。面向文档的模型基本上支持任何数据建模或关系建模。
- 查询语言： MongoDB 使用名为 MongoDB 查询语言 (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、ScyllaDB 与 PostgreSQL：性能比较
研究过程结束后，我们的团队对仅使用书面信息来做出影响我们产品未来的决定表示怀疑。我们开始深入研究，以确保我们的决定切实可行。
首先，我们构建了一个环境来复制我们的数据采集管道，但我们做得非常积极。我们创建了一个脚本来模拟比当前数据流更大的数据流。当时，我们的吞吐量约为每秒 16,000 次操作，并且我们以每秒 160,000 次操作（所以基本上是 10 倍）测试数据库。
当然，我们还测试了不同格式和数据结构的写入和读取响应时间；有些与我们当时已经使用的相似。
您可以在下面看到我们的结果，其中使用 ScyllaDB 进行了新的最佳配置，并使用我们使用 MongoDB（我们的旧设置）进行的配置应用了上述测试：
ScyllaDB延迟是30-40之间，而MongoDB是600-700之间，
延迟是越低越好。
在相似的基础设施成本下，ScyllaDB实现了更好的延迟和容量；该决定是明确且有效的。我们面临着大规模的数据库迁移。
从 MongoDB 迁移到 ScyllaDB NoSQL
当我们决定开始实施时，我们就面临着现实的困难。有些事情值得一提。
在此迁移中，我们添加了新的信息和格式，这影响了直接或间接使用这些数据的所有生产服务。必须通过在管道中添加适配器或重新创建部分处理和操作逻辑来重构它们。
在迁移过程中，服务和数据库都必须复制，因为不可能使用中断事件在新旧版本之间交换来验证我们的管道。这是关键实时系统中必须处理的问题的一部分：即使您正在修复或更新系统，也绝不允许中断。
重建过程应该经过数据科学模型，以便它们可以利用新格式，提高准确性和计算性能。
根据这些指导方针，我们创建了两个小组。其中一名负责管理和维护旧的数据库和架构。另一组对我们的数据湖进行了大规模的重新处理，并重构了模型和服务以处理新的架构。
从设计结构到最终部署和更换生产环境的完整过程花了六个月的时间。在此期间，需要进行调整和重大修正。你永远不知道一路上你会学到什么教训。
NoSQL 迁移挑战
ScyllaDB 能够实现这种性能，因为它旨在利用高端硬件和非常具体的数据建模。最终的结果令人惊讶，但实现这些结果需要一些时间。硬件对性能有重大影响。ScyllaDB 针对现代多核处理器进行了优化，并使用所有可用的 CPU 核心来处理数据。采用AVX2（高级矢量扩展2）、AES-NI（高级加密标准新指令）等硬件加速技术；它还取决于存储设备的类型和速度，包括固态磁盘和 NVMe（非易失性内存 Express）驱动器。
在我们的早期测试中，我们搞乱了一些硬件配置，导致性能下降。当这些问题得到解决后，我们偶然发现了另一个问题：数据建模。
ScyllaDB 使用 Cassandra 数据模型，该模型在很大程度上决定了查询的性能。如果您对数据结构、查询或数据量做出错误的假设，就像我们一开始所做的那样，性能将会受到影响。
实际上，在某些情况下，第一个提出的数据格式最终超出了 ScyllaDB 分区建议的最大大小，这导致数据库性能不佳。
我们的主要困难是理解如何将旧的数据模型转换为可以在 ScyllaDB 上执行的模型。我们必须将数据重组为多个表和分区，有时需要复制数据以获得更好的性能。
经验教训：NoSQL 数据库的比较和迁移
简而言之，我们在这个过程中吸取了三个教训：一些来自我们的成功，另一些来自我们的错误。
在对数据库进行研究和基准测试时，我们发现不同数据库中存在的许多规范和功能都有特定的应用程序。您的具体用例将决定最适合您的应用程序的数据库。而这一事实只有通过在压力情况下对生产环境进行实际测试和模拟才能发现。我们投入了大量的时间，并且我们选择使用最合适的数据库得到了回报。
当开始一个大型项目时，为中途改变路线做好准备是至关重要的。如果你开发的项目在构思后没有改变，那么你可能在构建过程中没有学到任何东西，或者你不关心意外的曲折。规划无法完全预测所有现实世界的问题，因此请准备好在此过程中调整您的决定和信念。
你不应该害怕巨大的变化。许多人反对我们提出的更改，因为它带来的风险以及给开发人员带来的不便（将团队已经拥有的工具更改为团队完全未知的新工具）。
最终，该决定是基于其对我们产品改进的影响，而不是对我们的工程团队的影响，尽管这是我们迄今为止所做的最重要的工程变革之一。
您使用什么架构或系统并不重要。真正关心的是它能否带领你的产品走向光明的未来。