As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Comportamento de gravação em cache
Este guia descreve um cache de leitura em que os itens são armazenados em cache na primeira leitura. Um cache de gravação enviaria entradas para o cache durante a operação de gravação, mas este guia não sugere fazer isso por dois motivos:
-
Quando um item é gravado, não há indicação de que ele será lido em breve, e é um desperdício escrever entradas de cache que não são usadas.
-
Um item que está em cache pode ser armazenado em cache várias vezes com chaves de assinatura diferentes. Por exemplo, diferentes expressões de projeção resultam em diferentes entradas de cache. Portanto, não está claro em qual chave de assinatura você deve armazenar a entrada antes que uma solicitação chegue. Você pode considerar mais elegante armazenar o item em cache somente uma vez em sua totalidade e, se a solicitação especificar um
ProjectionExpression
parâmetro, aplicar a projeção ao vivo dentro do invólucro de cache. Infelizmente, isso adiciona uma complexidade significativa porque requer a implementação de uma gramática não trivialProjectionExpression
. É mais fácil manter o invólucro de cache muito simples para que ele armazene em cache apenas as solicitações que aconteceram anteriormente e tente evitar ao máximo inventar uma nova resposta. Deixe que o banco de dados seja o único lugar em queProjectionExpression
um seja interpretado. Isso elimina um modelo de cache de gravação fácil.
No entanto, as operações de gravação podem ser inteligentes e podem invalidar proativamente quaisquer entradas de cache de itens armazenadas anteriormente que sejam relevantes para o item gravado. Isso mantém o cache do item atualizado sem precisar esperar pela expiração do TTL. A entrada do cache é preenchida novamente na próxima leitura.
nota
Uma vantagem importante dessa integração com o DynamoDB, em comparação com uma integração de cache de banco de dados relacional projetada de forma semelhante, é que cada gravação no DynamoDB sempre especifica as chaves primárias dos itens que estão sendo gravados. Um cache de leitura pode observar as chamadas de gravação e realizar a invalidação exata e imediata do cache de itens. Quando você usa um banco de dados relacional, uma UPDATE
instrução não identifica os itens que podem ser afetados, e não há uma forma passiva de invalidar entradas de linha em cache que não seja por meio de TTL.
As chamadas de gravação implementam esse fluxo lógico:
-
Execute a operação de gravação no banco de dados.
-
Se a operação for bem-sucedida, extraia a tabela e as chaves primárias para a gravação.
-
Invalide todas as entradas do cache de itens que sejam relevantes para as chaves primárias.
É necessário um pouco de limpeza para tornar essa última etapa possível. As entradas do cache de itens são armazenadas sob um hash de sua assinatura, portanto, é necessário saber quais chaves invalidar. Você pode fazer isso mantendo no cache um mapeamento entre as chaves primárias do item e a lista de assinaturas armazenadas associadas a essa chave primária. É essa lista de itens que devem ser invalidados.
Aqui está a tabela anterior:
Pseudocódigo |
ElastiCache cálculo da chave |
ElastiCache valor |
---|---|---|
|
|
|
|
|
|
|
|
|
E a tabela de limpeza anterior:
Operação |
ElastiCache cálculo da chave |
ElastiCache valor |
---|---|---|
Rastreie a lista de entradas para tabela |
|
( |
Rastreie a lista de entradas para tabela |
|
( |
Vamos supor que haja uma operação de gravação na tabela t1
e que o item tenha a chave primáriak1
. A próxima etapa é invalidar as entradas relevantes para esse item.
Aqui está a lógica completa:
-
Execute a operação de gravação no banco de dados.
-
Se a operação for bem-sucedida, extraia a tabela e a chave primária para a gravação.
-
Extraia do cache a lista de assinaturas de hash armazenadas associadas a essa chave primária.
-
Invalide essas entradas de cache de itens.
-
Exclua a lista de manutenção dessa chave primária.
Seria fantástico ter uma maneira de invalidar proativamente as entradas do cache de consultas como parte das operações de gravação de itens. No entanto, inventar um design para isso é extremamente difícil porque é quase impossível determinar, de forma eficiente e confiável, quais resultados de consultas em cache seriam afetados por um item atualizado. Por esse motivo, as entradas do cache de consultas não têm melhor opção do que expirar por meio das configurações de TTL.