Friday, July 15
Listens to developer explaining how MySQL is no good for really large databases, like, over 100MB.
Looks at 6TB MySQL production database handling several thousand transactions per second.*
It's pretty obvious he's got broken joins. The advantage we had back in the good old days was that rather than taking several seconds to return your data, it would take several weeks, and you could hear the drive heads thrashing about while it happened, so it was kind of obvious that you'd screwed up.
I've seen far too many programs where someone has failed to realise that the half a second or so that a function takes is because they've got it completely wrong, and it should be taking milliseconds or even microseconds. Send them all back to 1985, I say. Here's your Unix box. We just upgraded it: It now has two megabytes of RAM!
* Mind you, it's not easy to get MySQL to scale that big on a single server. But 100GB is perfectly manageable, and that's a thousand times what this guy was talking about.
In fact, sometimes I've felt the same thing, I just have never managed to phrase it nearly as well.(We've got a service where I work that used to run on a pair of Ultra-1's with 500 MHz of CPU and 500 MB of memory between them, and the developers are now trying to say that the "next generation" is in serious danger of running out of resources on four SunFire 5120s (32 1GHz cores and 12 GB each) PLUS four 8-core 3 GHz 6GB Linux boxes. Admittedly, the new version is shinier feature-wise, but I don't think it's that much shinier)
Posted by: Hypozeuxis at Saturday, July 16 2011 12:19 AM (5eWak)
Posted by: J Greely at Saturday, July 16 2011 01:43 AM (2XtN5)
52 queries taking 0.1798 seconds, 283 records returned.
Powered by Minx 1.1.6c-pink.