Datengrids, Partitionen und Shards

Ein Datengrid ist in Partitionen unterteilt. Eine Partition enthält einen exklusiven Teil der Daten. Eine Partition enthält ein oder mehrere Shards: ein primäres Shard und Replikat-Shards. Replikat-Shards sind in einer Partitin nicht erofrderlich, aber Sie können Replikat-Shards für die Unterstützung der hohen Verfügbarkeit verwenden. Unabhängig davon, ob Ihre Implementierung ein unabhängiges speicherinternes Datengrid oder ein speicherinterner Datenbankverarbeitungsbereich ist, ist der Datenzugriff in eXtreme Scale im Wesentlichen von den Shard-Konzepten abhängig.

Die Daten für eine Partition werden zur Laufzeit in einer Gruppe von Shards gespeichert. Diese Gruppe von Shards setzt sich aus einem primären Shard und unter Umständen einem oder mehreren Replikat-Shards zusammen. Ein Shard ist die kleinste Einheit, die eXtreme Scale in einer Java Virtual Machine hinzufügen oder entfernen kann.

Es gibt zwei Verteilungsstrategien: feste Partitionsverteilung (Standardeinstellung) und containerbezogene Verteilung. Die folgende Beschreibung konzentriert sich auf die Verwendung der Strategie der festen Partitionsverteilung.

Gesamtanzahl der Shards

Wenn Ihre Umgebung beispielsweise zehn Partitionen mit einer Million Objekten ohne Replikate enthält, sind zehn Shards vorhanden, in denen jeweils 100.000 Objekte gespeichert sind. Wenn Sie diesem Szenario ein Replikat hinzufügen, ist in jeder Partition ein zusätzliches Shard vorhanden. In diesem Fall sind dann 20 Shards vorhanden, zehn primäre Shards und zehn Replikat-Shards. In jedem dieser Shards werden 100.000 Objekte gespeichert. Jede Partition setzt sich aus einem primären Shard und einem oder mehreren (N) Replikat-Shards zusammen. Die Festlegung der optimalen Shard-Anzahl ist ein kritischer Faktor. Wenn Sie eine geringe Anzahl an Shards konfigurieren, werden die Daten nicht gleichmäßig auf die Shards verteilt, was zu Fehlern wegen Speicherengpässen und Problemen durch Prozessüberlastung führt. Sie müssen bei der Skalierung mindestens zehn Shards für jede JVM festlegen. Wenn Sie das Grid implementieren, verwenden Sie möglicherweise eine höhere Anzahl an Partitionen.

Anzahl der Shards pro JVM

Szenario mit einer geringen Anzahl an Shards für jede JVM

Daten werden in einer JVM in Shard-Einheiten hinzugefügt und entfernt. Shards werden nie unterteilt. Wenn 10 GB Daten und 20 Shards zum Speichern dieser Daten vorhanden sind, enthält jedes Shard durchschnittlich 500 MB Daten. Wenn das Datengrid auf neun JVMs verteilt ist, hat jede JVM durchschnittlich zwei Shards. Da 20 nicht durch 9 teilbar ist, haben einige JVMs drei Shards. Die Verteilung ist wie folgt: Da jedes Shard 500 MB Daten enthält, ist die Verteilung der Daten unsymmetrisch. Die sieben JVMs mit zwei Shards enthalten jeweils 1 GB Daten. Die beiden JVMs mit drei Shards enthalten jeweils 50 % mehr Daten (oder 1,5 GB), was eine sehr viel höhere Speicherlast darstellt. Da die beiden JVMs drei Shards haben, empfangen sie auch 50 % mehr Anforderungen für ihre Daten. Deshalb führt eine geringe Anzahl an Shards für jede JVM zu einem Ungleichgewicht. Zur Verbesserung der Leistung erhöhen Sie die Anzahl der Shards für jede JVM.

Szenario mit einer höheren Anzahl an Shards pro JVM

In diesem Szenario wird eine sehr viel höhere Anzahl an Shards verwendet. Es gibt 101 Shards mit neun JVMs für 10 GB Daten. In diesem Fall werden in jedem Shard 99 MB Daten gespeichert. Die Shards sind wie folgt auf die JVMs verteilt: Die beiden JVMs mit jeweils 12 Shards enthalten jetzt nur 99 MB mehr Daten als die anderen Shards. Dies ergibt eine Differenz von 9 %. In diesem Szenario ist die Last gleichmäßiger verteilt als in dem Szenario mit einer geringeren Anzahl an Shards, wo die Differenz bei 50 % liegt. Vom Standpunkt der Prozessorauslastung betrachtet, fällt auf die beiden JVMs mit den jeweils 12 Shards im Vergleich mit den sieben JVMs mit jeweils 11 Shards nur 9 % mehr Arbeit. Durch die Erhöhung der Shard-Anzahl in jeder JVM wird die Daten- und Prozessorauslastung fair und gleichmäßig verteilt.

Verwenden Sie 10 Shards für jede JVM, wenn Sie Ihr System in maximaler Größe bzw. die Ausführung der maximalen Anzahl an JVMs in Ihrem System planen.

Zusätzliche Verteilungsfaktoren

Die Anzahl der Partitionen, die Verteilungsstrategie und der Typ der Replikate wird in der Implementierungsrichtlinie definiert. Die Anzahl der verteilten Shards richtet sich nach der definierten Implementierungsrichtlinie. Die Attribute "minSyncReplicas", "developmentMode", "maxSyncReplicas" und "maxAsyncReplicas" wirken sich auf die Verteilung von Partitionen und Replikaten aus.

Die folgenden Faktoren haben Auswirkungen auf den Zeitpunkt der Shard-Verteilung:
  • Befehle xscmd -c suspendBalancing und xscmd -c resumeBalancing
  • Servereigenschaftendatei, die die Eigenschaft placementDeferralInterval enthält, die die Anzahl der Millisekunden definiert, bevor Shards auf die Container-Server verteilt werden
  • Attribut numInitialContainers in der Implementierungsrichtlinie

Wenn beim Erststart nicht die maximale Anzahl an Replikaten verteilt wird, können weitere Replikate verteilt werden, wenn Sie später weitere Server starten. Bedenken Sie bei der Planung der Shard-Anzahl pro JVM darauf, dass die maximale Anzahl an primären Shards und Replikat-Shards davon abhängig ist, dass genügend JVMs fr die Unterstützung der maximalen Anzahl an Replikaten verfügbar sind. Ein Replikat wird niemals in demselben Prozess wie das primäre Shard ausgeführt. Wenn ein Prozess verloren geht, würden sonst das primäre Shard und das Replikat-Shard verloren gehen. Wenn das Attrbut "developmentMode" auf false gesetzt ist, werden die primären Shards und die Replikat-Shards nicht an denselben physischen Server verteilt.