Posted on

Scaling and hardware selection – reasons

Gained some interesting insight earlier this week at the SUN/MySQL APAC eHorizons event. A key thread in my (business track) session was that a) databases are not interchangable, and b) you plan for growth. If you don’t, you can’t grow, and your business might end (or at least be in serious pain).

For instance, if you build an application but don’t put application logic into place that deals with separate master/slave connections (even if they talk to the same server for starters!) is a bad idea. It’s a pain to fix up later, and sometimes it’s just impossible (better believe it, I have helped customers who struggle wish exactly this issue). Not all reads should go to slaves, sometimes you need absolute up-to date info from the master. So the logic is not quite as simple as “all selects to the slaves”….

Hardware selection is a result of all kinds of architectural choices, and again has to be geared for the future. Sometimes companies acquire hardware first, and then discuss application architecture. Sorry, wrong order. Or when encountering scaling issues, they order big chunky hardware first and then call me. Nice bigger master server(s) can make perfect sense, and good commodity hardware slave systems. That’s just general logic, details really do differ per situation.

Now the insight. My client’s client wanted the hardware selection based on energy footprint in the data center. The choice went to SUN T2 based systems, which have 8 cores, each with 8 execution paths. So they say “hi I have 64 cores” to the operating system.

From talking with Peter Zaitsev I understand that the CPUs themselves are not that fast (single thread), so the power comes from the numbers under multithreading. Good for MySQL, overall, when it deals with regular queries on many connections. Just need to mind things like ALTER TABLE and other operations which are essentially single threaded. Diddums for long-running queries (reporting).
For deployment, the most efficient solution will likely be having a few MySQL servers running on the same box, i.e. a master and a few slaves. That way some of the contention with single threaded operations is mitigated.
As with many of these things, “Try it And See” is the way, and so we will.

Anyway, the interesting take-away from this is that energy footprint is now also a factor when selecting hardware infrastructure. It makes sense, and in this case it should work out fine. There are multiple physical servers so there is redundany even with slaves sharing the same box with a master.

Posted on