Jeremy has a great post about why DHH’s article on Sharding is….dumb, i mean flawed.
If you’re a startup, and think you’re about to experience tremendous growth, listen to Jeremy, not DHH. I’ll let Jeremy and the other tech heavy hitters handle the technical flaws with his article.
I’m not sure about his definition of “reasonable” is, but I can’t find a single system with 128GB of RAM within my definition of “reasonable”. Secondly, the whole notion that bigger/better/faster is the solution is absurd. That’s like saying we need a bigger land fill because the one we have currently is full. Sure, that’ll work, but how do you install said landfill into place? do you dig under the current one? do you use “bolt on” land fills?
DHH completely misses the purpose of sharding in my opinion. It’s not just about the load and distribution of reads/writes for mysql, but the organizational benefits are invaluable. I’ve been using some form of sharding for the past 5 years, and it’s helped me considerably. The drawbacks he’s mentioned, can also be a benefit. The number of times I’ve been able to upgrade a certain set of customers without affecting the others, has been invaluable for us, and for the customers. Your entire system doesn’t have to go down just because MySQL doesn’t have online changes yet. We’ve been able to upgrade our system without any noticeable downtime to our customers, because of sharding.
I’m sure he’s right on certain points and situations, but I’d suggest the end user not consider his word as gospel, nor mine, nor Jeremy’s.. your situation is unique, but don’t discard a methodology just because newer/faster hardware is around the corner.
