a database noob question, when you say distribute the database to 50 servers all these are shards, correct? MySQL (or any standard RDBMS) can't span more than one server, correct ?
> 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.
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.
Sharding is when you store your tables, or parts of tables, on other machines, so that queries are executed by the resources of those remote machines.
Read-only replication stores a copy of the whole database on other machines, so that any query which doesn't write can be handled by asking the remote machine. Writes are bottlenecked through the primary machine, which then sends changes to the remotes.
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.