ople (u/ople) - Readit News

ople commented on ClickHouse 25.6: CoalescingMergeTree table engine clickhouse.com/blog/click... · Posted by u/samaysharma

ople · a month ago

This is a cool and underrated new feature: It basically enables simple joins of large and dynamically updated tables efficiently. This is something that has been a bit of an Achilles heel of ClickHouse, at least for me so it's exciting to see.

That said, it's not a solution for all kinds of joins, but probably covers the most common use case for most people.

ople commented on Some notes on Grafana Loki's new "structured metadata" utcc.utoronto.ca/~cks/spa... · Posted by u/valyala

jakozaur · 6 months ago

There is an effort in OpenTelemetry to create a standard query language for observability. There were a lot of discussions with a lot of opinions; there were even several talks during KubeConEU about that:

https://sched.co/1tcyx

https://sched.co/1txI1

We are still waiting for a compelling implementation that will show the way.

ople · 6 months ago

Why not just use SQL? With LLMs evolving to do sophisticated text-to-SQL, the case for a custom language for the sake of simplicity is diminishing.

I think that expressiveness, performance and level of fluency by base language models (i.e. the amount of examples in training set) are the key differentiators for query languages in the future. SQL ticks all those boxes.

ople commented on Unraveling the Mystery of Idle Threads in ClickHouse altinity.com/blog/unravel... · Posted by u/hodgesrm

ople · a year ago

This is one of the things I appreciate about ClickHouse: Contributors willing and able to dive in to performance tune even low-level core stuff like this and getting merged quickly and efficiently, even if they are not affiliated with ClickHouse Inc.

Lovely write-up as well!

ople commented on Show HN: LogsQL – opinionated query language for logs docs.victoriametrics.com/... · Posted by u/valyala

valyala · a year ago

Diversity is great! Let's see which query language for logs will survive.

ople · a year ago

True. My bet is that arbitrary text queries converted to SQL via LLM will become an increasingly popular alternative. Not sure if it will completely replace the custom query languages though..

ople commented on Show HN: LogsQL – opinionated query language for logs docs.victoriametrics.com/... · Posted by u/valyala

ople · a year ago

Recently there seems to be an bunch of SPL (Splunk) -like query languages popping up: PQL, PRQL, Grafana Explore Logs syntax, Kusto.. Probably others as well. Does yet another similar but slightly different language make sense? Why not leverage an existing one?

ople commented on Optimizing ClickHouse: Tactics that worked for us highlight.io/blog/lw5-cli... · Posted by u/podoman

ople · a year ago

Very interesting observations! Merge performance tuning seems often overlooked even though it's a key aspect of sustained ClickHouse performance.

I also like that the blog is quite compact and gets the points across without getting too much into the weeds.

One thing I've noticed also that bloom filter index types can be quite costly to merge. In many cases that's acceptable though due to the massive benefit they provide for text queries. One just has to be mindful of the overhead when adding them.

ople commented on Reducing BigQuery Costs blog.peerdb.io/reducing-b... · Posted by u/cauchyk

jojobas · 2 years ago

So far the best solution I've seen to save on BigQuery costs is to deploy your own ClickHouse.

It has its own gotchas and quirks, but cost-wise it's not even comparable.

ople · 2 years ago

I have had the same experience. I was constantly bumping into unexpected limitations. Moving to CH felt like the opposite, with many more ”Wow, I didn’t expect this to be possible but it is” experiences.

There is a place for BQ but it is good to set expectations correctly and also look at the constraints. They are sometimes not obvious. The docs do helpfully outline the limitations, for example:

- Materialized views: https://cloud.google.com/bigquery/docs/materialized-views-in... - Indexes: https://cloud.google.com/bigquery/docs/search-intro#limitati...

ople commented on InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion community.influxdata.com/... · Posted by u/PaulAA

physicles · 2 years ago

I’ve been self-hosting InfluxDB in the hundreds of GB range for several years. I wouldn’t say I’m super happy with it, but… let’s say we’ve reached an understanding, the software and I. We’re on the latest patch of 1.8 and content to stay there.

I agree with GP about storage efficiency, which is superb. Query performance is good as long as a single query doesn’t deal with more than ~dozens of series. And $deity help you if you want to do hourly roll-ups of all series for a short time range, as RAM usage is wildly unpredictable. Storage is optimized for long reads of a single series, not for short reads of many series (but in fairness, you have to choose one or the other, that’s just the physics of the thing).

If I were starting from scratch, I’d probably pick Timescale. Or maybe DuckDB… I wonder if it would work for our use case.

ople · 2 years ago

I have pretty much exactly the same experience.

However, I do feel that they are trying to really do the right thing with the new 3.0 architecture, addressing the deficiencies (most importantly performance and full-fledged SQL) while keeping the stuff that works (InfluxQL for simple and legacy queries). Also leveraging open-source projects and contributing to their upstream is a plus. Thus I’m hoping for them to succeed delivering on that promise.