Plug-in do Cache JPA Nível 2 (L2)

O WebSphere eXtreme Scale inclui plug-ins de cache de nível 2 (L2) para ambos os provedores OpenJPA e Hibernate Java Persistence API (JPA). Quando você usar um desses plug-ins, seu aplicativo usará a API do JPA. Uma grade de dados é introduzida entre o aplicativo e o banco de dados, melhorando os tempos de resposta.

Usar o eXtreme Scale como um provedor de cache L2 aumenta o desempenho na leitura e consulta de dados e reduz a carga para o banco de dados. O WebSphere eXtreme Scale tem vantagens sobre as implementações de cache integradas porque o cache é automaticamente replicado entre todos os processos. Quando um cliente armazena em cache um valor, todos os outros clientes conseguem usar o valor armazenado em cache que está localmente na memória.

É possível configurar a topologia e as propriedades para o provedor de cache L2 no arquivo persistence.xml. Para obter mais informações sobre como configurar essas propriedades, consulte Propriedades de Configuração do Cache JPA.

Dica: O plug-in do cache JPA L2 requer um aplicativo que usa as APIs do JPA. Se desejar usar as APIs do WebSphere eXtreme Scale para acessar uma origem de dados JPA, use o carregador JPA. Para obter informações adicionais, consulte Carregadores JPA.

Considerações sobre Topologia de Cache do JPA L2

Os fatores a seguir afetam qual tipo de topologia configurar:
  1. Quantos dados você espera que sejam armazenados em cache?
  2. Qual é a proporção de "leitura para gravação" esperada?
    A proporção de "leitura para gravação" afeta o desempenho do cache L2. Cada topologia manipula as operações de leitura e gravação de forma diferente. Aplicativos que são principalmente somente leitura devem usar topologias integradas e intradomínio quando possível. Aplicativos que executam mais gravação devem usar topologias intradomínio.
  3. Qual é a porcentagem de dados consultados versus localizados por uma chave?

    Quando ativadas, as operações de consulta usam o cache de consulta de JPA. Ative o cache de consulta de JPA somente para aplicativos com altas proporções de leitura para gravação, por exemplo quando você está se aproximando de 99% de operações de leitura. Se você usar o cache de consulta de JPA, deverá usar o Topologia Integrada ou Topologia Intradomínio.

    A operação de localização por chave busca uma entidade de destino se a entidade de destino não tem nenhum relacionamento. Se a entidade de destino tiver relacionamentos com o tipo de busca EAGER, esses relacionamentos serão buscados juntamente com a entidade de destino. No cache de dados de JPA, a busca desses relacionamentos faz com que alguns acertos do cache obtam todos os dados de relacionamento.

  4. Qual é o nível de deterioração tolerado dos dados?

    Em um sistema com algumas JVMs, existe latência de replicação de dados para operações de gravação. O objetivo do cache é manter uma visualização de dados sincronizados final entre todas as JVMs. Quando você estiver usando a topologia intradomínio, existirá um atraso de replicação de dados para operações de gravação. Aplicativos que usam essa topologia devem ser capazes de tolerar leituras antigas e gravações simultâneas que podem sobrescrever os dados.

Topologia Intradomínio

Com uma topologia intradomínio, os shards primários são posicionados em cada servidor de contêiner na topologia. Esses shards primários contêm o conjunto completo de dados para a partição. Qualquer um desses shards primários também podem concluir as operações de gravação em cache. Essa configuração elimina o gargalo na topologia integrada na qual todas as operações de gravação de cache deve passar por um shard primário único.

Em uma topologia intradomínio, nenhum shard de réplica é criado, mesmo se as réplicas tiverem sido definidas em seus arquivos de configuração. Cada shard primário redundante contém uma cópia completa dos dados, de modo que cada shard primário também pode ser considerado como um shard de réplica. Essa configuração usa uma única partição, semelhante à topologia integrada.

Figura 1. Topologia de Intradomínio do JPA
Topologia particionada integrada do JPA
As propriedades de configuração de cache JPA relacionadas para a topologia intradomínio são:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING

Vantagens:

  • As leituras e atualizações do cache serão locais.
  • Simples para configurar.

Limitações:

  • Essa topologia é mais adequada para quando os servidores de contêiner puderem conter o conjunto inteiro de dados da partição.
  • Os shards de réplica, mesmo se estiverem configurados, nunca são posicionados porque cada servidor de contêiner hospeda um shard primário. No entanto, todos os shards primários são replicados com os outros shards primários, portanto, esses shards primários se tornam réplicas entre si.

Topologia Integrada

Dica: Considere usar uma topologia intradomínio para obter melhor desempenho.

Uma topologia integrada cria um servidor de contêiner dentro do espaço do processo de cada aplicativo. O OpenJPA e o Hibernate lêem a cópia na memória do cache diretamente e gravam para todas as outras cópias. É possível melhorar o desempenho de gravação usando replicação assíncrona. Esta topologia padrão executa melhor quando a quantidade de dados armazenados em cache é pequena o suficiente para ajustar-se a um único processo. Com uma topologia integrada, crie uma única partição para os dados.

Figura 2. Topologia Integrado do JPA
Topologia integrada do JPA
As propriedades de configuração de cache JPA relacionadas para a topologia integrada são:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=num_replicas,ReplicaMode=SYNC | ASYNC | NONE
Vantagens:
  • Todas as leituras de cache são acessos locais rápidos.
  • Simples para configurar.
