Comments on: Scaling: Consider both Size and Load

By: Peter Zaitsev

Peter Zaitsev — Wed, 14 Jul 2010 18:11:19 +0000

Thanks Sergey.

Fixed.

By: Sergey

Sergey — Wed, 14 Jul 2010 17:37:14 +0000

Hi,

Typo:
“As your data growths you may frequently find load becoming CPU bound”
– should be “disk I/O bound” or whatever.

By: Peter Zaitsev

Peter Zaitsev — Wed, 14 Jul 2010 17:16:27 +0000

Jestep,

Indeed. Operations add a whole different angle which I have not covered. Certain operations task such as Alter Table become especially bad, not only they may not fit in the “downtime window” allowed by some businesses but they their speed is often disproportionally reduced as data size grows due to less memory fit.

By: Sarah Angel

Sarah Angel — Wed, 14 Jul 2010 06:34:59 +0000

Hi,

I am creating a software program using MySQL?

Where do I host my MySQL database?
What systems do you recommend for placing and operating my database program?

Thank you.
Sarah Angel

By: Jestep

Jestep — Wed, 14 Jul 2010 01:59:46 +0000

One thing not to forget is sheer administration. When your DB is tapped out on resources, an alter table, modifying an index, or even a rarely used query creates prohibiting response times for completion. These can create simply unacceptable delays when trying to properly administer or restore a DB. In my experience administration suffers far before user or application interaction. While I don’t have the magic formula for database resources-to-size, when administering the db becomes ridiculous, planned usage is close to follow. I would say if you ever have to scale, scale to the point that you don’t think you will ever need it (cost allowing of course). Most likely you’ll still find that you didn’t do enough in the long run.