Web Operations

The Yearning for a Cluster

At this point, you are probably wondering if I'll ever get around to helping you understand how to choose a good database architecture for your application, or if I'm just going to keep telling you about more and more choices and explaining why they are all complex and there's no simple answer. Well, yes. I'll do both. I have one more thing to cover—and it's very important—and then I'll tell you about some database architectures that I consider to be reasonably good bets.

The topic of clustering is absolutely vital to cover, for two reasons:

• Right now no good clustering option is available for most web database use cases, and I am not sure that'll change anytime soon.

• Everyone goes through a phase of pinning her hopes on something with the word cluster in its name. I did it myself, and I've seen a lot of others do it, too.

When applications start to have trouble of one kind or another, or when managers start to ask hard questions about high availability or scalability, people's thoughts turn to clustering like a young man's thoughts turn to love in springtime. Everyone has a vague notion of the word cluster in the beginning. People dream of some amorphous, magical system that takes a whole bunch of servers and makes them look and act like a single server. This works fine for web servers, but not for databases.

The fundamental reason people hope for a cluster to solve their problems is that things are so easy when you have just one server. When you add in more ...