主持人 > 博客 > 管理 > 使用 InfluxDB 时的愤怒、讨价还价和抑郁

使用 InfluxDB 时的愤怒、讨价还价和抑郁

使用 InfluxDB 时的愤怒、讨价还价和抑郁

如果您使用时间序列数据库（timeseries db， 维基）作为具有统计数据的站点的主要存储，那么您可能会遇到很多麻烦，而不是解决问题。 我正在做一个使用这样的数据库的项目，有时将要讨论的 InfluxDB 会带来完全意想不到的惊喜。

免责声明：列出的问题适用于 InfluxDB 版本 1.7.4。

为什么是时间序列？

该项目旨在跟踪各种区块链上的交易并显示统计数据。 具体来说，我们看看稳定币的发行和燃烧（维基）。 基于这些交易，您需要构建图表并显示汇总表。

在分析交易时，产生了一个想法：使用InfluxDB时序数据库作为主存储。 交易是时间点，它们非常适合时间序列模型。

聚合函数看起来也非常方便 - 非常适合处理长期图表。 用户需要一年的图表，数据库包含时间范围为五分钟的数据集。 向他发送全部十万个点是没有意义的——除了长时间的处理之外，它们甚至无法显示在屏幕上。 您可以编写自己的增加时间范围的实现，或使用 Influx 中内置的聚合函数。 在他们的帮助下，您可以按天对数据进行分组并发送所需的 365 个点。

令人有点困惑的是，此类数据库通常用于收集指标。 监控服务器、物联网设备以及数以百万计的点“流动”的一切：[<时间> - <指标值>]。 但是，如果数据库在大数据流下运行良好，那么为什么小数据流会导致问题呢？ 考虑到这一点，我们使用 InfluxDB 来工作。

InfluxDB还有什么方便的地方

除了上面提到的聚合函数之外，还有一个很棒的东西 - 连续查询 (DOC）。 这是数据库中内置的调度程序，可以按计划处理数据。 例如，每 24 小时您可以将当天的所有记录分组，计算平均值并在另一个表中记录一个新点，而无需编写自己的自行车。

也有一个 保留政策 (DOC)—设置一定时间后删除数据。 例如，当您需要存储一周的 CPU 负载并每秒测量一次，但在几个月的距离内不需要这种精度时，它非常有用。 在这种情况下，您可以这样做：

  1. 创建连续查询以将数据聚合到另一个表中；
  2. 对于第一个表，定义删除早于同一周的指标的策略。

而且Influx会独立减少数据的大小，删除不必要的东西。

关于存储的数据

存储的数据不多：大约 70 万笔交易和另外 3000 万个带有市场信息的点。 添加新条目 - 每天不超过 XNUMX 点。 该网站也有一些指标，但那里的数据很少，而且根据保留政策，它们的存储时间不超过一个月。

问题

在服务的开发和后续测试过程中，InfluxDB的运行出现了越来越多的关键问题。

1. 删除数据

有一系列的交易数据：

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

结果：

使用 InfluxDB 时的愤怒、讨价还价和抑郁

我正在发送删除数据的命令：

DELETE FROM transactions WHERE symbol=’USDT’

接下来我请求接收已删除的数据。 Influx 返回的不是空响应，而是应删除的部分数据。

我正在尝试删除整个表：

DROP MEASUREMENT transactions

我检查表删除：

SHOW MEASUREMENTS

我在列表中没有看到该表，但新的数据查询仍然返回相同的事务集。

这个问题只出现在我身上一次，因为删除案例是一个孤立的案例。 但数据库的这种行为显然不符合“正确”操作的框架。 后来发现github上开放了 票 大约一年前关于这个话题。

因此，删除然后恢复整个数据库会有所帮助。

2. 浮点数

在 InfluxDB 中使用内置函数时的数学计算存在精度错误。 这并不是什么不寻常的事情，但它是令人不愉快的。

就我而言，数据包含财务成分，我希望对其进行高精度处理。 因此，我们计划放弃连续查询。

3、连续查询无法适配不同时区

该服务有一个包含每日交易统计数据的表。 对于每一天，您需要对当天的所有交易进行分组。 但每个用户的一天将在不同的时间开始，因此交易集也会不同。 按 UTC 时间 是 37选项 您需要汇总数据的班次。

在 InfluxDB 中，按时间分组时，您还可以指定班次，例如莫斯科时间 (UTC+3)：

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

但查询结果会不正确。 由于某种原因，按天分组的数据会一直追溯到1677年（InfluxDB官方支持从今年开始的时间跨度）：

使用 InfluxDB 时的愤怒、讨价还价和抑郁

为了解决这个问题，我们暂时将服务切换到 UTC+0。

4. 性能

互联网上有很多比较 InfluxDB 和其他数据库的基准测试。 乍一看，它们看起来像是营销材料，但现在我认为其中有一些道理。

我来告诉你我的情况。

该服务提供了一个 API 方法来返回最后一天的统计信息。 执行计算时，该方法使用以下查询查询数据库 XNUMX 次：

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

解释：

  1. 在第一个请求中，我们通过市场数据获取每种代币的最后分数。 就我而言，八个硬币可以得到八个积分。
  2. 第二个请求获取最新点之一。
  3. 第三个请求请求过去 XNUMX 小时内的交易列表；可能有数百个。

让我澄清一下，InfluxDB会根据标签和时间自动构建索引，从而加快查询速度。 在第一个请求中 符号 是一个标签。

我已经对此 API 方法进行了压力测试。 对于 25 RPS，服务器展示了 XNUMX 个 CPU 的满负载：

使用 InfluxDB 时的愤怒、讨价还价和抑郁

同时，NodeJs进程根本不提供任何负载。

执行速度已经下降了 7-10 RPS：如果一个客户端可以在 200 毫秒内收到响应，那么 10 个客户端就必须等待一秒钟。 25 RPS 是稳定性受到影响的极限；向客户端返回了 500 个错误。

有了这样的性能，不可能在我们的项目中使用 Influx。 而且：在一个需要向很多客户端演示监控的项目中，可能会出现类似的问题，并且指标服务器会过载。

结论

从所获得的经验中得出的最重要的结论是，如果没有充分的分析，就不能将未知的技术应用到项目中。 对 github 上的未解决问题进行简单筛选可以提供信息，以避免选择 InfluxDB 作为主要数据存储。

InfluxDB 本来应该很适合我的项目的任务，但实践表明，这个数据库并不能满足需求，而且有很多 bug。

您已经可以在项目存储库中找到版本 2.0.0-beta；我们只能希望第二个版本能够有重大改进。 与此同时，我将去研究 TimescaleDB 文档。

来源： habr.com

添加评论