How would I implement separate databases for reading and writing operations?

Matt picture Matt · May 26, 2010 · Viewed 11.8k times · Source

I am interested in implementing an architecture that has two databases one for read operations and the other for writes. I have never implemented something like this and have always built single database, highly normalised systems so I am not quite sure where to begin. I have a few parts to this question.

1. What would be a good resource to find out more about this architecture?
2. Is it just a question of replicating between two identical schemas, or would your schemas differ depending on the operations, would normalisation vary too?
3. How do you insure that data written to one database is immediately available for reading from the second?


Any further help, tips, resources would be appreciated. Thanks.

EDIT
After some research I have found this article which I found very informative for those interested..

http://www.codefutures.com/database-sharding/

I found this highscalability article very informative

Answer

Pascal Thivent picture Pascal Thivent · May 26, 2010

I'm not a specialist but the read/write master database and read-only slaves pattern is a "common" pattern, especially for big applications doing mostly read accesses or data warehouses:

  • it allows to scale (you add more read-only slaves if required)
  • it allows to tune the databases differently (for either efficient reads or efficient writes)

What would be a good resource to find out more about this architecture?

There are good resources available on the Internet. For example:

Is it just a question of replicating between two identical schemas, or would your schemas differ depending on the operations, would normalisation vary too?

I'm not sure - I'm eager to read answers from experts - but I think the schemas are identical in traditional replication scenari (the tuning may be different though). Maybe people are doing more exotic things but I wonder if they rely on database replication in that case, it sounds more like "real-time ETL".

How do you insure that data written to one database is immediately available for reading from the second?

I guess you would need synchronous replication for that (which is of course slower than asynchronous). While some databases do support this mode, not all do AFAIK. But have a look at this answer or this one for SQL Server.