Limitações:
  • A quantidade de dados é limitada ao tamanho do processo.
  • Todas as atualizações de cache são enviadas por meio de um shard primário, que cria um gargalo.

Topologia Integrada e Particionada

Dica: Considere usar uma topologia intradomínio para obter melhor desempenho.
CUIDADO:
Não use o cache de consulta de JPA com uma topologia particionada integrada. O cache de consulta armazena os resultados da consulta que são uma coleção de chaves de entidade. O cache de consulta busca todos os dados da entidade do cache de dados. Como o cache de dados é dividido entre diversos processos, essas chamadas adicionais podem negar os benefícios do cache L2.

Quando os dados em cache são muito grandes para se ajustarem em um único processo, é possível usar a topologia particionada integrada. Esta topologia divide os dados sobre diversos processos. Os dados são divididos entre os shards primários, portanto, cada shard primário contém um subconjunto dos dados. Ainda é possível usar esta opção quando a latência do banco de dados é alta.

Figura 3. Topologia Particionada Integrada do JPA
Topologia particionada integrada do JPA
As propriedades de configuração de cache do JPA relacionadas à topologia particionada integrada são:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=num_partitions,ReplicaReadEnabled=TRUE | FALSE

Vantagens:

  • Armazena grandes quantidades de dados.
  • Simples para configurar
  • As atualizações de cache são propagadas para vários processos.

Limitação:

  • A maioria das leituras e atualizações de cache é remota.

Por exemplo, para armazenar em cache 10 GB de dados com um máximo de 1 GB por JVM, 10 Java Virtual Machines são necessários. Portanto, o número de partições deve ser configurado para 10 ou mais. De maneira ideal, o número de partições deve ser configurado com um número primo no qual cada shard armazena uma quantidade razoável de memória. Geralmente, a configuração de numberOfPartitions é igual ao número de Java Virtual Machines. Com esta configuração, cada JVM armazena uma partição. Se você ativar replicação, será necessário aumentar o número de Java Virtual Machines no sistema. Caso contrário, cada JVM também armazenará uma partição de réplica, que consome tanta memória quanto uma partição primária.

Leia sobre oDimensionamento de Memória e Cálculo de Contagem de Partições para aumentar o desempenho de sua configuração escolhida.

Por exemplo, em um sistema com quatro Java Virtual Machines e com o valor da configuração de numberOfPartitions de 4, cada JVM hospeda uma partição primária. Uma operação de leitura tem 25% mais chance de buscar dados de uma partição disponível localmente, o que é muito mais rápido comparado ao obter dados de uma JVM remota. Se uma operação de leitura, como a execução de uma consulta, precisar buscar uma coleta de dados que envolva 4 partições igualmente, 75% das chamadas são remotas e 25% das chamadas são locais. Se a configuração de ReplicaMode for definida para SYNC ou ASYNC e a configuração de ReplicaReadEnabled for definida para true, as quatro partições de réplica são criadas e espalhadas pelos quatro Java Virtual Machines. Cada JVM hospeda uma partição primária e uma partição de réplica. A chance de que a operação de leitura execute localmente aumenta em 50%. A operação de leitura que busca uma coleta de dados que envolve quatro partições igualmente tem somente 50% de chamadas remotas e 50% de chamadas locais. Chamadas locais são muito mais rápidas do que chamadas remotas. Sempre que ocorrem chamada remotas, o desempenho cai.

Topologia Remota

CUIDADO:
Não use o cache de consulta de JPA com uma topologia remota. O cache de consulta armazena os resultados da consulta que são uma coleção de chaves de entidade. O cache de consulta busca todos os dados da entidade do cache de dados. Como o cache de dados é remoto, estas chamadas adicionais podem negar os benefícios do cache L2.
Dica: Considere usar uma topologia intradomínio para obter melhor desempenho.

Uma topologia remota armazena todos os dados armazenados em cache em um ou mais processos separados, reduzindo o uso da memória dos processos do aplicativo. É possível obter vantagem da distribuição de dados em processos separados ao implementar uma grade de dados replicada e particionada do eXtreme Scale. Ao contrário das configurações integradas e particionadas integradas descritas nas seções anteriores, se desejar gerenciar a grade de dados remota, você deverá fazer isso independente do aplicativo e do provedor JPA.

Figura 4. Topologia Remota do JPA
Topologia remota do JPA
As propriedades de configuração de cache JPA relacionadas à topologia remota são:
ObjectGridName=objectgrid_name,ObjectGridType=REMOTE

O tipo de ObjectGrid REMOTE não requer nenhuma configuração de propriedade porque a política de ObjectGrid e de implementação é definida separadamente a partir do aplicativo JPA. O plug-in do cache JPA conecta-se remotamente a um ObjectGrid remoto existente.

Como toda a interação com o ObjectGrid é remota, essa topologia possui o menor desempenho entre todos os tipos de ObjectGrid.

Vantagens:

  • Armazena grandes quantidades de dados.
  • O processo aplicativo é livre de dados em cache.
  • As atualizações de cache são propagadas para vários processos.
  • Opções de configuração flexíveis.

Limitação:

  • Todas as leituras e atualizações de cache são remotas.