4 ms·
It's explained in section 1.2. My interpretation is; Oxide already chose to use Clickhouse as their DB for metrics in it's rack. You can't just slap PromQL on
by jsiepkes 2y ago
It's explained in section 1.2.
My interpretation is; Oxide already chose to use Clickhouse as their DB for metrics in it's rack. You can't just slap PromQL on Clickhouse because DSL's like PromQL reflect some of the inner workings of for example Prometheus. Hence they needed a DSL which was somewhat opinionated towards Clickhouse in order to make it work.
- antonyt 2y agoYou can, however, slap PRQL or KQL on top of Clickhouse. https://clickhouse.com/docs/en/guides/developer/alternative-query-languages https://clickhouse.com/docs/en/guides/developer/alternative-... 1.2 doesn't go into nearly enough detail to be convincing, in my opinion.
- jsiepkes 2y agoAs far as I know neither PRQL nor KQL are DSL's intended for querying timeseries (like PromQL). Even other timeseries DB's like Influx DB which are somewhat similar to Prometheus have their own DSL (for example InfluxQL in case of influx DB). Personally I think this sentence summarizes the need pretty well: "Many telemetry systems have implemented their own DSL, and each tends to be tailored (intentionally or not) to the underlying data model and storage mechanisms.".
- antonyt 2y agoKQL, at least, is exactly a DSL intended for querying timeseries. Also it's not like they've implemented a custom storage back-end, it's ClickHouse. ClickHouse itself thinks SQL is fine for querying time-series data (as do Snowflake and TimeScale, for that matter). Ultimately of course Oxide can do what it wants, but the justifications provided in this doc are thin enough to make NIH seem like a very plausible explanation. Perhaps the problem domain is more complicated than just retrieving some time-series data out of ClickHouse, and the doc fails to make that clear.