influxdb 中的模式设计

Question

我的 influxDB 用例是用于存储和趋势来自不同 PLC 的过程数据。我使用 grafana 可视化这些数据。在第一个试验中，我使用了来自 influxDB 的模式设计指南，使用通用的度量名称并通过标签分隔不同的值源。

例如，当我在“酸”泵组中有 2 个泵，在“苛性”泵组中有 2 个泵时，我会重新计算压力：

- pump_pressure {pump: pump_1, group: acid} 
- pump_pressure {pump: pump_2, group: acid} 
- pump_pressure {pump: pump_1, group: caustic} 
- pump_pressure {pump: pump_2, group: caustic} 

在我的用例中，最终用户希望能够使用 Grafana 制作自己的趋势。虽然这种记录数据的方式符合 influxDB 的架构设计指南（我认为），但对于不习惯使用类似 SQL 的语言进行工作和思考的非技术人员来说，这非常令人困惑。

因此，我很想以他们习惯的方式存储数据，这是在类似产品中工作的一般方式（历史学家）：

- ACID_pump_1_pressure
- ACID_pump_2_pressure
- CAUSTIC_pump_1_pressure
- CAUSTIC_pump_2_pressure

这将使最终用户更容易做出趋势，因为 1 次测量 = 一个数据源，他们不必担心 where 和 group by 子句。

谁能指出一些线索，后者会对 influxDB 性能和存储产生什么影响。数据会以这种方式占用更多空间吗？请注意，后一种方法可能会导致几千次测量，但它们的基数都是 1。

Answer 1

如果它更适合您的用例，您没有理由不能这样做。您开始使用的指南就在那里，因为它释放了 InfluxDB 标记功能的全部力量。

不会影响性能或存储。在内部，InfluxDB 基于每个唯一的测量“键”创建一个新系列，其中键是测量名称和标签键/值对的组合。

即，每一个都是一个单独的系列：

pump_pressure,pump=pump_1,group=acid
pump_pressure,pump=pump_2,group=acid
pump_pressure,pump=pump_1,group=caustic
pump_pressure,pump=pump_2,group=caustic

另外，每一个都是一个单独的系列：

ACID_pump_1_pressure
ACID_pump_2_pressure
CAUSTIC_pump_1_pressure
CAUSTIC_pump_2_pressure

编辑，来源：我在 InfluxData 工作

EDIT 2，话虽这么说，我也完全同意@srikanta，我建议保留标签，但寻找另一种解决方案来与数据库用户交互（或教育）。

Answer 2

确实，您可以采用这种方法。然而，这是不可扩展的。如果使用的泵数量增加怎么办？然后，这种方法也适用于泵数量等于时间序列数量的情况。但是，管理起来很痛苦。

如果要避免非技术用户与 SQL 查询交互的问题，则应考虑不同的方法，而不是改变数据库的“模式”。

更多见解 --> https://blog.zhaw.ch/icclab/influxdb-design-guidelines-to-avoid-performance-issues/