3 ms·

Cardinality is only expensive if the metric dimensions/tags/labels are a part of the builtin metric data model (like for example in InfluxDB). It's not expensi

Cardinality is only expensive if the metric dimensions/tags/labels are a part of the builtin metric data model (like for example in InfluxDB). It's not expensive when dimensions are just columns in the custom table schema, like for example in TimescaleDB or kdb+/q. Also in the latter case a single database "row" can contain multiple metrics (each modeled as a separate column in a table).

hardwaresofton 5y ago
> It's not expensive when dimensions are just columns in the custom table schema, like for example in TimescaleDB or kdb+/q. kdb+/q (not exactly sure) is the one that is used heavily in finance, correct? [EDIT] - Yup[0][1]. I'm not sure how many competitors there are but last time I heard about kdb it seemed like they were pretty much the go-to choice outside comp sci land (which is normally preoccupied with influx, prometheus, timescale, etc). There's probably a reason it's trusted by those other fields. [0]: https://kx.com/ https://kx.com/ [1]: https://code.kx.com/home/ https://code.kx.com/home/
- liveoneggs 5y ago
  kdb is crazy expensive which is why storing your 5-min load average inside of it doesn't make much sense
- nivertech 5y ago
  kdb+/q was originally heavily used in finance/trading, but nowadays also in IoT/IIoT. The q language itself is pretty-much general purpose PL, but of course it shines for timeseries processing workloads.
claytonjy 5y ago
This is true, but given this post and the one linked about their custom column store, I don't think Timescale would fit. Timescale is still row-oriented while in memory (compressed chunks are columnar), though that may not be a big deal in practice; the bigger deal might be the ability to arbitrarily add columns. With Timescale you either have to issue DDL to add a column (which can be expensive and doesn't work in some cases), or resign yourself to JSONB. My worry with the JSONB is that it'll be expensive to search w/o indices, but if you need indices that goes against the Honeycomb philosophy. Very curious to hear if folks more deeply familiar with TimescaleDB internals have a different take!

hardwaresofton 5y ago

> It's not expensive when dimensions are just columns in the custom table schema, like for example in TimescaleDB or kdb+/q. kdb+/q (not exactly sure) is the one that is used heavily in finance, correct? [EDIT] - Yup[0][1]. I'm not sure how many competitors there are but last time I heard about kdb it seemed like they were pretty much the go-to choice outside comp sci land (which is normally preoccupied with influx, prometheus, timescale, etc). There's probably a reason it's trusted by those other fields. [0]: https://kx.com/ https://kx.com/ [1]: https://code.kx.com/home/ https://code.kx.com/home/

liveoneggs 5y ago
kdb is crazy expensive which is why storing your 5-min load average inside of it doesn't make much sense
nivertech 5y ago
kdb+/q was originally heavily used in finance/trading, but nowadays also in IoT/IIoT. The q language itself is pretty-much general purpose PL, but of course it shines for timeseries processing workloads.

claytonjy 5y ago

This is true, but given this post and the one linked about their custom column store, I don't think Timescale would fit. Timescale is still row-oriented while in memory (compressed chunks are columnar), though that may not be a big deal in practice; the bigger deal might be the ability to arbitrarily add columns. With Timescale you either have to issue DDL to add a column (which can be expensive and doesn't work in some cases), or resign yourself to JSONB. My worry with the JSONB is that it'll be expensive to search w/o indices, but if you need indices that goes against the Honeycomb philosophy. Very curious to hear if folks more deeply familiar with TimescaleDB internals have a different take!