0

Consider a Database which is being constantly accessed (read,write,update,deletions etc) , for instance the Database for some particular airlines.

I can understand simultaneous writes/updates can lead to a lot of issues, as writes might require a lock . Moreover if too many writes are queued, it might lead to buffer overflow etc. hence the need to replicate (clone or provide multiple access points to the database) arises.

What about many reads. Can multiple simultaneous read requests (request to get some data from DB) lead to any issues aside from slowing down access to the DB ? If my database will seldom be updated but frequently accessed to read data ONLY does replicating it make sense ?

1 Answer 1

1

Lots of big databases where most of the activity comprises reads replicate and then load balance off the read databases.

There are a few gotchas, but this does work well if correctly set up. (One of the gotchas is reads which also update a field as part of the read).

Another gotcha is consistency - if some writes span multiple tables, during the short period where not everything is written, you may get undesireable results and errors when doing a read from one of the replicated databases - particularly if replication is done such that different tables are mirrored to different machines or there is a burst of activity.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .