Become a Redis expert.
See what's new in Redis University
Database scaling is the ability of a database to obtain or cut resources depending on the system’s load, establishing a direct correlation between the allocation of resources and their demand. Scaling ensures consistency in the database server quality while keeping the use of resources as efficient as possible. For this reason, the scaling process is often automated. The automation of scaling is known as elasticity.
Learn the 9 Essential Database Capabilities
While many databases exist that have just one or even a few of these critical features, having all nine is vital to successfully manage the challenges they are facing today.
While scalability has a common principle of increasing or decreasing the database system resources as needed, there are different ways in which a system can scale. Some will prove more efficient depending on the tasks the database performs. Hence, the first question is whether the system should scale vertically or horizontally.
Vertical scaling consists of adding more resources to a single system node or computer, such as memory or processors. It is fast and straightforward to scale this way. However, vertical scaling has limitations and lacks flexibility. For example, a vertical scaling system can be a single point of failure for the database and compromise availability. Besides, these systems cannot deploy a virtual machine larger than their available resources; they had to scale first and deploy later.
Horizontal scaling is a powerful way to improve the performance and capacity of a system. With horizontal scaling, you can add more nodes or computers to your infrastructure to handle increasing traffic and demand. While it may take a little longer to deploy and start a new virtual machine, the benefits are well worth it. By adding more resources to your system, you can ensure that your application remains fast, responsive, and available to your users.
With horizontal scaling, you have the flexibility to add capacity as needed, without having to make a large upfront investment in hardware. This means you can adapt to changing business needs quickly and easily, without worrying about wasting resources or over-provisioning. And once your new machines are up and running, they are fully integrated into your system, providing a seamless and reliable experience for your users.
While there may be some waiting time until the new machines are up and running, the benefits of horizontal scaling far outweigh any potential drawbacks. By adding more resources to your system, you can ensure that your application is always available, always fast, and always ready to handle whatever comes your way. So if you’re looking to improve the performance and capacity of your system, consider horizontal scaling as a powerful tool to help you get there.
Want to Create database using Redis Cloud?
Create your free Redis Cloud account. Once you click on “Get Started”, you will receive an email with a link to activate your account and complete your signup process.
Database scaling techniques attempt to achieve the greatest performance by exploiting the database mechanisms depending on the database architecture and tasks.
Database replication consists of creating copies of the database. Database replicas work as secondary instances of the original database (also known as Design Primary). The Design master and the replicas form a replica set in which all of them synchronize to keep the same data.
To save resources, any change is first written into the Design Master database and later to the replicas. Reading, nonetheless, is divided among instances. As such, by sharing the system’s load, replication increases accessibility and performance.
Replication also adds fault tolerance to the system; by adding more points of connection to the database, ensuring the system will still work if one of these fails. In this regard, a replica can be designed to take the Design Master role if the latter is unavailable.
There are three primary methods for database replication:
Partitioning or sharding divides the database into smaller parts for managing and access purposes. Queries that only need a fraction of the data have fewer data to scan and therefore run faster, while the server can run tasks on different partitions in parallel. For this reason, partitioning is often chosen for large-scale databases.
Partitioning also offers more flexibility to the database; for example, databases can be divided by usage pattern into different types of data storage. Likewise, the most important or sensible data can be hosted in the best quality storage or a more secure partition with distinct security measures. Also, if your database’s hardware has reached its limit, you can opt to divide the database and store part of it in a new server.
Related Resource: New Database Scaling and Security Features in Azure Cache for Redis Enterprise Tiers
Partitioning also prevents the database from having a single point of failure. Should something happen to a database instance, only the data in that database would be affected.
Data partitioning is achieved mainly in three ways:
Horizontal partitioning (also known as range partitioning) divides the data based on a range of values for a selected key field. Each partition has a separate data store but shares a common schema. This method is useful for databases with large tables that need to be distributed across multiple nodes.
Vertical partitioning (also known as column partitioning) divides the data vertically by columns. Each partition has a subset of columns from the database, and the partitions are distributed among nodes depending on usage patterns. This method is useful when some columns are used more frequently than others, allowing for faster data access.
Functional partitioning divides the data according to how it is used by each bounded context in the system. This method is more closely related to domain-driven design and microservices architecture, where different services have their databases with separate schemas.
A database system can use both partitioning and replication. In this case, the database is divided into partitions and each partition is replicated across multiple servers. The tradeoffs are read-and-write scalability and high resiliency in the event of server failure.
On the other hand, while combining replication and partitioning provides greater flexibility, it can also increase the complexity of the database and introduce additional overhead for maintaining the replicas and partitions.
