Comportamento de leitura do cache

O shim deve armazenar em cache somente as chamadas de leitura eventualmente consistentes feitas para o DynamoDB. Isso inclui get_item, batch_get_item, query e scan. Ele não deve armazenar em cache chamadas de leitura fortemente consistentes ou chamadas de leitura transacionais, porque essas chamadas inerentemente não querem ver uma versão em cache dos dados.

As entradas do cache devem compreender a assinatura da solicitação para identificar solicitações subsequentes equivalentes. A assinatura de cada chamada consiste em todos os parâmetros da solicitação que afetam o resultado. Para uma get_item chamada, a assinatura inclui os ExpressionAttributeNames parâmetros TableName KeyProjectionExpression,, e. Para uma chamada de consulta, ela inclui os TableName Limit parâmetros IndexName KeyConditionsFilterExpression,ScanIndexForward,,, e. Se duas chamadas para a mesma função tiverem a mesma assinatura, isso é uma possível ocorrência de cache.

Aqui está um exemplo de fluxo lógico para uma get_item chamada:

Por exemplo, suponha que você tenha esse código:

cache_client.get_item(
  TableName='test',
  Key={ 'PK': { 'S': '123' } },
  ProjectionExpression='#attr1, #attr2',
  ExpressionAttributeNames={
    '#attr1': 'agent',
    '#attr2': 'count'
  },
  ConsistentRead=False
)

No interiorcache_client, o código calcula a assinatura hash da chamada. A assinatura é derivada do hashing da concatenação dos parâmetrosTableName,Key, e. ProjectionExpression ExpressionAttributeNames Qualquer sistema de hash pode ser usado, desde que seja determinístico e produza um único valor de string. Nesse caso, vamos supor que se reduza a0xad4c812a. Esse hash identifica esse conjunto de parâmetros.

E se outra chamada for feita da mesma forma, exceto que ela #attr1 seja renomeada#attribute1? Essa chamada deve ser considerada como tendo a mesma assinatura? Idealmente, sim, porque é semanticamente idêntico, mas a sobrecarga de descobrir a equivalência semântica em cada chamada simplesmente não é prática. É muito mais rápido fazer o hash dos valores dos parâmetros às cegas e exigir correspondências exatas. A regra é: as chamadas são elegíveis para um cache hit se forem realmente a mesma chamada, mas não se forem basicamente a mesma chamada.

No interiorcache_client, o código então ElastiCache procura uma entrada no cache de itens que está armazenada em0xad4c812a. Se a entrada existir, isso é um hit no cache. Caso contrário, o valor é obtido do banco de dados e armazenado ElastiCache para uma visita posterior ao cache.

Veja a aparência do cache para três get_item chamadas que têm três conjuntos diferentes de parâmetros de tabela, chave e projeção.

Outras chamadas, como query escan, funcionam da mesma forma, mas parâmetros diferentes compõem suas assinaturas.

Esse design pode lembrá-lo de como funciona um proxy de cache HTTP. Se ele ver a mesma solicitação novamente, ele poderá retornar a resposta da solicitação anterior. A definição da mesma solicitação em HTTP é baseada principalmente na string de consulta. Com o DynamoDB, o tipo de chamada e o conjunto de parâmetros que são passados para a função influenciam seus resultados.

Há mais uma etapa. É importante que o armazenamento em cache de itens mantenha um mapeamento entre a chave primária de cada item e a lista de hashes usados ativamente para armazenar esse item em cache. Isso entrará em ação durante as operações de gravação, conforme descrito na próxima seção. Portanto, além das chaves e valores anteriores, haverá entradas extras de cache, como estas: