Servidores de Contêiner, Partições e Shards

O servidor de contêiner armazena dados do aplicativo para a grade de dados. Estes dados geralmente são divididos em partes, chamadas de partições, que são hospedadas em vários servidores de contêiner. Cada servidor de contêiner, por sua vez, hospeda um subconjunto de dados completos. Uma JVM pode hospedar um ou mais servidores de contêiner e cada servidor de contêiner pode hospedar diversos shards.

Lembre-se: Planeje o tamanho do heap para os servidores de contêiner, que hospedam todos os dados. Configure as configurações de heap apropriadamente.
Figura 1. Servidor de Contêineres
Um servidor de contêiner existe dentro de uma Java virtual machine e hospeda um número de shards.
Partições hospedam um subconjunto de dados na grade. O WebSphere eXtreme Scale coloca automaticamente diversas partições em um único servidor de contêiner e propaga as partições à medida que mais servidores de contêiner se tornam disponíveis.
Importante: Escolha o número de partições cuidadosamente antes da implementação final já que o número de partições não pode ser alterado dinamicamente. Um mecanismo hash é utilizado para localizar partições na rede e o eXtreme Scale não pode re-hash o conjunto de dados inteiro após ele ser implementado. Como uma regra geral, é possível superestimar o número de partições
Figura 2. Partição
Os shards são instâncias de partições e possuem uma das duas funções: primário ou de réplica. O fragmento primário e suas réplicas constituem a manifestação física da partição. Cada partição tem vários shards que hospedam, cada um deles, todos os dados contidos nessa partição. Um shard é o primário e os outros são réplicas, que são cópias redundantes dos dados no primeiro shard. Um fragmento primário é a única instância da partição que permite que as transações sejam gravadas no cache. Um fragmento de réplica é uma instância "espelhada" da partição. Ele recebe atualizações de forma síncrona e assíncrona do fragmento primário. O fragmento de réplica permite apenas a leitura das transações do cache. As réplicas nunca são hospedadas no mesmo servidor de contêiner que os primários e normalmente não são hospedados na mesma máquina que os primários.
Figura 3. Shard
Um shard contém múltiplos mapas.

Para aumentar a disponibilidade dos dados, ou aumentar garantias de persistência, replique os dados. Entretanto, a replicação inclui custo na transação e troca desempenho em retorno para a disponibilidade. Com o eXtreme Scale, é possível controlar o custo já que ambas as replicações síncrona e assíncrona são suportadas, bem como modelos de replicação híbrida utilizando os modos de replicação síncrona e assíncrona. O shard da réplica síncrona recebe atualizações como parte da transação do shard primário para garantir consistência de dados. Uma réplica síncrona pode duplicar o tempo de resposta porque a transação precisa executar commit na réplica primária e na réplica síncrona antes da transação ser concluída. Um shard de réplica assíncrono recebe atualizações após o commit da transação para limitar o impacto no desempenho, mas introduz a possibilidade de perda de dados enquanto que a réplica assíncrona pode ser diversas transações atrás do shard primário.

Figura 4. ObjectGrid
ObjectGrid