SQL database scaling

Monday, January 11, 2010 , Posted by Johnny Fuery at 2:02 AM

Originally Published 2006-03-21 05:40:15

Warning, this is geeky...

So, DB scalability... there's three basic strategies, right?

(1) Backup often, pray to a deity, and where a pager.
(2) Backup often, keep a warm standby server, and manage duel transaction logs.
(3) Keep a warm standby server and use a storage area network SAN for the actual data storage.

Now, the only drama that comes out of this is the necessary logic surrounding sequencing of your writes -- sets of locked rows or tables and other such things CS PhDs spend their time worrying about. So why doesn't a widget exist for allowing a db engine to run in read-only mode? (Or does this exist already and I just don't know about it?)

For example, you could have two servers -- one that handles all of your write transactions and one that handles reads. You could actually scale a little without getting your hands all dirty with data segmentation (i.e., users 1-1mm are handled by server A, 1mm-2mm by server B, and so on).

You'd probably get 50% more simultaneous transactions handled by an off-the-shelf DB (like, say, mysql) just by adding a little traffic-cop code in front to "load balance" the whole mess.

Currently have 0 comments:

Leave a Reply

Post a Comment