时间序列数据存储：RDBMS 与 NoSQL

Question

这些天我面临着存储一些时间序列数据的问题。

该数据取自一台工业机器：对于每个作业（大约每小时 3 个，24/24h），一个软件记录：

• 油压;
• 油温；
• 一些振动数据。

振动数据以非常高的频率 (> 10 kHz) 获取，并导致非常大的内存需求。这个问题让我的公司评估了一些有效存储这些数据的可能性。

插入不会很频繁（可能每天 1 或 2 次，当机器不工作时）。读取可能非常频繁（另一个软件将检索数据以进行绘图和分析）。

目前，将使用单个节点来存储数据，所以我不想（目前）考虑分区和并行化问题。

我应该更喜欢哪种解决方案？关系型 DBMS（例如 MySQL 或 PostgreSQL），还是通用的 NoSQL DB（例如面向列的数据库 - 考虑到所有时间序列都是单变量的 - 像 Cassandra，或面向文档的数据库，像 MongoDB）？

除了我的特定用例之外，何时通常更喜欢 RDMBS 而不是 NoSQL 进行时间序列存储？什么时候更喜欢 NoSQL 而不是 RDBMS？

Answer 1

tl;博士：

将 NoSQL 用于非结构化的大量数据，例如：记录结果、网站搜索数据等。

使用关系数据库：当您有一个层次结构时：销售流程的工作流程的进出。

嗯，总的来说，网上有很多关于这个主题的内容。一般来说，在关系数据库中，原理图是“预先”已知的——尽管它会随着时间而改变，但它是相当静态的。

大多数 Not-only-SQL的最大“好处”在于：

• 不需要固定的原理图和固定的关系来保持数据的一致性。这意味着 - 例如图形数据库 - 您可以更轻松、更灵活地关联其他对象，或者您必须拥有几个独立的表。
• 通过设计能够（更好的）水平扩展，这在更大的系统中是解决性能相关问题的一大好处。（考虑成为几个独立的表以了解原因）
• 数据不需要（非常）结构化。如果您需要在数据库中包含外部数据源或典型的非结构化数据，这再次是一个好处。

注意：有多种 NoSQL 数据库类型，所有类型都有不同的方法和各自的优缺点。

所以：

除了我的特定用例之外，何时通常更喜欢 RDMBS 而不是 NoSQL 进行时间序列存储？

使用 RDMBS 时，您需要 - 至少 - 预先了解您的原理图，并且预计它们不会经常更改。

在以下情况下，您更喜欢 RDMBS：

• 这种结构化数据和一致性检查是您存储的数据的固有属性。例如：维护仓库库存清单，跟踪工作时间等。
• 您的数据存储可以被视为一个孤立的权威。例如：文件系统索引器或产品测试结果存储。

什么时候更喜欢 NoSQL 而不是 RDBMS？

在以下情况下，您更喜欢 NoSQL：

• 您无法预先确定所有关系并期望频繁添加数据、来源和关系。典型用例是大数据存储、关系存储；更具体的：社交网络、高级统计相关性或频繁变化的外部数据提供者。
• 您需要高可扩展性，这在大多数 NoSQL 系统中更为自然。
• 您只想以或多或少的结构化方式将一些数据转储到云中的某处。例如，创建一个简单的表来保存设置记录。

至于您的用例：

看来您的数据结构是众所周知且固定的。这需要一个关系数据库。

至于高负载：数据结构也是预先知道的。尽管如此，还是有一些问题可以处理高负载。可以将关系数据库配置为与此数量相匹配并且性能非常好，但 NoSQL 通常对读取它进行了更好的优化。

所以除此之外 - 这是一次不错的体验 - 我没有看到支持 NoSQL 的强有力的论据（尽管我可能会遗漏一些东西[比如性能]）。

另一方面，它确实提出了另一个问题：既然您是 24/7 全天候监控；您多久需要一次去年或前一年的数据？上个月还是上周？

我只是问，因为有更多的选择来处理这些数据量。历史数据通常被视为日志，并且仅“偶尔”请求。在这种情况下，您可以将数据卡存储在不同的服务器上，甚至以不同的形式存储。例如，10kHz 振动数据也可以以 blob 或存储数据流的形式存储在专用服务器上。