101–110 of 184 posts
https://altinity.com/blog/2019/7/new-encodings-to-improve-cl...
In particularly low_cardinality() for strings and time series specific compression many be very valuable
We've got a few billion rows in TSDB, pretty happy with it so far. Our workload fits the OLTP workflow more than OLAP though, we're processing / analyzing individual data points from IoT devices as they come in, and then providing various visualizations. This tends to mean that we're doing lots of fetches to relatively small subsets of the data at a time, vs trying to compute summaries of large subsets. Compression i…
Does this effect your query performance ?
It would be awesome to combine the following things: * PostGIS * Timescale * Citus * Zedstore This truly would be the relational DB to end all relational DBs. Unfortunately, we run into a couple problems: * Managing multiple extensions is a burdensome task, which should be in the wheelhouse of cloud providers, but... * Timescale and Citus are are open core, holding back features for customers. Their primary revenue c…
Regarding distributed (Citus) and columnar (Zedstore):
- TimescaleDB's compression actually takes a columnar approach (including that it only reads the individual compressed columns that you SELECT), and so combines both row- and column-oriented data. [0]
- TimescaleDB 2.0 also supports distributed deployment, and Timescale Cloud will (very soon) offer one-click deployment of fully-managed multi-node TimescaleDB. [1]
[0] https://blog.timescale.com/blog/building-columnar-compressio...
[1] https://blog.timescale.com/blog/building-a-distributed-time-...
That’s a really thorough comparison. Much more detailed than I expected. From what I see, the trade off in disk space usage would point me toward Timescale for most of my workloads. The insert performance tradeoff just wouldn’t justify the difference for me.
Does the disk usage go down later once the numerous parts are merged or not? I would assume it does but reading the article implies that it does not.
How much you save is again exactly the same as when dealing directly with files: it depends on the data and on the compression algo.
Earlier quoted context omitted.
Hello @PeterZaitsev! Actually Altinity is the one that contributed the bits to TSBS for benchmarking ClickHouse[1], so we are using the work that they contributed (and anyone is welcome to make a PR for updates or changes). We also had a former ClickHouse engineer look at the setup to verify it matched best practices with how CH is currently designed, given the TSBS dataset. As for the optimizations in the article yo…
Thank you for your prompt response! I think the most important thing is Clickhouse is NOT designed for small batch insertion, if you need to do 1000s of Inserts/sec you do queue in front of clickhouse. And query speed can be impacted by batch side a lot. So have you looked at query performance with optimal batch size ?
https://blog.timescale.com/blog/what-is-clickhouse-how-does-...
Our anecdata: we store telemetry per thing. After loading a month worth of data - timescaldb as hosted by their cloud ran a difference aggregation in seconds. Clickhouse routinely did it in 20 millis. Simple avg, etc were better, but always clickhouse was an order of magnitude faster than timescale. We didn't invest a whole bunch into optimization other than trying some indexing strategies in timescaledb. So for our…
From what I can tell it comes down to execution engine differences. TimeScale, even with compressed tables, uses a row by row execution engine architecturally resembling IE6 era JS engines. ClickHouse uses a batched and vectorized execution engine utilizing SIMD. Difference is one to two orders of magnitude of throughput in terms raw number of rows per core pushed through the execution engine.
Postgres/TimeScale could certainly also implement a similar model of execution, but to call it an undertaking would be an understatement considering the breadth and extensibility of features that the execution engine would need to support. To my knowledge no one is seriously working on this outside of limited capability hacks like vops or PG-Strom extensions.
It would be awesome to combine the following things: * PostGIS * Timescale * Citus * Zedstore This truly would be the relational DB to end all relational DBs. Unfortunately, we run into a couple problems: * Managing multiple extensions is a burdensome task, which should be in the wheelhouse of cloud providers, but... * Timescale and Citus are are open core, holding back features for customers. Their primary revenue c…
One clarification. While TimescaleDB is open-core, our community version is source-available and 100% free to use. We do not "hold back features for customers". You do not need to pay to use any of TimescaleDB's best features, it's all free via the Timescale Community license.
You only pay if you'd like to use our hosted offerings (and save the hassle of self-managing your DB): Timescale Cloud or Managed Service for TimescaleDB.
For more see: https://www.timescale.com/products
(Disclaimer: I work at Timescale)
Earlier quoted context omitted.
Sure. As we shared in the blog post it was tested (like other benchmarks) on dedicated EC2 instances using the freely available Community version.
This does not answer the question - is it Open Source License or Source Available (TSL) https://www.timescale.com/legal/licenses
> Versions: TimescaleDB version 2.4.0, community edition, with PostgreSQL 13
and the link you posted explains that it's the non OSI license version:
> TimescaleDB Community is made available under the Timescale License ("TSL")
* Create a setup which is production grade i.e. run a multi-node HA setup of those systems.
* Understand the best practices of those systems otherwise result gets biased.
* Validate the results with experts of those systems before publishing.