Database Reference
In-Depth Information
As our chat system has more or less a 1:1 ratio of writes and reads, moving reads to
a separate server will buy us nothing. The replication itself is more expensive than
the possible win from reading from a second server.
Multimaster replication
Multi-master replication is even worse than master-slave(s) when the problem is
scaling a write-heavy workload. It has all the problems of master-slave, plus it intro-
duces extra load via cross-partition locking or conflict resolution requirements, which
further slows down the whole cluster.
Data partitioning across multiple servers
The obvious solution to scaling writes is to split them between several servers.
Ideally you could have, for example, four servers and each of them getting exactly
¼th of the load.
In this case, each server would hold a quarter of users and messages, and serve a
quarter of all requests.
To make the change transparent for database clients, we introduce a layer of proxy
databases. These proxy databases can either reside on the same hosts as the parti-
tion databases or be on their own host. The role of the proxy databases is to pretend
