

How to Avoid the Top 5 Scale-Out Pitfalls - datums
http://www.mysql.com/why-mysql/scaleout/scaleout_pitfalls.html

======
kakooljay
See: [http://www.mysql.com/why-
mysql/scaleout/scaleout_pitfalls.ht...](http://www.mysql.com/why-
mysql/scaleout/scaleout_pitfalls.html)

~~~
mmt
_2\. Don't Think Vertically_

 _It's a mistake to think that a system can be grown by scaling vertically,
that is, by buying bigger machines with more CPUs. Throwing more power at an
existing implementation -- which is probably synchronous and most likely
already suffering from lock waits -- is only going to make it 'wait faster'.
By planning for horizontal scale-out, almost from the start, a business is
already planning in the direction of distributed, asynchronous systems, which
will make it easier to add more capacity later on._

Therein lies what I consider to be MySQL's greatest "scale out" failing:
locking implementation. It also hints at its second-greatest failing in this
context, being parallelism implementation, leading to CPU being a limiting
factor.

Scaling "horizontally" is extremely expensive, if vertical scaling is still
possible. For example, a $1k server might hold 6 spindles, while a $1k storage
array holds 24. The situation with CPU and memory isn't quite as extreme, but
it still tends to hold. It also limits one to network (rather than internal
bus) latencies and bandwidth.

