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.
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.
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: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: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.
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.
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.