在设计InfluxDB 模式时，如何在字段和标签中存储数据之间进行选择有哪些好的规则和示例？

到目前为止我发现的是：

随时间变化的测量应该是一个字段，关于测量的元数据应该在标签中

标签和字段实际上是表中的列。标记已编入索引，字段未编入索引

高度变异且通常不属于 WHERE 子句的值被放入字段中

如果您打算将数据与 InfluxQL 函数一起使用，则将数据存储在字段中

包含高度可变信息（如 UUID、哈希和随机字符串）的标签将导致数据库中出现大量系列，通俗地称为高系列基数。高系列基数是许多数据库工作负载高内存使用率的主要驱动因素。

但是，假设您在电子商务应用程序中存储已填写的订单：订单 ID、销售价格、货币。

• 订单 ID 应该是标签还是字段？
• 货币应该是标签还是字段？

我有以下 SQL 时间序列表：

CREATE TABLE [dbo].[SensorData](
 [DateTimeUtc] [datetime2](2) NOT NULL,
 [SensorId] [int] NOT NULL,
 [Key] [varchar](20) NOT NULL,
 [Value] [decimal](19, 4) NULL,
CONSTRAINT [PK_SensorData] PRIMARY KEY CLUSTERED 
(
  [SensorId] ASC,
  [Key] ASC,
  [DateTimeUtc] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = 
ON, Data_Compression=PAGE) ON PS_Daily(DateTimeUtc))

现在基于这个索引，每个单独的查询都需要在查询where过滤器中包含以下参数：

CREATE TABLE [dbo].[SensorData](
 [DateTimeUtc] [datetime2](2) NOT NULL,
 [SensorId] [int] NOT NULL,
 [Key] [varchar](20) NOT NULL,
 [Value] [decimal](19, 4) NULL,
CONSTRAINT [PK_SensorData] PRIMARY KEY CLUSTERED 
(
  [SensorId] ASC,
  [Key] ASC,
  [DateTimeUtc] ASC
)WITH …

我被要求为时间序列数据开发数据存储，尽管进行了大量研究，但我不确定要选择的数据模型和存储技术。

关于数据

要存储在数据存储器中的源数据由物理测量单元提供。每个单元可能有也可能没有不同的变量子集，每个测量站有多达 300 个变量（例如燃料类型、燃料消耗、速度），而所有站的不同信号数量约为 1500。预先知道每个站的预期变量子集。但是，随着时间的推移，可能会向站点添加额外的传感器（随着时间的推移，可能需要更改架构）。所有站都以从 20Hz 到 0.2Hz 的不同速率提供数据。

此外，还有相当数量的元数据可供所有这些测量站使用，最终我们将拥有大约 500 个。

数据通常是批量输入的，而不是“实时”流。批次大小从每小时批次到每月批次不等。

关于查询

进行数据查询主要有两个原因，单测站数据的上报和统计分析，以及跨站比较。大约 80% 的查询与过去 30 天内输入的数据有关。查询每天进行，因此SELECT负载超过INSERT负载。

理想情况下查询像

SELECT var1, var2, ... varN FROM station_data WHERE station_id=X OR station_id=Y AND TIMESTAMP BETWEEN ... AND ...;

非 SQL 专家可以轻松访问数据。此外，简单的基于时间的聚合算法应该是可能的（AVG、MAX 等 pp）。

现在的情况

目前，使用高度规范化的结构将数据存储在 PostgreSQL 数据库中，该数据库现在增长到大约 6TB，每个变量一个表。大约 1500 个数据表中的每一个都是这样的形式

(timestamp, station_id, value)

索引(station_id), (station_id, timestamp), (timestamp)和唯一约束(station_id, timestamp, value)。

这种结构需要大量的外部连接（最多 300 个外部连接），这使得数据检索变得繁琐且计算成本高。

研究

到目前为止，进行了以下考虑：

数据库技术

1. 虽然 NoSQL 将提供所需的架构灵活性，但确保数据完整性、访问控制和元数据管理的工具似乎具有挑战性，并且内部不存在 NoSQL 经验。此外，阅读与此相关的评论和答案似乎有利于我们用例的 …

这是情况：

• 来自一组非常有限的来源的大量时间序列数据将保存在 SQLite 数据库文件中。
• 时间序列源由 10 个字符长的字符串标识。来源的数量非常少，而且根本不是动态的。
• 无需立即对时间序列源之间进行任何相关分析。

我想，按照惯例，人们会将所有时间序列数据转储到单个表中，并带有标识每个数据点来源的文本字段。

但是，我想知道为每个时间序列数据源创建一个单独的表是否会更有效？通过消除重复的文本字段，SQLite 数据库的文件大小最终会小很多吗？查询会运行得更快吗？

或者我应该完全避免为每个来源创建表格以及出于什么原因？

数据库不会很大，这可能保证在 MySQL 上使用 SQLite。除了整数时间戳，还有四个整数字段。每 3 分钟进行一次测量，但它可以轻松运行一年或更长时间。部分设计最终可能会出现在闪存容量非常有限（64Mbit）的嵌入式设备中，因此我最初对 SQLite 感兴趣。但是，我愿意接受其他建议。

题

如何改进此查询以将下面显示的查询速度从30+ 秒提高到毫秒？我正在使用PostgreSQL: v 9.6.6。

语境

我有一个时间序列表buildings.hispoint，用于存储表中数据点的历史数据buildings.point。

我需要Max(value) - Min(value) as aggregation_value为大量数据点汇总不同时间范围（例如，年初至今）的数据。

事实证明，这非常缓慢，需要改进。

表结构buildings.hispoint （20,210,129行）

CREATE TABLE buildings.hispoint (
    id int,
    value float,
    datetime timestamp,
    point_id …
    CONSTRAINT foo FOREIGN KEY (point_id)
    REFERENCES buildings.point (point_id),
    …
);

询问

SELECT COUNT(datetime) AS id, 
MAX(value) - MIN(value) AS aggregation_value
FROM buildings_hispoint
WHERE point_id = 44 
AND buildings_hispoint.datetime BETWEEN '2018-01-01 00:00:00' AND '2018-05-02 09:18:14';

查询计划

Aggregate  (cost=160967.11..160967.12 rows=1 width=16) (actual time=21713.720..21713.720 rows=1 …