Sort is working! Another suggestion is to allow the user to edit the DNS resolver list -- in the running program itself. An ADD/DELETE feature would be useful (to me at least).
A quick note... when I open the app I only see the left pane. I wouldn't have known there was a map had I not previously seen/read about it.
That's what the tool is doing - querying a bunch of public resolvers around the world to see the state of what they resolve to. Since end users usually use DNS servers close to their location, this gives an idea, around the world, of who sees what.
Agreed, this is a cache that expires and refreshes from the source DNS server. It just looks like a virus that propagates when the cache expires.
> It just looks like a virus that propagates when the cache expires.
No it does not. The changes do not happen geographically. There is no geographical connection whatsoever. Calling the tool “DNSGlobe”, and displaying a map, only further reinforces the myth.
We went from the get go to that infrastructure for multiple reasons in the first place:
* Having a durable buffer before ensures if you have big spikes that gets eaten by the buffer, not OLAP which when it is powering your online dashboard you want to keep responsive. Clickhouse cloud now has compute/compute that addresses that but open source users' don't.
* When we shipped this for the first time, clickhouse did not have the async buffering in place, so not doing some kind of buffered inserts was forwned upon.
* As oatsandsugar mentioned, since them we also shipped direct insert where you don't need a kafka buffer if you don't want it
* From an architecture standpoint, with that architecture you can have multiple consumers
* Finally, having kafka enables having streaming function written in your favorite language vs using SQL. Definitely will be less performance to task ratio, but depending on the task might be faster to setup or even you can do things you couldn't directly in the database.
> Clickhouse cloud now has compute/compute that addresses that but open source users' don't.
Altinity is addressing this with Project Antalya builds. We have extended open source ClickHouse with stateless swarm clusters to scale queries on shared Iceberg tables.
The durability and transformation reasons are definitely more compelling, but the article doesn’t mention those reasons.
It’s mainly focused on the insert batching which is why I was drawing attention to async_insert.
I think it’s worth highlighting the incremental transformation that CH can do via the materialised views too. That can often replace the need for a full blown streaming transformation pipelines too.
IMO, I think you can get a surprising distance with “just” a ClickHouse instance these days. I’d definitely be interested in articles that talk about where that threshold is no longer met!
