orhanhh

I tested clusters with between 3 and 12 nodes, and the differences were similar for the different sizes. I’m not sure how it performs for larger clusters than that though. Additionally, the results might have been a bit misleading on the large clusters because of the low scale factor, leading to higher contention on some rows.

I used oltpbenchmark and ran automated tests on hetzner cloud using Terraform and some automation scripts. The comparisons are based on the YCSB workloads executed by oltpbenchmark.

I recently benchmarked TiDB (pre 4.0), CockroachDB and YugabyteDB. TiDB outperformed the others for write throughout and latency, probably because it has a bit weaker isolation guarantees (snapshot vs serializable). However, for all read operations, CockroachDB performed significantly better than TiDB. It would be interesting to do a new comparison with version 4.0, as it seems from this article that they have improved performance quite a bit.

Do you think these are counted differently? TV viewers statistics often use average number of people in a household, iirc. I would guess the HBO number is just the actual number of plays, no matter how many people viewed on that screen.

Note that neither CockroachDB or TiDB use Golang for their actual storage engine, which is in both cases written in C (RocksDB). They do use Golang for SQL parsing though, which is what this post was mostly about.

I assume they are able to target these users with advertisements (by paying Facebook money..)

I use Arq on two macs and it works very well with B2.

For downloading the data there is an option to download "Ads and Businesses" under "Information About You". I just downloaded it, and it includes all data that was shared.

However, the data only shows the source, timestamp and activity ID. The actual event data is not included..

How do you suggest one configures Redis to avoid this kind of possible data loss while maintaining throughput? I think when enabling replication, users will assume that recent writes are safe. This bug or whatever you want to call it, seems to allow data to be unsafe as long as the high load persists.

Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD.

It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.