Uma grade de dados é dividida em partições. Uma partição retém um subconjunto exclusivo de dados. Uma partição contém um ou mais shards: um shard primário e shards de réplicas. Os shards de réplicas não são necessários em uma partição, porém eles podem ser usados para fornecer alta disponibilidade. Independente se sua implementação for uma grade de dados em memória independente ou um espaço de processamento de banco de dados em memória, o acesso aos dados no eXtreme Scale depende fortemente dos shards.
Os dados para uma partição são armazenados em um conjunto de shards no tempo de execução. Este conjunto de shards inclui um shard principal e, possivelmente, um ou mais shards de réplica. Um shard é a menor unidade que o eXtreme Scale pode incluir ou remover de uma Java Virtual Machine.
Há duas estratégias de posicionamento: posicionamento de partição fixo (padrão) e de posicionamento por contêiner. A seguinte abordagem foca o uso da estratégia de posicionamento de partição fixo.
Se seu ambiente inclui 10 partições que contêm 1 milhão de objetos sem réplicas, existirão 10 shards, cada um armazenando 100.000 objetos. Se você incluir uma réplica neste cenário, então, existe um shard extra em cada partição. Neste caso, há 20 shards: 10 shards primários e 10 shards de réplica. Cada um destes shards armazenam 100.000 objetos. Cada partição consiste de um shard primário e uma ou mais (N) shards de réplica. Determinar a contagem de shards ideal é crítica. Se você configurar um pequeno número de shards, os dados não são distribuídos igualmente entre os shards, resultando em erros de falta de memória e problemas de sobrecarga do processador. Pelo menos 10 shards devem existir para cada JVM à medida que escala. Quando estiver implementando inicialmente uma grade de dados, muitas partições poderão ser usadas.
Cenário: pequeno número de shards para cada JVM
Os dados são incluídos e removidos de uma JVM utilizando unidades de shard. Os shards nunca são divididos em partes. Se existirem 10 GB de dados e 20 shards para conterem estes dados, cada shard conterá 500 MB de dados em média. Se nove Java Virtual Machines hospedarem a grade de dados, em média, cada JVM possuirá dois shards. Como 20 não é igualmente divisível por 9, algumas Java Virtual Machines possuem três shards, na seguinte distribuição:Cenário: número aumentado de shards por JVM
Neste cenário, considere um número muito maior de shards. Neste cenário, há 101 shards com nove Java Virtual Machines hospedando 10 GB de dados. Neste caso, cada shard contém 99 MB de dados. A Java Virtual Machines possui a seguinte distribuição de shards:Quando você está criando seu sistema, utilize 10 shards para cada JVM em seu cenário com dimensionamento máximo ou quando o sistema está executando seu número máximo de Java Virtual Machines em seu horizonte de planejamento.
O número de partições, a estratégia de posicionamento e o número e o tipo de réplicas são configurados na política de implementação. O número de shards que são colocados depende da política de implementação definida. Os atributos minSyncReplicas, developmentMode, maxSyncReplicas e maxAsyncReplicas afetam onde as partições e as réplicas são posicionadas.
Se o número máximo de réplicas não for posicionado durante a primeira inicialização, réplicas adicionais poderão ser posicionadas se servidores adicionais forem posicionados posteriormente. Ao planejar o número de shards por JVM, o número máximo de shards primário e de réplicas depende da existência de JVMs suficientes iniciadas para suportar o número máximo de réplicas configurado. Uma réplica nunca é posicionada no mesmo processo que seu primário. Se um processo for perdido, tanto o primário quanto a réplica são perdidos. Quando o atributo developmentMode é configurado como false, o primário e as réplicas não são posicionados no mesmo servidor físico.