When should you scale your database? The short answer often is: Don't scale until you have to. It is important to understand—and exhaust—all of your options for improving database performance first. Here is a look at the common options available.
Posted September 10, 2014
There has been a lot of interest lately in NoSQL databases and, of course, many of us have strong backgrounds and experience in traditional relational "SQL" databases. For application developers this raises questions concerning the best way to go. One recurring truth that eventually surfaces with all new software technologies is that "one size does not fit all." In other words, you need to use the right tool for the job, as each has its own strengths and weaknesses. In fact, a danger of many new architectural approaches is one of "over-adoption" - using a given tool to address a wide array of situations when originally they were designed for the specific problem domain in which they excel.
Posted November 09, 2010
Database Sharding: The Key to Database Scalability
Posted August 18, 2009
The concept of database sharding has gained popularity over the past several years due to the enormous growth in transaction volume and size of business-application databases. Database sharding can be simply defined as a "shared-nothing" partitioning scheme for large databases across a number of servers, enabling new levels of database performance and scalability. If you think of broken glass, you can get the concept of sharding—breaking your database down into smaller chunks called "shards" and spreading them across a number of distributed servers.
Posted August 14, 2009