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