데이터베이스 쓰기 확장을 위한 전략

Source: Dev.to

Introduction

In the previous article, we saw how to scale reads by reducing the amount of work the database has to do for every query.

Writes have a different problem.

A write is not just “store this data”. It often means:

• Update indexes
• Maintain order
• Enforce constraints
• Check relationships
• Modify multiple structures

As write traffic increases, the database becomes write‑bound because every write forces the system to do a lot of organizational work.
So the goal of scaling writes is simple:

Make each write as lightweight as possible.

The Core Idea Behind Scaling Writes

A write becomes slow when the database has to:

• Update many indexes
• Maintain strict structure
• Perform synchronous checks
• Touch multiple data locations

Strategy: Reduce how much work happens at the moment of the write by postponing, distributing, or simplifying that work. Every technique below follows this idea.

1. Sharding (Horizontal Partitioning)

Split data across multiple shards so each shard handles only a portion of the write load.

Why it works: If one machine handles W writes/sec, N shards can handle roughly N × W writes/sec. Writes are distributed instead of competing for the same resources.

2. Batch Writes

Group many writes together instead of writing records one by one.

Why it works: Larger sequential operations are far more efficient for databases and disks, reducing overhead per write.

3. Asynchronous Writes

Acknowledge the write to the client early and perform heavy work (indexing, constraints) later in the background.

Why it works: User‑perceived latency drops, and the database can organize work more efficiently offline.

4. Write‑Ahead Logging (WAL)

Before modifying actual tables, write the change to an append‑only log.

Why it works: Appending to a log is extremely fast; the database can later apply and organize the changes.

5. LSM‑Based Engines

Log‑Structured Merge (LSM) trees (e.g., Cassandra, RocksDB, LevelDB) write data to memory first and periodically flush sorted data to disk.

Why it works: Writes are fast initially; sorting and compaction happen later, deferring expensive work.

6. Idempotent Writes

Design writes so that repeating the same operation has no adverse effect.

Why it works: Retries, batching, and asynchronous processing can occur without extra read‑before‑write checks.

7. Reduced Indexing

Limit indexes to only those that are truly necessary.

Why it works: Fewer structures to maintain means less work per write.

The Pattern Behind All These Techniques

All the strategies share a common principle:

Make writes cheaper by reducing immediate organization work.

You can achieve this by:

• Distributing the load
• Delaying the work
• Simplifying the structure
• Turning random writes into sequential ones

Final Thought

Scaling writes isn’t about making the database itself faster; it’s about making each write lighter. You achieve this by:

• Postponing structure maintenance
• Distributing load across shards or nodes
• Writing sequentially (batching)
• Avoiding unnecessary work (excess indexes, synchronous checks)