What is database scaling?
Database scaling is the process of increasing a database system's ability to handle more data, queries, writes, or concurrent users while maintaining acceptable performance and reliability.
Questions 51-75: Database Scaling, Partitioning, NoSQL & Data Consistency.
Open a question for the full answer, code and interview guidance.
Database scaling is the process of increasing a database system's ability to handle more data, queries, writes, or concurrent users while maintaining acceptable performance and reliability.
Vertical database scaling increases the capacity of one database server by adding CPU, memory, faster storage, or higher network capacity.
Database replication maintains copies of data on multiple database instances. Replicas may be used for high availability, disaster recovery, geographic distribution, or read scaling.
A read replica is a database copy that receives replicated changes from a primary database and serves read workloads. It can reduce read pressure on the primary when the application has many queries relative to writes.
Replication lag is the delay between a change being committed on the source database and becoming visible on a replica.
Partitioning divides a large logical dataset into smaller portions according to a partitioning rule. Depending on the database technology, partitions may remain within one database system or be distributed across different nodes.
Horizontal partitioning divides rows of the same logical table into separate partitions. Each partition has the same columns but stores a subset of rows based on a key or range.
Vertical partitioning separates columns or related groups of data into different tables or stores. It can keep frequently accessed data small while moving large or rarely used attributes elsewhere.
Sharding distributes portions of a logical dataset across multiple independent database nodes. Each shard owns a subset of the data, commonly selected by tenant, customer, geographic region, or a hash of a key.
A good shard key distributes workload and data reasonably evenly while aligning with common access patterns. It should avoid concentrating a large percentage of traffic on one shard.
A hot partition is a partition that receives disproportionately high traffic or data compared with others. It can become the system bottleneck even when total capacity across all partitions is large.
Consistent hashing is a technique for mapping keys to nodes so that adding or removing a node causes only a portion of keys to move rather than remapping nearly the entire dataset.
Normalization organizes relational data to reduce unnecessary duplication and maintain data integrity. It commonly separates entities and relationships into tables connected by keys.
Denormalization intentionally duplicates or pre-combines data to make important reads faster or simpler. Examples include storing calculated totals, maintaining read models, or embedding commonly displayed values.
A NoSQL database can be appropriate when the workload benefits from a non-relational data model, flexible schema, massive horizontal distribution, specialized access patterns, or database-specific consistency and availability characteristics.
A document database stores records as self-contained documents, commonly JSON-like structures. Related data that is normally accessed together can often be stored together in one document.
A key-value database stores values that are retrieved primarily through a unique key. This simple access model can provide very high performance and horizontal scalability.
A graph database represents data as nodes and relationships and is optimized for traversing connections. It is useful when relationships are central to the queries, such as social networks, recommendation relationships, fraud analysis, or dependency graphs.
Polyglot persistence means using different data-storage technologies within one system because different workloads have different requirements.
The CAP theorem states that when a distributed data system experiences a network partition, it cannot simultaneously guarantee both strong consistency and availability for every operation.
Strong consistency means clients observe data according to a model in which completed writes are visible in the required order, often making the system behave as though there is one current authoritative value.
Eventual consistency allows replicas or derived views to be temporarily different after an update, with the expectation that they converge when updates stop and communication succeeds.
Read-your-writes consistency guarantees that after a client successfully writes data, that same client will not subsequently observe an older version through the relevant read path.
Optimistic concurrency control assumes conflicts are relatively uncommon. A record carries a version or concurrency token, and an update succeeds only if the version has not changed since it was read.
Pessimistic concurrency control prevents conflicting access by acquiring locks before or while data is being changed. Other transactions may wait until the lock is released.