

5 Steps To Scaling MongoDB (Or Any DB) In 8 Minutes - matan_a
http://highscalability.com/blog/2011/9/13/must-see-5-steps-to-scaling-mongodb-or-any-db-in-8-minutes.html

======
matan_a
Decent high level points (with a lot of room to add specifics).

First thing is that your data design has a huge impact on everything your
applications do, so getting that right is critical. I would say these points
assume so.

Also I'm not sure i agree with his point that caching your data layer isn't a
good idea. Yes, MongoDB has pretty awesome in-memory performance, but having
dedicated caching servers have numerous advantages like:

\- Allowing you to manipulate the data structures better for use-cases or to
cache preprocessed items (that might not require persistence).

\- Resources. A memcached box doesn't need the type of hardware a MongoDB box
needs so it's easier to increase your global cache size and performance w/o
adding new DB servers or dealing with indexing size vs working set size
voodoo.

\- Specialization. Caches are built and optimized for doing exactly that. Why
would you think your DB code can do it better?

\- Flexibility. I can control my caching lifecycle independently of how my
persisted data changes.

At any rate, i'm enjoying my MongoDB work and it does help a lot for the push
button scaling, but unfortunately, whole _systems_ need to scale, not just the
DB servers so these suggestions won't solve all your problems.

