24 Beispiel: Erstellung eines Sharding Keys für eine Collection

Ein Sharding Key ist essenziell, um Daten in einem Sharded Cluster effizient zu verteilen. Der Schlüssel muss sorgfältig gewählt werden, um eine gleichmäßige Datenverteilung (Balancing) zu gewährleisten und Hotspots zu vermeiden.

24.1 Szenario

Angenommen, wir haben eine Sammlung orders mit folgendem Schema:

{
  "orderId": "12345",
  "customerId": "67890",
  "orderDate": "2024-12-01T10:00:00Z",
  "totalAmount": 250.75,
  "status": "shipped"
}

Wir wollen diese Sammlung basierend auf einem sinnvollen Sharding Key partitionieren.

24.2 1. Wahl des Sharding Keys

24.2.1 Ziel:

• Gleichmäßige Verteilung der Daten über alle Shards.
• Optimierung für häufige Abfragen (z. B. nach customerId oder orderDate).

24.2.2 Optionen:

1. customerId: Gut geeignet, wenn häufige Abfragen pro Kunde gestellt werden.
2. orderDate: Sinnvoll, wenn Abfragen nach Zeiträumen erfolgen.
3. Kombination aus customerId und orderDate: Ideal, um Workloads granularer zu verteilen.

24.3 2. Erstellung eines Sharding Keys

24.3.1 Beispiel 1: Einzelfeld-Sharding mit customerId

Wir sharden die Collection basierend auf dem Feld customerId und verwenden Hash-Based Sharding, um eine gleichmäßige Verteilung sicherzustellen.

// Sharding für die Datenbank aktivieren
sh.enableSharding("shopDB")

// Sharding Key für die Collection erstellen
sh.shardCollection("shopDB.orders", { customerId: "hashed" })

24.3.2 Erklärung:

• customerId wird als Sharding Key genutzt.
• "hashed" sorgt dafür, dass die Werte von customerId gehasht und gleichmäßig über die Shards verteilt werden.

24.3.3 Beispiel 2: Zusammengesetzter Sharding Key mit customerId und orderDate

Wenn Abfragen sowohl nach Kunde als auch nach Zeit erfolgen, könnte ein zusammengesetzter Sharding Key sinnvoll sein.

sh.shardCollection("shopDB.orders", { customerId: 1, orderDate: 1 })

24.3.4 Erklärung:

• { customerId: 1, orderDate: 1 } ist ein zusammengesetzter Key.
• Die Verteilung basiert primär auf customerId. Innerhalb eines Shards wird nach orderDate sortiert.

24.4 3. Beispiel für eine zweite Collection: inventory

Angenommen, wir haben eine Sammlung inventory:

{
  "itemId": "A123",
  "warehouseId": "W001",
  "quantity": 100,
  "lastUpdated": "2024-12-05T15:30:00Z"
}

Für eine hohe Verfügbarkeit könnten wir die Daten nach warehouseId sharden, da Abfragen häufig lagerbasiert sind.

sh.shardCollection("shopDB.inventory", { warehouseId: "hashed" })

24.5 Tipps zur Auswahl des Sharding Keys

• Hohe Kardinalität: Der Schlüssel sollte viele eindeutige Werte haben, um eine gute Datenverteilung zu gewährleisten.
• Häufig genutzte Felder: Wähle ein Feld, das in den meisten Abfragen als Filter verwendet wird.
• Vermeide monotone Verteilung: Nutze Hash-Based Sharding für Felder mit zeitbasierten oder sequentiellen Werten.

24.6 Vorteile und Herausforderungen der Datenverteilung

24.6.1 Vorteile des Sharding

1. Horizontale Skalierung: MongoDB kann Daten nahtlos auf mehrere Maschinen verteilen, was die Speicherkapazität und den Durchsatz erhöht.
2. Höhere Verfügbarkeit: In einem Sharded Cluster können Daten repliziert werden, was die Verfügbarkeit bei Knotenausfällen verbessert.
3. Lastverteilung: Der Balancer stellt sicher, dass Chunks gleichmäßig über alle Shards verteilt sind, um die Last gleichmäßig zu verteilen.
4. Optimierung großer Datenmengen: Sharding ermöglicht es, große Datenmengen effizient zu speichern und zu verarbeiten.

24.6.2 Herausforderungen und Lösungen

1. Wahl des Shard Keys:
   • Ein schlecht gewählter Shard Key kann zu einer ungleichen Verteilung der Daten führen.
   • Lösung: Wählen Sie einen Shard Key, der eine gleichmäßige Verteilung gewährleistet, wie Felder mit hoher Kardinalität (viele unterschiedliche Werte).
2. Abfragen über mehrere Shards:
   • Quer-Shard-Abfragen können die Leistung beeinträchtigen.
   • Lösung: Strukturieren Sie Ihre Abfragen so, dass sie auf einen bestimmten Shard oder eine kleine Gruppe von Shards beschränkt sind.
3. Chunk-Splitting und Migration:
   • Wenn ein Chunk zu groß wird, muss er aufgeteilt und migriert werden, was zusätzliche Ressourcen benötigt.
   • Lösung: Überwachen Sie regelmäßig die Chunk-Größe und aktivieren Sie den Balancer zur automatischen Verwaltung.
4. Netzwerküberlastung:
   • Datenmigration und Abfragen zwischen Shards können das Netzwerk stark belasten.
   • Lösung: Nutzen Sie ein dediziertes Netzwerk für den Datenverkehr zwischen den Shards und den Konfigurationsservern.
5. Komplexität der Administration:
   • Sharded Cluster erfordern mehr Verwaltungsaufwand als einfache Replikatsets.
   • Lösung: Automatisierungstools wie MongoDB Atlas oder Ops Manager nutzen, um die Verwaltung zu vereinfachen.

Die effiziente Verteilung von Daten in einem MongoDB-Sharded Cluster erfordert sorgfältige Planung und regelmäßige Überwachung. Mit der richtigen Konfiguration und Verwaltung können die Vorteile wie Skalierbarkeit und Leistung maximiert werden, während die Herausforderungen minimiert bleiben.