Partitionierung

Partitionierung für die horizontale Skalierung einer Anwendung verwenden. Sie können die Anzahl der Partitionen in Ihrer Implementierungsrichtlinie definieren.

Informationen zur Partitionierung

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.

Wichtig: Wählen Sie die Anzahl der Partitionen sorgfältig aus. Die in der Implementierungsrichtlinie definierte Partitionsanzahl wirkt sich direkt auf die Anzahl der Container-Server aus, auf die eine Anwendung skaliert werden kann. Jede Partition setzt sich aus einem primären Shard und der konfigurierten Anzahl an Replikat-Shards zusammen. Mit der Formel (Anzahl_Partitionen*(1 + Anzahl_Replikate)) wird die Anzahl der Container berechnet, die verwendet werden kann, um eine einzelne Anwendung horizontal zu skalieren.

Partitionen verwenden

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.

ObjectMap und Partitionierung

Bei der Verteilungsstrategie FIXED_PARTITION werden Maps auf Partitionen und die Hash-Werte von Schlüsseln auf verschiedene Partitionen verteilt. Der Client muss nicht wissen, zu welcher Partition die Schlüssel gehören. Wenn ein MapSet mehrere Maps hat, müssen die Maps in separaten Transaktionen festgeschrieben werden.

Entitäten und Partitionierung

EntityManager-Entitäten besitzen eine Optimierung, die Clients hilft, die mit Entitäten in einem Server arbeiten. Das Entitätsschema im Server für das MapSet kann eine einzige Stammentität spezifizieren. Der Client muss auf alle Entitäten über diese Stammentität zugreifen. Der EntityManager findet dann die zugehörigen Entitäten über diese Stammentität, ohne dass die zugehörigen Maps einen gemeinsamen Schlüssel haben müssen. Die Stammentität stellt die Affinität zu einer einzelnen Partition her. Diese Partition wird nach der Herstellung der Affinität für all Entitätsabrufe innerhalb der Transaktion verwendet. Diese Affinität kann zu Speichereinsparungen führen, weil die zugehörigen Maps keinen gemeinsamen Schlüssel benötigen. Die Stammentität muss mit einer modifizierten Entitätsannotation angegeben werden, wie im folgenden Beispiel gezeigt wird:
@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.