The following article can be considered as a continuation of Embarking on a Data Odyssey: A Comprehensive Introduction to Cosmos DB. In order to talk about Cosmos DB performance we would need to understand what are the traditional database scaling options.
Database scalability is the ability to expand or contract the capacity of system resources in order to support the changing usage of your application. This can refer both to increasing and decreasing usage of the application.
Traditional scaling in the context of databases refers to:
- the process of increasing the capacity and performance of a database system by adding more resources to a single server or upgrading the existing hardware. This approach is also known as vertical scaling or scaling up.
- the process of adding more machines or nodes to a distributed environment rather than upgrading a single server's resources. This approach is also known as horizontal scaling or scaling out.
Vertical scaling involves making a single machine more powerful to handle increased workload and demands.
Vertical scaling
Here are some common ways vertical scaling is achieved in a database system:
Increasing CPU Power:
Upgrading the central processing unit (CPU) of the server to a faster and more powerful one allows the database server to process queries and transactions more quickly.
Adding Memory (RAM):
Increasing the amount of random-access memory (RAM) in a server helps the database store more data in memory, reducing the need to access data from slower storage devices like hard drives.
Improving Storage:
Upgrading to faster and larger storage devices, such as solid-state drives (SSDs), can enhance the speed at which the database retrieves and stores data.
Optimizing Disk I/O:
Improving the input/output (I/O) performance of storage devices by using techniques like RAID (Redundant Array of Independent Disks) can enhance the overall performance of the database system.
Enhancing Network Infrastructure:
Upgrading the network infrastructure can improve the speed at which data is transmitted between the database server and client applications.
While vertical scaling can provide immediate relief by boosting the capabilities of a single server, it has some limitations:
Finite Scalability:
There is a practical limit to how much a single server can be scaled vertically. Once the hardware reaches its maximum capacity, further scaling becomes challenging.
Single Point of Failure:
Relying on a single, powerful server creates a single point of failure. If the server goes down, the entire system becomes unavailable.
Cost:
High-end hardware capable of substantial vertical scaling can be expensive.
Downtime during Upgrades:
Scaling up often requires taking the database offline during hardware upgrades, resulting in downtime.
As an alternative or complement to vertical scaling, many organizations also consider horizontal scaling, which involves adding more servers to a distributed system. This approach is often associated with technologies like sharding, clustering, and replication, providing a more scalable and fault-tolerant solution for handling growing workloads.
Horizontal scaling
Horizontal scaling, also known as scaling out, is an approach to expanding a system's capacity and performance by adding more machines or nodes to a distributed environment rather than upgrading a single server's resources. Unlike vertical scaling, where you increase the power of a single machine, horizontal scaling focuses on distributing the workload across multiple machines to handle larger volumes of data and traffic. Here are some key aspects of horizontal scaling:
Distribution of Workload:
Sharding:
This involves breaking down a large database into smaller, more manageable pieces called shards. Each shard is hosted on a separate server, distributing the data and workload across multiple machines.
Partitioning:
Similar to sharding, partitioning involves dividing a database into partitions based on certain criteria, such as range, hash, or list partitioning. Each partition can be stored on a different server.
Increased Redundancy and Fault Tolerance:
Replication:
Creating replicas of the database on multiple servers helps ensure data redundancy and fault tolerance. If one server fails, another can take over, minimizing downtime and data loss.
Load Balancing:
Distributing incoming traffic or queries across multiple servers ensures that no single server becomes a bottleneck. Load balancers help optimize resource utilization and enhance system performance.
Scalability:
Adding Nodes:
To scale horizontally, you simply add more servers or nodes to the system. This makes it easier to accommodate increased data volume, user traffic, or processing demands.
Elasticity:
Horizontal scaling allows for dynamic adjustments to the number of nodes in the system, enabling flexibility to scale up or down based on changing workloads.
Cost-Effectiveness:
Horizontal scaling often utilizes commodity hardware, which is more cost-effective than investing in high-end, powerful servers. This can result in a more affordable and scalable solution.
The same way as the vertical scaling, the horizontal scaling has its own limitations:
Data Consistency:
Ensuring consistency across distributed nodes can be challenging. Techniques like eventual consistency and distributed transactions are often used to address this issue.
Complexity: Managing a distributed system introduces complexities, including network latency, inter-node communication, and potential synchronization challenges.
Popular technologies and approaches associated with horizontal scaling include distributed Databases as Apache Cassandra, MongoDB, and Amazon DynamoDB.
Technologies like Docker and Kubernetes facilitate the deployment and management of containerized applications, making it easier to scale horizontally.
Horizontal scaling is widely adopted in modern cloud-based architectures, providing a more flexible and scalable solution for handling growing workloads in a distributed and resilient manner.
In a future article, we will see that when using Cosmos DB we can't proceed in the same way. We don't manage the underlying infrastructure, it is a managed service.
Photo by Shubham's Web3 on Unsplash
P.S.
I would love hearing from our tech-savvy community! Have insights, tips, or burning questions? Don't keep them to yourself! Drop your thoughts in the comments below. Let's spark a conversation and learn from each other's experiences in the dynamic world of Azure migration.
Top comments (0)