4 ms·
We're working on the cardinality problem. Will be resolved in an upcoming release. Moving the index over to a disk based format that will hopefully still be fas
by pauldix 10y ago
We're working on the cardinality problem. Will be resolved in an upcoming release. Moving the index over to a disk based format that will hopefully still be fast and not sacrifice lookup performance.
- bsg75 10y agoCan you explain the cardinality problem in a bit more detail? Its come up more than once in this thread.
- soundoflight 10y agohttps://docs.influxdata.com/influxdb/v1.0/concepts/glossary/#series-cardinality https://docs.influxdata.com/influxdb/v1.0/concepts/glossary/... You want to keep the amount of different data that you are indexing/tagging on low. As an example with my situation, I was tracking what could be amounted to connections between nodes in a very large tree. I had a lot of distinct pairs, which means that I had a high cardinality. When the cardinality increases a query that used to take a millisecond to load could move to a couple seconds.
- bsg75 10y agoSo InfluxDB v1.0 has issues with the cardinality of the "primary key" (or candidate keys) gets high? At what level of keys or tags did you start to see query performance become problematic?
- soundoflight 10y agoGood to hear! I have a project coming up soon that I want to use it on.