Why is seperate Write and Read better?

Question

I can't understand why separate write and read is better than write and read in one server.

For example, I have a mysql cluster with three machines: node1, node2,node3.

One possible architecture is:

All write requests to node1, but all read requests to node2 and node3.

The second possible architecture is:

All of these three nodes handle both writes and reads.

We can see in architecture one that the write to node1 pressure very huge, so I prefer architecture two.

Also, why does mongodb separates writes to primary node and reads to secondary nodes.

It's important to note that MongoDB does not separate write ands reads to primary and secondary nodes unless you tell it to with SlaveOK or another read preference. By default the primary will handle both reads and writes. — Andre de Frere
@AndredeFrere If I wanna dump all of the database,what address should I use,i.e mongodump --host mongosServer:port or mongodump --host mongoDServer:port if I indicate a mongoD I would not dump all of the data and I don't know if indicate mongoS is right thanks in advance — Jack
probably not the best place for this, but backing up from both mongod and mongos are viable strategies depending on the case. Check here and here for more details. — Andre de Frere
A strange phenomenon:I use java client read the mongodb cluster,found all reads on secondary node(using mongostat checked),but when I login the secondary node,it tells me:not master and slaveok=false So I'm very strange why all the reads on this secondary,but I can't on the command line query. — Jack
The read preference is set on the connection. Your Java app may have this read preference set, but connecting to the shell is a new connection and would not have the same settings as your java app necessarily. — Andre de Frere

Mark Cohen Mark Cohen · Accepted Answer · 2012-09-05T03:27:50

This is an issue of scale for both MySQL and MongoDB. In the simplest application with a small dataset and low traffic volume, having all writes and reads go to one server gives you a simple architecture. In a very high volume read application with low volume writes, a single write node replicating to more than one read nodes gives you the ability to scale your reads just by adding another node. In a high read AND write volume application you might consider sharding (in MySQL you do it yourself or find a tool to help), in mongodb you run mongos that handles sharding for you. Sharding will put records on a specific instance based on some key that you define. The key will determine the instance each record should be stored on. You can imagine that sharding would be more complicated to manage than a single server for read/write access. You would be right, even in a case like mongodb that does the sharding for you once you define a key (or just use the default key).

Why is seperate Write and Read better?

2 Answers