influxdb中的架构设计 [英] Schema design in influxdb

问题描述

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

My use case for influxDB is for storing and trending process data coming from different PLCs. I visualize this data using grafana. In a first pilot, I used the schema design guidelines from influxDB, using a generic measurement name and separating the different value sources by means of tags.

例如，当我在酸性"泵组中有2个泵，在苛性"泵组中有2个泵时，我对压力进行了测量:

For example, when I have 2 pumps in the 'acid' pump group and 2 pumps in the 'caustic' pump group of which I recond the pressure:

- 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的语言的非技术人员来说，这是非常令人困惑的.

In my use case, the end-user wants to be able to make their own trends using Grafana for example. While this way of recording the data is conform the schema design guidelines of influxDB (I think), it is very confusing for non technical people that are not used to working with and thinking in SQL like languages.

因此，我很想以惯用的方式存储数据，这是在类似产品(历史学家)中使用的通用方法:

Therefore, I'm tempted to store the data in the way that they are used to, and is the general way of working in similar products (historians):

- ACID_pump_1_pressure
- ACID_pump_2_pressure
- CAUSTIC_pump_1_pressure
- CAUSTIC_pump_2_pressure

这将使最终用户更容易制定趋势，因为1个度量=一个数据源，并且他们不必担心where和group by子句.

This would make it much easier for the end user to make trends, as 1 measurement = one data source, and they don't have to worry about where and group by clauses.

谁能为我提供一些线索，后者将对influxDB性能和存储产生什么影响.数据会以这种方式占用更多空间吗?请不要说后一种方法可能导致数千次测量，但是它们的基数都为1.

Can anyone point me to some clues what the impact of the latter would be on influxDB performance and storage. Will the data take more space in this way? Please not that the latter method can lead to a few thousand measurement, but their cardinality would all be 1.

推荐答案

如果没有更好的用例，就没有理由不这样做.您可以从这里开始的准则开始，因为它可以释放InfluxDB标记功能的全部功能.

There is no reason you can't do that if it fits your use-case better. The guidelines that you start with are there because it unlocks the full power of InfluxDB's tagging capability.

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

There will be no performance or storage implications. Internally, InfluxDB creates a new series based on each unique measurement "key", where the key is the combination of measurement name and tag key/value pairs.

即，每个都是单独的系列:

ie, each of these is a separate series:

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

此外，这些都是一个单独的系列:

also, each of these is a separate series:

ACID_pump_1_pressure
ACID_pump_2_pressure
CAUSTIC_pump_1_pressure
CAUSTIC_pump_2_pressure

编辑，来源:我在InfluxData工作

EDIT, source: I work at InfluxData

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

EDIT 2, this being said, I also agree fully with @srikanta and I would recommend keeping the tags, but finding another solution to interacting with the users of the db (or educating).

这篇关于influxdb中的架构设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！