Chapter 15. Nonrelational Databases
SCALING THE DATA STORAGE LAYER OF YOUR APPLICATION IS HARD. It seems that no matter what database technology you use, as the volume of data and the number of transactions increases, changes need to be made to accommodate that new load. With some databases, it’s as simple as buying more hardware; more nodes to add to the cluster. For most of the open source SQL databases on the market right now, however, that’s simply not the case. Queries, schemas, and application logic all need to be changed to make the data access faster and more scalable.
SQL database scalability usually boils down to four main things: caching, query optimization, buying new hardware, and sharding the database. Caching is a bit beyond the scope of this chapter, but it can help to alleviate some of the read load on the database. Unfortunately, it adds complexity to your application and has an upper bound on how much load it can reduce. Query optimization, like caching, can do only so much. Caching and query optimization are good practices, but they can go only so far.
Buying new hardware is always a valid choice when it comes to scaling SQL databases. It’s fairly simple to do, and it is proven to work. As database load increases, simply buy better and faster hardware. The problems with this are twofold: it’s expensive, and once you’ve bought the best hardware, there’s nothing more you can do. In practice, expensive hardware, caching, and efficient queries can carry ...