NOTE

5.2 Distributed-System Partitioning: Request Processing

The routing component routes client read and write requests to the node that contains the corresponding partition. 1. Routing Component. 2. Request Processing 2.1. Add Data - 1. The client generates data containing a sharding key. 2. The client sends the add request to the routing component.

Distributed SystemsCreated Updated 2 min readhistorical

This is a historical learning note and may contain outdated or incomplete understanding.

The routing component routes client read and write requests to the node that contains the corresponding partition.

1. Routing Component

Routing Component

2. Request Processing

2.1. Add Data

  1. The client generates data containing a sharding key.
  2. The client sends the add request to the routing component.
  3. The routing component forwards the request to the corresponding node according to the sharding key.
  4. The node adds the data.

2.2. Delete Data

2.2.1. Contains the Sharding Key

  1. The client deletes data according to the sharding key.
  2. The client sends the delete request to the routing component.
  3. The routing component forwards the request to the corresponding node according to the sharding key.
  4. The node deletes the data.

2.2.2. Does Not Contain the Sharding Key

  1. The client deletes data according to a keyword.
  2. The client sends the delete request to the routing component.
  3. The routing component forwards the request to all nodes.
  4. Each node deletes the data.

2.3. Find Data

2.3.1. Contains the Sharding Key

  1. The client queries data according to the sharding key.
  2. The client sends the query request to the routing component.
  3. The routing component forwards the request to the corresponding node according to the sharding key.
  4. The node queries the data.

2.3.2. Does Not Contain the Sharding Key

  1. The client queries data according to a keyword.
  2. The client sends the query request to the routing component.
  3. The routing component forwards the request to all nodes.
  4. Each node queries the data.

2.4. Modify Data

2.4.1. Contains the Sharding Key

  1. The client modifies data according to the sharding key.
  2. The client sends the modification request to the routing component.
  3. The routing component forwards the request to the corresponding node according to the sharding key.
  4. The node modifies the data.

2.4.2. Does Not Contain the Sharding Key

  1. The client modifies data according to a keyword.
  2. The client sends the modification request to the routing component.
  3. The routing component forwards the request to all nodes.
  4. The node modifies the data.

2.4.3. Examples

  • MySQL CRUD can contain a sharding key or not contain one.
  • Redis CRUD contains a sharding key.
  • Kafka CRU contains a sharding key; there is no D.
  • ZooKeeper does not use partitioning.
  • Elasticsearch CRUD can contain a sharding key or not contain one.

3. Secondary Indexes

  • Data partitioning is not split according to secondary indexes.
  • But when data is accessed through a secondary index, there is a question of which partition the read/write request should be sent to.

3.1. Local Index (document based)

  • Each partition maintains only the index for the current partition and stores it locally.
  • Disadvantage
    • Read/write request routing uses scatter/gather.
  • Advantage
    • Fast writes.

3.2. Global Index (term based)

  • Indexes for all partitions are maintained together, and the index itself is also partitioned.
  • Disadvantage
    • Slow writes.
  • Advantage
    • Read/write request routing uses the term to route to the correct partition, similar to a primary-key index.

3.3. Examples

  • MySQL secondary indexes use local indexes.
  • Redis has no secondary indexes.
  • Kafka secondary indexes use local indexes.
  • ZooKeeper has no secondary indexes.
  • Elasticsearch secondary indexes use local indexes.

Discussion

Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub