Understanding Distributed Database Scenarios and Data Partitioning

Q1: What are the applicable scenarios for distributed databases, and how do they differ from traditional databases?

Distributed databases mainly address two scenarios:

When data volume exceeds the capacity of a single machine or scaling up is prohibitively expensive, requiring scale‑out expansion.

When high availability is needed, deploying across multiple independent physical machines—or even across data centers—to mitigate single‑machine failures.

For external users, distributed databases provide essentially the same functionality as traditional databases but with superior scalability and availability.

Internally, the implementation is far more complex: distributed systems must handle time ordering, data consistency, network partitions, and the full suite of database features such as ACID transactions and indexing, making them significantly harder to build.

Q2: When a client reads data, how does a distributed system know which machine holds the data? Does it need to scan all machines?

Data in a distributed system is partitioned using range partitioning, hash partitioning, or a hybrid of both. The number of partitions and the machine each partition resides on are stored in system metadata. Clients either retrieve this metadata themselves or receive it from a Front‑End service, which then directs the request to the appropriate partition and machine, eliminating the need to query every node.