InfluxDB 因大量数据而宕机答案

【问题标题】：InfluxDB goes down for huge dataInfluxDB 因大量数据而宕机
【发布时间】：2016-06-21 12:37:43
【问题描述】：

我正在使用 InfluxDB 构建仪表板。我有一个产生大约的来源。每分钟2000点。每个点有 5 个标签，6 个字段。只有一个测量值。

大约 24 小时内一切正常，但随着数据量的增长，我无法对 influx 运行任何查询。例如，现在我有大约 48 小时的数据，即使是基本的选择也会降低流入数据库，

select count(field1) from measurementname

错误超时：

ERR: Get http://localhost:8086/query?db=dbname&q=select+count%28field1%29+from+measuementname: EOF

配置：

我有一个仪表板和一个 Web 应用程序查询 influxdb。 webapp 允许用户根据 tag1 或 tag2 查询数据库。

标签：

【问题讨论】：

标签： influxdb

【解决方案1】：

tag1 - 每条记录都是唯一的。
tag2 - 每条记录都是唯一的。

这是一个糟糕的架构。您正在为每条记录创建一个新系列，这给数据库带来了沉重的负担。每个系列都必须被索引，并且整个索引当前必须驻留在 RAM 中。我怀疑由于系列基数，您在 48 小时后内存不足，而查询只是最后一根稻草，而不是导致 RAM 不足的实际原因。

在标签中使用唯一值是非常糟糕的做法。您仍然可以在 WHERE 子句中使用字段，只是它们的性能不那么好，而且对您的系统造成的损害远小于每个点都有一个唯一的系列。

【讨论】：

当然。如果您想调查设计结果，以下命令会非常有用：/usr/bin/find /var/lib/influxdb/data -type f -name '*.tsm' -printf '%h\n' | sort -u | xargs --delimiter "\n" --max-args 1 --replace={} sh -c 'du -h {};echo "\n";influx_inspect report -detailed {};echo "\n"' > /var/log/influxdb/inspect_$(date +'%Y%m%d_%H%M%S').log 2>&1
进一步将 tag1 和 tag2 移动到字段中的性能不佳：如果用户体验很重要，请检查您是否可以将用户可能需要的明显查询移动到连续查询中。这些仍然会表现不佳，但您会将性能影响转移到人们可能不会等待的时间。