Launch HN: QuestDB (YC S20) – Fast open source time series database

Re:Launch HN: QuestDB (YC S20) – Fast open source time serie... by bluestreak on Tuesday July 28, 2020 @02:54PM (#23979372)

We store "dimensions" as table columns with no artificial limits on column count. If you able to send all dimensions in the same message, they will be stored on one row of data. If dimensions are sent as separate messages, current implementation will store them on different rows. This will make columns sparse. We can change that if need be and "update" the same row as dimensions arrive as long as they have the same timestamp value.

There is an option to store set of dimensions separately as asof/splice join separate tables.

[ Parent | on HN ]

Re:Launch HN: QuestDB (YC S20) – Fast open source time serie... by hintymad on Tuesday July 28, 2020 @05:09PM (#23980735)

Thanks for the explanation.

[ Parent | on HN ]

Re:Launch HN: QuestDB (YC S20) – Fast open source time serie... by architectonic on Tuesday July 28, 2020 @05:18PM (#23980809)

Can you handle multiple time dimensions efficiently? We have 3 of them, can one get away without having to physically store "slices" on one of them?

[ Parent | on HN ]

Re:Launch HN: QuestDB (YC S20) – Fast open source time serie... by bluestreak on Tuesday July 28, 2020 @06:47PM (#23981511)

if you can send all three in the same message, Influx Line Protocol for example, we will store them as 3 columns in one table. Does this help?

[ Parent | on HN ]