时间序列数据存储：RDBMS 与 NoSQL
Time Series Data storing: RDBMS vs NoSQL
最近，我面临着存储一些时间序列数据的问题。
此数据取自工业机器：对于每个作业（大约每小时 3 个，24/24 小时），软件记录：
- 油压;
- 油温；
- 一些振动数据。
振动数据以非常高的频率（> 10 kHz）获取，导致非常大的内存需求。这个问题让我的公司评估了一些有效存储这些数据的可能性。
插入不会很频繁（当机器不工作时，可能每天 1 或 2 次）。
读取可能会非常频繁（另一个软件将检索数据用于绘图和分析目的）。
目前，单个节点将用于存储数据，所以我不想（暂时）考虑分区和并行化问题。
我应该选择哪种解决方案？
关系型 DBMS（例如 MySQL 或 PostgreSQL），或通用的 NoSQL DB（例如，面向列的数据库——考虑所有时间序列都是单变量的——如 Cassandra，或面向文档的数据库，喜欢 MongoDB)?
除了我的特定用例之外，通常什么时候更喜欢 RDMBS 而不是 NoSQL 来存储时间序列？什么时候更喜欢 NoSQL 而不是 RDBMS？
tl；博士：
通常对于时间序列，我会使用像 InfluxDb 这样的时间序列数据库。
对非结构化的大量数据使用否SQL，例如：日志记录结果、网站搜索数据等。非常适合针对特定查询进行优化。
当您有简单的实体时，也可以使用 NoSQL（文档存储），这些实体基本上可以包含关于该实体的所有内容。由于数据模型通常较小，因此在微服务中派上用场。
使用关系数据库：当您具有层次结构时，例如：销售流程的工作流程的来龙去脉。如果必须在大量数据上保持数据结构完整性，则关系型工作得更好。
这里有一个关于如何处理各种关系的很好的总结：关系存储与文档存储：https://completedeveloperpodcast.com/document-vs-relational-databases/
嗯，总的来说，网上有很多关于这个主题的内容。通常，在关系数据库中，原理图是已知的 “预先” - 尽管它会随时间变化，但它是非常静态的。
大多数 Not-only-SQL 的最大 “好处” 是他们：
- 不需要固定的原理图和固定的关系来保持数据的一致性。这意味着 - 例如图形数据库 - 您可以更轻松、更灵活地与其他对象相关联，或者您必须有几个独立的 tables.
- 通过设计能够（更好的）水平缩放，这在更大的系统中是解决性能相关问题的一大好处。 （考虑成为一对独立的 table 看看为什么）
- 数据不需要（非常）结构化。如果您需要在数据库中包含外部数据源或典型的非结构化数据，这又是一个好处。
- 适用于小型实体，查询优化存储。
注意：有多种 NoSQL 数据库类型，所有类型都有不同的方法和各自的优缺点。
所以：
Beyond my particular use case, when generally to prefer RDMBS over NoSQL for Time Series storing?
使用 RDMBS 时，您需要 - 至少 - 预先了解您的原理图，并且预计它们不会经常更改。
如果满足以下条件，您更喜欢 RDMBS：
- 这种结构化数据和一致性检查是您存储的数据的固有 属性。例如：维护仓库库存清单、跟踪工作时间等
- 你的数据存储可以被看作是一个孤立的权威。例如：文件系统索引器或产品测试结果存储。
When to prefer NoSQL over RDBMS?
如果满足以下条件，您更喜欢否SQL：
- 您无法预先确定所有关系并期望经常添加数据、来源和关系。典型的用例是大数据存储、关系存储；更具体：社交网络、高级统计相关性或经常变化的外部数据提供者。
- 您需要高可扩展性，这在大多数 NoSQL 系统中更为自然。
- 您只是想以或多或少的结构化方式将一些数据转储到云中的某处。例如，创建一个简单的 table 来保存设置记录。
- 具有简单的实体和查询，不需要复杂的连接和分层数据
关于您的用例：
看来你的数据结构是众所周知的和固定的。这恳求关系数据库。
数据量及其简单性是争取否SQL的理由。
至于高负载：数据结构也是预先知道的。尽管如此，还是有一些问题涉及处理高负载。关系数据库可以配置为与此数量相匹配，并且性能非常好，但 NoSQL 通常对此进行了更好的优化。
我觉得这有点平衡，而过去是关系型的；在这种情况下，我现在会去文档存储。
然而，它确实提出了另一个问题：由于您是 24/7 全天候监控；您多久需要一次去年或前一年的数据？上个月还是上周？
我问这个问题是因为有更多选项可以处理这些数据量。历史数据通常被视为日志，并且只是“偶尔”请求。在那种情况下，您可以将数据块存储在不同的服务器上，甚至以不同的形式存储。例如，10kHz 的振动数据也可以存储在专用服务器上，以 blob 或存储数据流的形式。
最近，我面临着存储一些时间序列数据的问题。
此数据取自工业机器：对于每个作业（大约每小时 3 个，24/24 小时），软件记录：
- 油压;
- 油温；
- 一些振动数据。
振动数据以非常高的频率（> 10 kHz）获取，导致非常大的内存需求。这个问题让我的公司评估了一些有效存储这些数据的可能性。
插入不会很频繁（当机器不工作时，可能每天 1 或 2 次）。 读取可能会非常频繁（另一个软件将检索数据用于绘图和分析目的）。
目前，单个节点将用于存储数据，所以我不想（暂时）考虑分区和并行化问题。
我应该选择哪种解决方案？ 关系型 DBMS（例如 MySQL 或 PostgreSQL），或通用的 NoSQL DB（例如，面向列的数据库——考虑所有时间序列都是单变量的——如 Cassandra，或面向文档的数据库，喜欢 MongoDB)?
除了我的特定用例之外，通常什么时候更喜欢 RDMBS 而不是 NoSQL 来存储时间序列？什么时候更喜欢 NoSQL 而不是 RDBMS？
tl；博士：
通常对于时间序列，我会使用像 InfluxDb 这样的时间序列数据库。
对非结构化的大量数据使用否SQL，例如：日志记录结果、网站搜索数据等。非常适合针对特定查询进行优化。
当您有简单的实体时，也可以使用 NoSQL（文档存储），这些实体基本上可以包含关于该实体的所有内容。由于数据模型通常较小，因此在微服务中派上用场。
使用关系数据库：当您具有层次结构时，例如：销售流程的工作流程的来龙去脉。如果必须在大量数据上保持数据结构完整性，则关系型工作得更好。
这里有一个关于如何处理各种关系的很好的总结：关系存储与文档存储：https://completedeveloperpodcast.com/document-vs-relational-databases/
嗯，总的来说，网上有很多关于这个主题的内容。通常，在关系数据库中，原理图是已知的 “预先” - 尽管它会随时间变化，但它是非常静态的。
大多数 Not-only-SQL 的最大 “好处” 是他们：
- 不需要固定的原理图和固定的关系来保持数据的一致性。这意味着 - 例如图形数据库 - 您可以更轻松、更灵活地与其他对象相关联，或者您必须有几个独立的 tables.
- 通过设计能够（更好的）水平缩放，这在更大的系统中是解决性能相关问题的一大好处。 （考虑成为一对独立的 table 看看为什么）
- 数据不需要（非常）结构化。如果您需要在数据库中包含外部数据源或典型的非结构化数据，这又是一个好处。
- 适用于小型实体，查询优化存储。
注意：有多种 NoSQL 数据库类型，所有类型都有不同的方法和各自的优缺点。
所以：
Beyond my particular use case, when generally to prefer RDMBS over NoSQL for Time Series storing?
使用 RDMBS 时，您需要 - 至少 - 预先了解您的原理图，并且预计它们不会经常更改。
如果满足以下条件，您更喜欢 RDMBS：
- 这种结构化数据和一致性检查是您存储的数据的固有 属性。例如：维护仓库库存清单、跟踪工作时间等
- 你的数据存储可以被看作是一个孤立的权威。例如：文件系统索引器或产品测试结果存储。
When to prefer NoSQL over RDBMS?
如果满足以下条件，您更喜欢否SQL：
- 您无法预先确定所有关系并期望经常添加数据、来源和关系。典型的用例是大数据存储、关系存储；更具体：社交网络、高级统计相关性或经常变化的外部数据提供者。
- 您需要高可扩展性，这在大多数 NoSQL 系统中更为自然。
- 您只是想以或多或少的结构化方式将一些数据转储到云中的某处。例如，创建一个简单的 table 来保存设置记录。
- 具有简单的实体和查询，不需要复杂的连接和分层数据
关于您的用例：
看来你的数据结构是众所周知的和固定的。这恳求关系数据库。
数据量及其简单性是争取否SQL的理由。
至于高负载：数据结构也是预先知道的。尽管如此，还是有一些问题涉及处理高负载。关系数据库可以配置为与此数量相匹配，并且性能非常好，但 NoSQL 通常对此进行了更好的优化。
我觉得这有点平衡，而过去是关系型的；在这种情况下，我现在会去文档存储。
然而，它确实提出了另一个问题：由于您是 24/7 全天候监控；您多久需要一次去年或前一年的数据？上个月还是上周？
我问这个问题是因为有更多选项可以处理这些数据量。历史数据通常被视为日志，并且只是“偶尔”请求。在那种情况下，您可以将数据块存储在不同的服务器上，甚至以不同的形式存储。例如，10kHz 的振动数据也可以存储在专用服务器上，以 blob 或存储数据流的形式。