eivanov89

Hi there, I'm the author of the post. I'm happy to answer any questions and appreciate any feedback and experience shared.

I think Denis addressed this in his post: "Overall, as an engineer, you will never regret taking part in the development of a sharding solution. It’s a complex engineering problem with many non-trivial tasks to solve". In other words, it might be not invented here syndrome (with all due respect to Figma team). Or there might be more nuances we are unaware about.

In YDB with block 4+2 erasure coding, you need half the disk space compared to mirror-3-dc schema. Meanwhile CPU usage is just a little bit higher, thus in high throughput tests mirror-3-dc wins. Indeed as mentioned in the post there might be a tail latency win in latency runs, but if your task is throughput with a reasonable latencies, replication might be a better choice.

We plan, but currently we are blocked by this issue: https://github.com/yugabyte/tpcc/issues/147 Thus, we consider either waiting for the improvement or trying running DBMSs in containers.

Absolutely. Both CockroachDB and YDB have replication factor equal to 3. So it's similar to Postgres with 2 sync replicas.

Thank you! Any chance you have a list of favourite benchmarks? Now, we are open for suggestions.

Nice to see this link shared on HN. I'm the post author and I'm glad to answer any questions. Also it would be interesting if you share your approach to the benchmarking, when you have to choose between Postgres and any other DB, especially sharded or distributed.

That's indeed amusing! I just published a post with title "When Postgres is not enough". It seems that the true distributed databases we have evaluated aren't quite Postgres's cup of tea: https://blog.ydb.tech/when-postgres-is-not-enough-performanc...

It's really interesting, that Postgres is extremely efficient, but same time can't scale vertically well enough, when there is synchronous replication. Unlike its distributed counterparts.

There're some proofs, check the https://blog.ydb.tech/ for comparison against CockroachDB and YugabyteDB.

Perhaps we'll give HikariCP a chance. However, please keep in mind that the goal of the YDB team is to enhance database performance. We needed virtual threads to make TPC-C efficient enough to generate a reasonable load on a modest amount of hardware.

Your comparison is indeed thoughtful. I would note a counterexample, though: an expensive restaurant with a very simple description gives no guarantee that you will be delighted, while some inexpensive places (possibly with basic ads) might offer something very delightful.

I would suggest looking at it from another perspective. Writing a text that precicely describes the image you want might require a lot of effort. Crafting this text to get as close as possible to the imagined picture also requires effort. Also, consider that some people can't draw (I also can't sing), but can write. AI gives a nice opportunity to add some color and visual humor, which is, in my humble opinion, great. But no doubt there are many examples of AI misusage (or overusage), which match your description.

Haha, but quite frankly we had one more in TPC-C for YDB. But unrelated to the virtual threads.

I would like to reply with a quote of sir Tony Hoare's 1980 ACM Turing Award Lecture: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies".

There were multiple reasons behind our decision:

1. We firmly believe that achieving superior performance in distributed transactions is impossible without first ensuring strong key-value load performance.

2. As mentioned in our paper, other distributed SQL databases also utilize the YCSB benchmark. You might be interested in the YugabyteDB vs. CockroachDB comparison we referenced.

3. Distributed databases are complex, comprising multiple layers. Though a key-value load is relatively simple to comprehend, it still allows for the performance evaluation of various layers like the transport layer, GRPC, underlying storage, and so forth. We make extensive use of this type of load in our attempts to identify and eliminate different bottlenecks.

We're currently preparing more benchmarks and look forward to sharing our findings soon.

Your feedback is always appreciated!

Author of this post as well as the whole team would appreciate any feedback. We are here to answer any questions.