[unoti]

> when you say distribute the database to 50 servers all these are shards, correct?

Yes, these are separate server instances that are essentially separate from each other. All of the records for a given user live on a single particular server. Although MySQL doesn't do this kind of partitioning inherently, this kind of partitioning can be implemented in the application.

[tehbeard]

Is there a write up somewhere on how you handled cross database transactions? E.g. Bob on db#12 gifts Alice on db#23 a "MegaPlushie(tm)"item?

Interested to know how you'd avoid duplicates and lost transactions while maintaining a comfortable level of performance/latency for an online game.

[voxic11]

With mysql this can be handled via XA transactions https://dev.mysql.com/doc/refman/8.0/en/xa.html

[MuffinFlavored]

would be cool if there was a free open source program that did this well written once so we could all benefit from it

[20after4]

It's not something that you can easily abstract away from the application's concerns without a significant performance penalty. For the most basic CRUD operations, an ORM could probably do a decent job. Surely someone has already written an ORM that supports sharding?

Beyond CRUD, I'm not so sure, and any application that's big enough to use sharding probably has some pretty complicated queries. At that point you really don't want to be depending on a library to handle the low level details. You need to think about the performance implications of the access patterns and the trade-offs inherent in different design choices. If a library makes these choices for you then you are unlikely to get optimal results.

[sanjayio]

There’s Vitess that’s been mentioned on HN a lot recently. https://vitess.io/