在Influxdb中的架构设计

Question

我对InfluxDB的使用案例是存储和趋势来自不同PLC的过程数据.我使用grafana可视化这些数据.在第一个试验中,我使用了来自潮流数据库的模式设计指南,使用通用测量名称并通过标记分离不同的值源.

例如,当我在'酸'泵组中有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制作自己的趋势.虽然这种记录数据的方式符合潮流数据库的模式设计指南(我认为),但对于那些不习惯在SQL语言中工作和思考的非技术人员来说,这是非常困惑的.

因此,我很想以他们习惯的方式存储数据,并且是在类似产品(历史学家)中工作的一般方式:

- ACID_pump_1_pressure
- ACID_pump_2_pressure
- CAUSTIC_pump_1_pressure
- CAUSTIC_pump_2_pressure

这将使最终用户更容易制作趋势,因为1次测量=一个数据源,他们不必担心where和group by从句.

任何人都可以向我指出一些线索,后者对潮流数据库性能和存储的影响.数据会以这种方式占用更多空间吗？请注意,后一种方法可以导致几千次测量,但它们的基数都是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工作

编辑2,这就是说,我也完全同意@srikanta,我建议保留标签,但找到另一个解决方案来与数据库的用户(或教育)进行交互.