3 ms·
but it's still utterly infeasible for high traffic web applications because of the replication issue Sorry, but what a nonsense. High traffic sites scale by c
by moe 18y ago
but it's still utterly infeasible for high traffic web applications because of the replication issue
Sorry, but what a nonsense.
High traffic sites scale by caching, sharding and non-relational databases, in that order.
Replication can, at best, be an intermediate kludge for read-heavy websites that haven't learned about caching (wink) or insist on abusing their RDBMS as a fulltext search engine.
It was also commonly used as an incremental backup solution until filesystem snapshots became commonplace.
- aditya 18y agoI think having multiple read slaves (and even write masters) is a perfectly acceptable way of distributing load, and in turn, scaling. To completely ignore that sounds foolish. EDIT: xzilla is right, I wasn't really recommending blindly adding write masters since that wouldn't work, but just that read slaves are not a bad idea. :)
- xzilla 18y agoAnyone who thinks you can scale writes by adding more masters is plain ignorant on the subject. The only way to scale writes is with better hardware or federation of application/data. The first of those is easy, the latter is hard.
- moe 18y agoWell, I have never seen a read-slave setup in a webapp for the purpose of scalability that would've made a lot of sense. It's a sometimes a stopgap measure when money is cheaper than time, but will come back to haunt you later. When your reads are starving in a webapp then you should look into fragment caching and content-generation but not much further. If that doesn't solve your problem then you're just very likely doing something fundamentally wrong and better go ask someone smarter.
- tobi 18y agoReplication has nothing to do with scalability in most cases. Replication is how you reduce downtime! It's the same reason why Raid5 is more then useless in a web server - if a disk dies it has to reboot and has to reconstruct data for hours. You cannot have downtime in a web application. This is of course slightly domain specific. We host several thousand e-commerce stores that are the livelihood of our clients. If we are down then no one can earn money. Shopify being down is a lot worse then twitter being down. In fact we may even see legal action if our downtime is too bad. The reason why you need replication is because you need 3+ 100% accurate and up to the second copies of your database which can take over at a moments notice. One single server, no matter how beefy it is, can never accomplish this. Someone is going to trip over it's power cords eventually ( and if it has two then someone is going to trip over the power cord of the network switch it's connected to ).
- wmf 18y agoReplication is how you reduce downtime! It's one possible way. It's the same reason why Raid5 is more then useless in a web server - if a disk dies it has to reboot and has to reconstruct data for hours. Clearly you're using the wrong RAID; the whole point is to keep going after a disk failure. you need 3+ 100% accurate and up to the second copies of your database which can take over at a moments notice. One single server, no matter how beefy it is, can never accomplish this. An alternative would be a single reliable copy of the database (using RAID, redundant controllers, and multipathing) attached to multiple servers. I suppose database replication is mighty attractive if you assume that disks have to be trapped inside servers.