Scalability and elasticity are related, though they are different aspects of database availability. Both scalability and elasticity help to improve availability and performance when demand is changing, especially when changes are unpredictable.
Scalability refers to the capability of a system to handle a growing amount of work, or its potential to perform more total work in the same elapsed time when processing power is expanded to accommodate growth. A system is said to be scalable if it can increase its workload and throughput when additional resources are added.
A related aspect of scalability is availability and the ability of the system to undergo administration and servicing without impacting applications and end user accessibility. A scalable system can be changed to adapt to changing workloads without impacting its accessibility, thereby assuring continuing availability even as modifications are made. In other words, a scalable system can be adjusted without requiring any downtime.
Elasticity is the degree to which a system can adapt to workload changes by provisioning and deprovisioning resources in an on-demand manner, such that at each point-in-time the available resources match the current demand as closely as possible.
The goal of elasticity is to balance the amount of resources allocated to a service with the amount of resources it actually requires. In so doing, both over- and under-provisioning can be avoided. Over-provisioning is when more resources are allocated than are required, and it should be avoided, particularly in a cloud model because the service provider must pay for all allocated resources, which can increase the cost. With under-provisioning fewer resources are allocated than are required, and this can be problematic because it usually results in performance problems. When performance is slow enough it can look like downtime to the end user, resulting in customers abandoning the application… and that has a financial impact.
From a database perspective, elasticity infers a flexible data model and clustering capabilities. The greater the number of changes that can be tolerated, and the ease with which clustering can be managed, the more elastic the DBMS.
Ways to Scale Databases
There are two broad categories for scaling database systems: vertical scaling and horizontal scaling. With vertical scaling, also called scaling up, resources (such as memory or more powerful CPUs) are added to an existing server. Removing resources, on the other hand, is called scaling down.
Replacing or adding resources to a system typically results in performance improvement, but realizing such gains often requires reconfiguration and downtime. Furthermore, there are usually limitations to the amount of additional resources that can be applied to a single system, as well as to the software that uses the system.
Vertical scaling has been a standard method of scaling for traditional RDBMSs that are architected on a single-server type model. Nevertheless, every piece of hardware has limitations that, when met, cause further vertical scaling to be impossible. For example, if your system only supports 256 GB of memory, when you need more memory you must migrate to a bigger box, which is a costly and risky procedure requiring database and application downtime.
Horizontal scaling, also known as scaling out, is the process of adding more hardware to a system. This typically means adding nodes (new servers) to an existing system. Doing the opposite, that is removing hardware, is referred to as scaling in.
With the cost of hardware declining, it can make sense to adopt horizontal scaling using low-cost commodity systems for tasks that previously required larger computers. Of course, horizontal scaling can be limited by the capability of software to exploit networked computer resources and other technology constraints. Keep in mind, too, that traditional database servers cannot run on more than a few machines (that is, you can typically scale to 2 or 3 machines, not to 100 or more).
Horizontal and vertical scaling can be combined, with resources added to existing servers to scale vertically and additional servers added to scale horizontally when required. It is wise to consider the tradeoffs between horizontal and vertical scaling as you consider each approach.
Horizontal scaling results in more computers networked together and that will cause increased management complexity. It can also result in latency between nodes and complicate programming efforts if not properly managed by either the database system or the application. That said, depending on your database system’s hardware requirements, you can often buy several commodity boxes for the price of a single, expensive, and often custom-built server that vertical scaling requires.
On the other hand, depending on your requirements, vertical scaling can be less costly if you’ve already invested in the hardware; it typically costs less to reconfigure existing hardware than to procure and configure new hardware. Of course, vertical scaling can lead to over-provisioning which can be quite costly.
Finally, you might want to look into some of the newer database systems (such as NuoDB, Cockroach, and FaunaDB) that were architected with scalability and elasticity in mind.