ryanbooz

6 ms·

1.
by ryanbooz 3y ago
The team at Tembo keeps working quickly to enable many different use cases with Postgres and extensions. Pretty fun example of how capable Postgres is for various tasks.
2.
Yeeting over 30k messages per second on Postgres with Tembo MQ(tembo.io)
14 points by ryanbooz 3y ago|7 comments
3.
by ryanbooz 4y ago
Totally agree. Time is a primary component, but it might not always be the primary query parameter... at least once the data is aggregated. In the example you gave, I'd assume that you wouldn't run a query over billions of transac
4.
by ryanbooz 4y ago
(NB - post author) Great definition! Having worked for years on both energy and IoT applications, the argument here is that your "monthly sales data" is likely being aggregated from your time-series data (sales transactions over t
5.
by ryanbooz 4y ago
(NB - post author) In a sense, it is. Continuous aggregates only have to materialize the most recent bucket of time, not the entire materialized view as you have to in PostgreSQL. That's honestly hard to demonstrate and quantify in a b
6.
by ryanbooz 4y ago
(NB - blog author/Timescale employee) One thing we're improving as we move forward in documentation and other areas is explaining why doing joins (and things like window functions) is difficult in continuous aggregates and not the
7.
by ryanbooz 4y ago
(blog author) Thanks for the feedback! Out of curiosity, if the data you're trying to analyze doesn't have time as one of the critical components, what kind of data is it? Always helpful to learn a bit more.
8.
by ryanbooz 5y ago
Timescale DevRel here! Great observations around how popular and useful it is for systems to have some level of Postgres line compatibility! Thanks for doing the writeup! One thing that's not totally clear in the comparison table is th
9.
by ryanbooz 5y ago
Heh - somehow missed that I had already responded to this one, my apologies. (and no immediate way to edit after the fact).
10.
by ryanbooz 5y ago
Thanks for your excellent contribution to this discussion. As the post author I wholly agree with your approach: if a solution hits the sweet spot for you in the context of your requirements that's the one you choose. Thank you for con
11.
by ryanbooz 5y ago
You are correct. The current multi-node deployment (if you need it for your workload) does have one "managing" access node. All ANs and DNs can be replicated and configured with tooling such as patroni for HA. We have a few users
12.
by ryanbooz 5y ago
(post author) Thanks for the great, thoughtful feedback. We (Timescale) couldn't agree more that there is a lot to love about ClickHouse, especially where it truly excels. Information like this is helpful for others currently in the &q
13.
by ryanbooz 5y ago
Looks like you edited this with some more detail, so I'll answer higher. Compression in TimescaleDB used to mean all compressed data was immutable and the table schema couldn't be altered. Since TimescaleDB 2.1, and 2.3 that has c
14.
by ryanbooz 5y ago
In it's current form/state, ClickHouse is not optimized for typical JOIN-type queries, a point we make in the post. You would have to re-write your statement to get better performance. The other main point is that all data is &quo
15.
by ryanbooz 5y ago
1) you're absolutely right. 5k rows isn't "large". We also mentioned that we did hundreds of tests often going between 5k and 15k rows/batch. The overall ingest/query cycle didn't change dramatically in an
16.
by ryanbooz 5y ago
Sure, these tests were not using really large batch sizes because of the other benchmarks we were trying to replicate (but with more detail). Honestly, for this single instance setup, we saw improvement in CH when we went from (say) 5k, 10k
17.
by ryanbooz 5y ago
Great question. Yes, eventually it does, but (at least for now) it wasn't something we could reliably force as part of the query cycle and know everything was in it's "best" state with ClickHouse. To be honest, we didn&#
18.
by ryanbooz 5y ago
(post author and Timescaler) What do you mean by "migrating old data"? Don't want to make assumptions before answering further.
19.
by ryanbooz 5y ago
(post author) You do a great job summarizing some of the benefits of ClickHouse we mentioned in the post, including the vectorized engine! That said, I'm not sure I'd refer to PostgreSQL/TimescaleDB engine architecture as res
20.
by ryanbooz 5y ago
Yep - it's all detailed in the post! The question is how it compares to TimescaleDB, which is an OLTP time-series database that has a lot of other possible use cases (and extensibility). I think it's very fair to explore how small
21.
by ryanbooz 5y ago
Two quick responses: - The code that TSBS uses was contributed by Altinity[1]. If there is a better setup, please feel free to submit a PR. As stated elsewhere, we did have a former CH engineer review and even updated ClickHouse to the newe
22.
by ryanbooz 5y ago
Sure. As we shared in the blog post it was tested (like other benchmarks) on dedicated EC2 instances using the freely available Community version.
23.
by ryanbooz 5y ago
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 fo
24.
by ryanbooz 5y ago
(post author) Those are great, impressive numbers. We certainly don't claim to be all things to all people, but the benchmark was run using single instances mostly because that is what most other benchmarks published by others have don
25.
by ryanbooz 5y ago
Gotcha! My apologies for not seeing the thread nature. HN threads get me sometimes. :-)
26.
by ryanbooz 5y ago
Indeed. Lots of discussion over this in the last few months. There are nuances, but I think you'll see some progress in this area over the next year.
27.
by ryanbooz 5y ago
(Post author) The two big things, which we discuss at length in the post, are: - Altinity (and others) did not enable compression in TimescaleDB (which converts data into columnar storage) and provides improvement in querying historical dat
28.
by ryanbooz 5y ago
(Post author) Howdy! All of the details about our TSBS settings in the performance section of the docs. Also, we'll be streaming a sample benchmark of the two databases next Wednesday at 10AM ET/4PM CET. https://blog.ti
29.
by ryanbooz 5y ago
There's a long list of DBs users would like to see. Druid is on the list but probably not happening in the near-term without some community help. Remember, TSBS is open-source and we've had some great contributions from many teams
30.
by ryanbooz 5y ago
(Post author) Howdy! We provided all of those details in the post and you're welcome to join us next week when we live-stream our setup and test! https://blog.timescale.com/blog/what-is-clickhouse-how-does-...

More ›