Sharding verteilt Daten über mehrere Server.
Architektur¶
- Shard — Replica Set mit Daten
- Config Server — Metadaten
- mongos — Router
Setup¶
sh.enableSharding('mydb')
sh.shardCollection('mydb.orders',{userId:'hashed'})
sh.status()
Shard Key¶
- Hashed — gleichmäßige Verteilung
- Ranged — Range-Abfragen effizient
- Compound — ausgewogene Verteilung
Wahl des Shard Key¶
Die richtige Wahl des Shard Key ist die wichtigste Entscheidung beim Sharding von MongoDB. Ein schlechter Shard Key fuehrt zu Hotspots — ein Shard erhaelt die meisten Schreibvorgaenge, waehrend andere ungenutzt bleiben. Ein idealer Shard Key hat hohe Kardinalitaet, verteilt Schreibvorgaenge gleichmaessig und unterstuetzt Ihre haeufigsten Abfragen.
Ein Hashed Shard Key gewaehrleistet gleichmaessige Verteilung, macht aber effiziente Range Queries unmoeglich. Ein Compound Shard Key (beispielsweise {tenant_id: 1, created_at: 1}) ist oft der beste Kompromiss — er verteilt Daten nach Tenant und ermoeglicht effiziente zeitbasierte Abfragen innerhalb eines Tenants. Einmal gewaehlt, kann der Shard Key nicht ohne Datenmigration geaendert werden. Der Balancer verschiebt automatisch Chunks zwischen Shards fuer gleichmaessige Verteilung, verbraucht dabei aber I/O und Netzwerkbandbreite.
Shard Key ist kritisch¶
Schlechter Shard Key = Hotspots.