我们有一个非常恼人的InfluxDB问题(没有集群)。我们的InfluxDB版本是1.7。
作为我们业务需求的一部分,我们存储事件的点(或数据)。我们时不时地会有峰值(一天大约有2000万次事件)。
我们有两个键的标签- tag1,tag2和键值- value1。
我们运行后的基数:
SHOW SERIES CARDINALITY ON db1是24。
具体来说,对于这个具有2000万个点的度量'measurement1‘,我们只有一个系列(我们只有一对关键字tag1和tag2的值):
measurement1,tag1=tag1value,tag2=tag2value现在,正如我所说的,如果在选定的一段时间内,我们可以拥有高达2000万点。
SELECT SUM(someDoubleValue) AS result
FROM measurement1
WHERE time > '2019-04-15T21:00:00Z'
AND time < '2019-05-17T20:59:59.999Z'
AND (tag1 = '1234567')
GROUP BY time(30d, 21h) FILL(0);这个查询在6-7秒后返回,但它消耗了80-100%的cpu。
现在基数是低的(也许我可能错了--有没有其他方法来验证我们的基数是低的?)。
我们想要解决的另一个问题是,在我们的一些流程中,我们可以并行调用2-3个这样的查询。当然,这会导致它们全部失败(我们的客户端超时)。
我们试图弄清楚这是否是分片问题--我们使用的默认分片是1周,所以我们不认为查询2个月应该是个问题。
我们增加了机器的功率,但没有运气-从i3-large到i3-xlarge (AWS)。
我们正在尝试找出这是InfluxDB中的一个问题,还是我们测量的一些错误配置。
发布于 2019-05-16 03:39:14
您使用的是tsm索引吗?我们的tsi索引提供了性能改进,这可能会有所帮助。
https://docs.influxdata.com/influxdb/v1.7/concepts/tsi-details/
https://stackoverflow.com/questions/56117854
复制相似问题