Partitionierung für die horizontale Skalierung einer Anwendung verwenden. Sie können die Anzahl der Partitionen in Ihrer Implementierungsrichtlinie definieren.
Partitionierung ist nicht dasselbe wie RAID-Striping (Redundant Array of Independent Disks), bei dem Teile jeder Instanz auf alle Stripes verteilt werden. Jede Partition enthält die vollständigen Daten für einzelne Einträge. Partitionierung ist ein effektives Mittel für Skalierung, aber nicht auf alle Anwendungen anwendbar. Anwendungen, die Transaktionsgarantien über große Datengruppen hinweg erfordern, können nicht skaliert und nicht effizient partitioniert werden. Deshalb unterstützt WebSphere eXtreme Scale derzeit keine partitionsübergreifende zweiphasige Festschreibung.
Ein Datengrid kann Tausende von Partitionen haben. Ein Datengrid kann vertikal bis auf das Produkt aus Partitionsanzahl und Shard-Anzahl pro Partition skaliert werden. Wenn Sie beispielsweise 16 Partitionen haben und jede Partition ein einziges primäres Shard oder zwei Shards hat, können Sie potenziell eine Skalierung auf bis 32 Java Virtual Machines erreichen. In diesem Fall wird für jede JVM ein einziges Shard definiert. Sie müssen, basierend auf der erwarteten Anzahl an Java Virtual Machines, die wahrscheinlich verwendet werden, eine angemessene Anzahl an Partitionen auswählen. Mit jedem Shard erhöht sich die Prozessor- und Speicherbelegung für das System. Das System ist so konzipiert, dass es horizontal skaliert werden kann, um diesen Aufwand entsprechend der Anzahl verfügbarer Java Virtual Machines des Servers handhaben zu können.
Anwendungen sollten nicht Tausende von Partitionen verwenden, wenn die Anwendung in einem Datengrid mit vier Container-Server-JVMs ausgeführt wird. In der Konfiguration der Anwendung sollte eine angemessene Anzahl an Shards für jede Container-Server-JVM angegeben werden. Eine unverhältnismäßige Konfiguration sind beispielsweise 2000 Partitionen mit zwei Shards, die in vier Container-JVMs ausgeführt werden. Diese Konfiguration würde bedeuten, dass 4000 Shards auf vier Container-JVMs bzw. 1000 Shards pro Container-JVM verteilt werden.
Eine bessere Konfiguration wären 10 Shards für jede erwartetet Container-JVM. Diese Konfiguration bietet Ihnen trotzdem die Möglichkeit einer elastischen Skalierung bis hin zum Zehnfachen der Erstkonfiguration bei einer gleichzeitig angemessenen Anzahl an Shards pro Container-JVM.
Stellen Sie sich das folgende Skalierungsbeispiel vor: Sie haben derzeit sechs physische Server mit jeweils zwei Container-JVMs. Sie erwarten ein Wachstum auf 20 physische Server in einem Zeitraum von drei Jahren. Mit 20 physischen Servern haben Sie 40 Container-Server-JVMs, und Sie wählen 60 aus, um pessimistisch zu sein. Sie möchten vier Shards pro Container-JVM haben. Sie haben 60 potenzielle Container bzw. insgesamt 240 Shards. Wenn Sie pro Partition ein primäres Shard und ein Replikat-Shard haben, möchten Sie 120 Partitionen haben. Diese Beispielrechnung ergibt 240, geteilt durch 12 Container-JVMs, bzw. 20 Shards pro Container-JVM für die Erstimplementierung mit der Möglichkeit einer späteren Skalierung auf 20 Computer.
@Entity(schemaRoot=true)Verwenden Sie die Entität, um das Stammelement des Objektgraphen zu ermitteln. Der Objektgraph definiert die Beziehungen zwischen Entitäten. Jede verbundene Entität muss in dieselbe Partition aufgelöst werden. Es wird davon ausgegangen, dass sich alle untergeordneten Elemente in derselben Partition wie das Stammelement befinden. Die untergeordneten Entitäten im Objektgraphen sind von einem Client aus nur über die Stammentität zugänglich. Stammentitäten sind in partitionierten Umgebungen immer erforderlich, wenn ein Client von eXtreme Scale für die Kommunikation mit dem Server verwendet wird. Es kann nur ein einziger Stammentitätstyp pro Client definiert werden. Stammentitäten sind nicht erforderlich, wenn XTP-ObjectGrids (Extreme Transaction Processing) verwendet werden, da die gesamte Kommunikation mit der Partition über direkten lokalen Zugriff und nicht über den Client/Server-Mechanismus erfolgt.