Particionamento

Use o particionamento para efetuar scale out de um aplicativo. É possível definir o número de partições em sua política de implementação.

Sobre Particionamento

O particionamento não é semelhante à divisão Redundant Array of Independent Disks (RAID), que fatia cada instância em todas as faixas. Cada partição hospeda os dados completos para entradas individuais. O particionamento é um meio mais efetivo para escalar, mas não é aplicável a todos os aplicativos. Os aplicativos que requerem garantias transacionais em grandes conjuntos de dados não são escalados e não podem ser particionados efetivamente. O WebSphere eXtreme Scale não suporta atualmente two-phase commit entre as partições.

Importante: Selecione o número de partições com cuidado. O número de partições definido na política de implementação afeta diretamente o número de servidores de contêiner aos quais o aplicativo pode ser escalado. Cada partição é constituída por um fragmento primário e pelo número configurado de fragmentos de réplica. A fórmula (Number_Partitions*(1 + Number_Replicas)) é o número de contêineres que pode ser utilizado para executar o scale out de um único aplicativo.

Utilizando Partições

Uma grade de dados pode ter até milhares de partições. Uma grade de dados pode efetuar scale up do produto até o número de partições vezes o número de shards por partição. Por exemplo, se você tiver 16 partições e cada uma delas tiver um shard primário e um shard réplica, ou dois shards, então, será possível ampliar para até 32 Java Virtual Machines. Neste caso, um shard é definido para cada JVM. É necessário escolher um número razoável de partições com base no número esperado de Java Virtual Machines que provavelmente serão utilizadas. Cada shard aumenta o uso de processador e de memória do sistema. O sistema foi desenvolvido para que possa expandir-se e manipular essa sobrecarga de acordo com o número de Java Virtual Machines de servidor disponíveis.

Os aplicativos não devem usar milhares de partições se o aplicativo executar em uma grade de dados de quatro Java Virtual Machines de servidor de conteiner. O aplicativo deve ser configurado para ter um número razoável de shards para cada JVM do servidor de contêiner. Por exemplo, uma configuração inadequada seria 2.000 partições com dois shards em execução em quatro Java Virtual Machines de contêiner. Essa configuração resultaria em 4.000 shards distribuídos em quatro Java Virtual Machines de contêiner ou em 1.000 shards por JVM de contêiner.

Uma configuração melhor é 10 shards para cada JVM de contêiner esperada. Essa configuração ainda permite expandir elasticamente 10 vezes a configuração inicial enquanto mantém um número adequado de shards por JVM de contêiner.

Considere este exemplo de ajuste de escala: atualmente há seis servidores físicos com dois Java Virtual Machinesde contêiner por servidor físico. Espera-se um crescimento para 20 servidores físicos nos próximos três anos. Com 20 servidores físicos, você tem 40 Java Virtual Machines de servidor de contêiner e escolhe 60 para ser pessimista. Você quer 4 shards por JVM de contêiner. Existem 60 contêineres potenciais, ou um total de 240 shards. Se tiver um primário e uma réplica por partição, terá 120 partições. Esse exemplo proporciona 240 shards dividido por 12 Java Virtual Machines de contêiner ou 20 shards por JVM de contêiner para uma implementação inicial, podendo efetuar scale out para 20 computadores posteriormente.

ObjectMap e Particionamento

Com a estratégia de posicionamento FIXED_PARTITION padrão, os mapas são divididos em partições e chaves hash para diferentes partições. O cliente não precisa saber à qual partição as chaves pertencem. Se um mapSet tiver vários mapas, os mapas deverão ser confirmados em transações separadas.

Entidades e Particionamento

As entidades do Entity Manager têm uma otimização que ajuda os clientes a trabalharem com entidades em um servidor. O esquema de entidade no servidor para conjunto de mapas pode especificar uma única entidade-raiz. O cliente deve acessar todas as entidades através da entidade-raiz. O gerenciador de entidades pode, então, localizar entidades relacionadas a partir dessa raiz na mesma partição, sem exigir que os mapas relacionados tenham uma chave comum. A entidade-raiz estabelece a afinidade com uma única partição. Essa partição será utilizada por todas as buscas de entidades dentro da transação uma vez estabelecida a afinidade. A afinidade pode economizar memória, visto que os mapas relacionados não precisam de uma chave comum. A entidade-raiz deve ser especificada com uma anotação de entidade modificada, conforme mostrado no exemplo a seguir:
@Entity(schemaRoot=true)
Utilize a entidade para localizar a raiz do gráfico do objeto. O gráfico de objetos define os relacionamentos entre uma ou mais entidades. Cada entidade vinculada deve resolver para a mesma partição. Todas as entidades filha são assumidas como estando na mesma partição que a raiz. As entidades filhas no gráfico de objetos são acessíveis apenas a partir de um cliente da entidade raiz. Entidades-raiz são sempre necessárias nos ambientes particionados ao usar um cliente do eXtreme Scale para se comunicar com o servidor. Apenas um tipo de entidade-raiz pode ser definido por cliente. As entidades raiz não são necessárias ao usar ObjectGrids do estilo Extreme Transaction Processing (XTP) porque todos a comunicação com a partição é feita por meio de acesso direto e local, e não por meio do mecanismo de cliente e servidor.