Databases, Replication and Sharding
SQL vs NoSQL
| Relational (SQL) | NoSQL | |
|---|---|---|
| Model | Tables, joins, schema | Document, key-value, wide-column, graph |
| Consistency | ACID transactions | Often tunable / eventual |
| Scaling | Vertical first, then replicas and sharding | Designed to scale out |
| Use when | Strong relationships, transactions | Huge scale, flexible schema, simple access patterns |
Replication
| Mode | Behaviour |
|---|---|
| Leader-follower | Writes go to the leader; followers serve reads |
| Multi-leader | Several writers, needs conflict resolution |
| Leaderless | Quorum reads and writes (Dynamo style) |
Synchronous replication gives stronger durability with higher latency; asynchronous is faster but followers can lag (replication lag), so a user may read stale data after writing.
Sharding (partitioning)
Split data across machines.
| Scheme | Description | Trade-off |
|---|---|---|
| Range | Key ranges per shard | Easy range queries, hot spots |
| Hash | hash(key) mod N or consistent hashing | Even load, hard range queries |
| Directory | Lookup service maps keys to shards | Flexible, extra hop |
Challenges: cross-shard joins and transactions, resharding, choosing a shard key that avoids hot spots.
CAP theorem
During a network partition a distributed store must choose between consistency (every read sees the latest write) and availability (every request gets a response).
| Type | Behaviour in a partition | Examples |
|---|---|---|
| CP | Refuse some requests to stay consistent | HBase, etcd, ZooKeeper |
| AP | Keep serving, reconcile later | Cassandra, DynamoDB (default) |
The PACELC extension adds that, even without a partition, you trade latency against consistency.
Consistency models
Strong, eventual, causal, read-your-writes, monotonic reads.
Indexing and storage engines
B-trees favour reads and in-place updates (typical relational DBs); LSM trees (Cassandra, RocksDB) favour high write throughput with background compaction.