cevian

8 ms·

31.
by cevian 6y ago
(TimescaleDB engineer) we hear you and are working on making continuous aggregations easier to use. For now, the recommended approach is to perform continuous_aggregates on single tables and perform joins, order by, and window when querying
32.
by cevian 6y ago
You can look at what we use in our benchmarking tool https://github.com/timescale/tsbs (results described here https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-... ). Pretty much it&#x27
33.
by cevian 6y ago
(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
34.
by cevian 6y ago
(TimescaleDB engineer) Actually, the reason we break out the Jsonb like this is because json blobs are big and take up a lot of space and so we normalize it out. This is the same thing that InfluxDB or Prometheus do under the hood. We also
35.
by cevian 6y ago
(TimescaleDB engineer here). This is a really unfair critique. The project you cite is super-optimized for the Prometheus use-case and data model. TimescaleDB beats InfluxDB on performance even without these optimization. It's also not
36.
by cevian 6y ago
(Timescale-Prometheus team lead here) I'd suggest using Timescale-Prometheus to connect Prometheus with TimescaleDB. Repo: https://github.com/timescale/timescale-prometheus Design Doc: https://tsdb.co&#
37.
by cevian 6y ago
To be clear, TimescaleDB does NOT throw away and indexing capabilities or ACID features. Its only limitation is that UNIQUE constraints need to include the time column. Also, its query optimizations are far from trivial to implement.
38.
by cevian 6y ago
Just as a point of clarification: timescale materialized views don't allow joins during materialization. But you can join materialized views arbitrarily at query time. (TimescaleDB engineer here)
39.
by cevian 6y ago
Another thing to mention is that TimescaleDB has much stronger ACID guarantees than ClickHouse. Which means you get more clear semantics for consistency
40.
by cevian 7y ago
The article covers this in more depth, but the short answer is: The hybrid approach has benefits when your workload has both shallow-and-wide (fetch all data for user X) and deep-and-narrow queries (calculate the average number of logins fo
41.
by cevian 7y ago
Hey Timescale engineer here. Happy to answer any questions.
42.
by cevian 7y ago
In practice this doesn't come up a lot. Say you have a hypertable with measurement(time, device_id, value) and a device table with (device_id, device_manufacturer, device_type). Timescale fully support a foreign-key from the measuremen
43.
by cevian 7y ago
Well as far as I understand, temporal tables usually have either a valid time or system time. TimescaleDB is geared towards something you'd call measurement time, and most modifications are inserts to recent measurement time. In contra
44.
by cevian 7y ago
[Timescaledb engineer here] We like to say that time-series data is any data that is insert-mostly with data associated with the most recent time period. That's a pretty broad definition, intentionally so. We see usage in telecoms, hea
45.
by cevian 7y ago
We have a tool to migrate from Influx. https://docs.timescale.com/v1.3/tutorials/outflux
46.
by cevian 7y ago
Clarification: this license is only for Community and Enterprise Features that live in the `tsl` subdirectory. The vast majority of our code (everything not under `tsl`) is licensed under Apache 2.
47.
by cevian 7y ago
(TimescaleDB engineer here) There are major feature and capabilities available in TimescaleDB that are not available in pg_partman. On the query side we implement a whole bunch of planner and execution time optimizations that don't com
48.
by cevian 8y ago
This seems like it could fit well with TimescaleDB but obviously would take testing. My only concern would be with Full-text search on JSON which I think is possible but I have never done. I would start with a timescaleDB hypertable on the
49.
by cevian 8y ago
In addition to JSON support we also support EAV type schemas which look like: - time | metric_name | value - or time | metric_id | value - or time | tags_id | value where the tags table contain normalized tags and metric names
50.
by cevian 8y ago
While it's true column stores perform better on single-column aggregates, they perform worse on multi-column operations, thresholding queries, and other types of complex analytics that one often sees on time-series workloads. We have p
51.
by cevian 8y ago
Yes TimescaleDB handles event data. I'd need more information about the exact nature of your queries to really give a good answer but there are multiple possible designs here: - keep the event as a json object and use a GIN index (this
52.
by cevian 8y ago
Thanks for trying out TimescaleDB. Glad you're having a good experience. :) We think that declarative partitioning is a great step forward for Postgres partitioning. That said the process is still quite manual (including in PG11) -- un
53.
by cevian 8y ago
The latter. Because of the table partitioning there is not much dependency between old and new data so we've seen consistent performance as you add more and more data.
54.
by cevian 8y ago
To put a number on this claim. TimescaleDB at this point can handle up to 100 TB of data.
55.
by cevian 8y ago
(Timescale engineer here) We are an extension on top of Postgres and not a whole new DBMS. That means that we inherit a lot of the reliability / stability of Postgres (critically we do not change the WAL/data on disk format which
56.
by cevian 8y ago
I believe what akulkarni meant to talk about is relation accesses (and not just locks). While the partition pruning certainly improved things, two sources of inefficiency still remain in PG 11: 1) Fetching statistics for each table during q
57.
by cevian 8y ago
From kdb+ license agreement: "1.4 Kdb+ Software Evaluations. End User shall not distribute or otherwise make available to any third party any report regarding the performance of the Kdb+ Software, Kdb+ Software benchmarks or any inform
58.
by cevian 9y ago
Postgres has great support for non-sharded HA.
59.
by cevian 9y ago
The issue for an operational workload like this with Clickhouse might be the lack of direct support for UPDATE and DELETE. The workarounds required would add additional complexity, I think.
60.
by cevian 9y ago
Clickhouse is very cool. But note that it does not support transactional and relational semantics and does not have real-time updates or deletes. Thus, its meant for very different applications than TimescaleDB. I would classify Clickhouse

More ›