MongoDBのシャーディングはどのように機能しますか？

Question

Accepted Answer

**シャーディング**は、MongoDBの**水平スケーリング**の方法です。複数のサーバー（**シャード**）にデータを分散して、単一のサーバーが処理できる範囲を超えたデータセットとスループットをデータベースが処理できるようにします。**シャードキー**によってデータをパーティション分割し、MongoDBはクエリを適切なシャードにルーティングします。

## なぜ重要なのか

シャーディングは、**MongoDBを非常に大規模なデータセットと高スループットにスケーリングするための重要な知識**であり、大規模なMongoDBデプロイメント向けのシニアレベルの知識として価値があります。

コア価値は**水平スケーリング**です。データやロードが単一のサーバーで処理できる限界を超えた場合、シャーディングはデータを複数のシャードに分散し、容量を水平方向にスケーリングして、垂直スケーリング（より大きなサーバー）では到達できない巨大なデータセットと高い書き込みスループットを処理します。これは大規模システムの重要な機能です。

**アーキテクチャ**（各シャードがデータのサブセットを保持し、`mongos`クエリルーターがクエリを指示し、設定サーバーがメタデータを保存する）を理解することは基本的なものです。

最も重要なのは、**シャードキー**（データ分散を決定するフィールド）を理解することです。これは**最も重大で、変更が難しいシャーディング決定**であるため、本質的に重要です。優れたシャードキー（高いカーディナリティ、均等な分散、クエリパターンに合致）はデータと負荷を均等に分散し、ターゲット化されたクエリを可能にします。一方、不適切なシャードキーはホットスポット（不均衡な負荷）、スキャッター・ギャザークエリ（すべてのシャードにヒット、遅い）、スケーリング不良を引き起こします。

**ターゲット化されたクエリとスキャッター・ギャザークエリの違い**（シャードキーを含むクエリは特定のシャードに効率的にルーティングされ、含まないクエリはすべてのシャードにヒット）を理解することは、クエリパターンの周辺でシャードキーを設計することの重要性を強調しています。

スケーリングが大規模なデータへの実際の課題であり、シャーディング（MongoDBの水平スケーリングメカニズム）は慎重な理解が必要であるため（特に重大で変更が難しいシャードキー決定とそれが分散やクエリ効率に与える影響）、シャーディングの理解はMongoDBのスケーリングのためのシニアレベルの重要な知識です。これは水平型データベーススケーリングの理解を示すトピックであり、シャードキー決定は特に、大規模システムを処理するシニアロールで期待される、深くて重大なMongoDBスケーリング専門知識を反映しています。

## シャーディングの仕組み

```text
The sharded cluster has three parts:
  SHARDS    → each holds a portion of the data (each shard is itself a replica set)
  mongos    → query ROUTER — apps connect here; it routes queries to the right shard(s)
  CONFIG SERVERS → store metadata (which data is on which shard)

Data is partitioned by the SHARD KEY into CHUNKS, distributed across shards.
MongoDB balances chunks across shards automatically.
```

## シャードキー — 最も重大な決定

```js
sh.shardCollection("mydb.orders", { customerId: 1 });   // shard by customerId
```

```text
The SHARD KEY determines how data is distributed — choosing it well is CRITICAL:
  ✓ HIGH CARDINALITY (many distinct values) → data spreads evenly
  ✓ EVEN DISTRIBUTION of reads/writes → no hot shards
  ✓ Queries include the shard key → routed to ONE shard (targeted, fast)
  ✗ A BAD shard key → uneven distribution (hotspots), or queries hitting ALL shards
    (scatter-gather, slow) → poor scaling. Hard to change later!
Strategies: ranged sharding, HASHED sharding (even distribution), zoned sharding.
```

## ターゲット化されたクエリとスキャッター・ギャザークエリ

```text
Query INCLUDES the shard key → routed to the specific shard(s) → fast (targeted)
Query WITHOUT the shard key → must query ALL shards (scatter-gather) → slower
→ Design the shard key around your common query patterns.
```

## 1つのサーバーを超えてスケーリングする理由

```text
A single server has limits (storage, RAM, write throughput). When data/load exceeds
what one server (even a powerful one) can handle, SHARDING distributes it:
  → data is split across multiple SHARDS (each a replica set)
  → each shard holds a SUBSET of the data → combined capacity scales horizontally
  → handles huge datasets and high write throughput
```