Database Sharding

I discovered a new term today, via a useful post on Julian Dontcheff's Database Blog (which I also discovered today). His post, Do not go beyond this point: on the "obvious advantages" of Database Shards, succinctly describes what database sharding is, and even better, points to three resources for deeper study.  He writes:

Caution! Database Sharding is like the anti-consolidation of databases. It is splitting the database into many small databases. You spend years and years on trying to unify and gather together databases and all of a sudden you are told that there is an application managed scaling technique using hundreds of independent databases. Tricky, right?

Sometimes, when planning database solutions in terms of scalability and massiveness, going beyond a certain point might be risky. This is the case when database shards may be of huge help (big website used globally). The word shard may sometimes refer to a piece of glass, a sea glass that can be found almost everywhere, for example at the beaches near San Francisco.

I share his amazement that after years of listening to vendor sermons on the benefits of server consolidation, now there's talk about going the opposite direction. Whatever happened to "green" in the data center?

He also makes the excellent point that proponents of standing up many servers with small databases typically ignore database licensing fees, which are typically charged per server (sometimes per core).

Anyway, good read.