> We built chproxy specifically because ClickHouse doesn't like thousands of tiny inserts. It's a Go service that buffers events and sends them in large batches. Each Cloudflare Worker would send individual analytics events to chproxy, which would then aggregate and send them to ClickHouse.
While I understand how this isn't the only thing that needed to be buffered, for Clickhouse data specifically I'd be curious why they built a separate service rather than use asynchronous inserts:
FWIW, I'm in a similar situation right now. I was able to massively decrease noise (and air flow) by switching to Noctua NF- A4x10 FLX fans. As long as my workloads aren't sustained temperatures are fine and noise has from gone ~70-80dB to ~40dB, with the power supply fans being the loudest part now.
Note they're comparing to CPython v3.7 and while https://speed.python.org doesn't go back to 3.7, the improvements between 3.8 to 3.12 are pretty massive.
I don't doubt PyPy is faster than CPython, but it would be very interesting to see latest PyPy compared to latest CPython.
I maintain a Brewfile (https://github.com/Homebrew/homebrew-bundle) which contains the majority of the non-project specific applications that I like to install on any new Mac:
What's really nice is the `cask` & `mas` keywords allow you to install .dmg files & directly from the App Store.
---
While its not included in there yet, I've been experimenting with maintaining a private Homebrew tap which contains my ~/bin directory as opposed to shell aliases.
Does anyone know if the performance regressions between 5.7 and 8.0 have been fixed? I no longer use MySQL regularly so I haven't been following this.
If I recall correctly, this was one of the major reasons why people were deferring this upgrade.
---
> Most notably, we encountered a problem where queries with large WHERE IN clauses would crash MySQL. We had large WHERE IN queries containing over tens of thousands of values.
The need to rewrite queries is mildly concerning. If this was part of their Rails codebase, I'm curious if these patches will make it into the ORM.
Calling out limitations like this in the documentation would go a long way in building confidence in the project. Better yet, if there's an example of how to deal with "day-2" operational concerns like this.
Simply looking at the docs on these two pages, its unclear to me whether there's a way to update the mirror definition when a schema change occurs or if I need to drop & recreate the mirror (and what the effects of this are in the destination):
While I understand how this isn't the only thing that needed to be buffered, for Clickhouse data specifically I'd be curious why they built a separate service rather than use asynchronous inserts:
https://clickhouse.com/docs/optimize/asynchronous-inserts