Partições de Grade de Dados e Shards

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.

Número Total de Shards

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ários: Número de Shards por JVM

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: Como cada shard contém 500 MB de dados, a distribuição de dados é desigual. As sete Java Virtual Machines com dois shards contêm cada uma 1 GB de dados. As duas Java Virtual Machines com três shards possuem 50% mais dados ou 1.5 GB, o que é uma carga de memória muito maior. Como estes dois Java Virtual Machines hospedam três shards, eles também recebem 50% mais solicitações para seus dados. Como resultado, um pequeno número de shards para cada JVM causa desequilíbrio. Para aumentar o desempenho, aumente o número de shards para cada JVM.

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: As duas Java Virtual Machines com 12 shards agora possuem apenas mais 99 MB de dados do que os outros shards, o que é uma diferença de 9%. Este cenário é distribuído muito mais igualmente do que a diferença de 50% no cenário com um pequeno número de shards. De uma perspectiva de uso do processador, apenas 9% de mais trabalho existe para os dois Java Virtual Machines com os 12 shards comparado aos sete Java Virtual Machines que possuem 11 shards. Ao aumentar o número de shards em cada JVM, o uso dos dados e do processador é distribuído de uma maneira proporcional e equilibrada.

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.

Fatores Adicionais de Posicionamento

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.

Os fatores a seguir afetam quando os shards podem ser posicionados:
  • Os comandos xscmd -c suspendBalancing e xscmd -c resumeBalancing.
  • O arquivo de propriedade de servidor, que possui a propriedade placementDeferralInterval que define o número de milissegundos antes de os shards serem posicionados nos servidores de contêiner.
  • O atributo numInitialContainers na política de implementação.

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.