캐시 읽기 동작

심은 DynamoDB에 대한 최종적으로 일관된 읽기 호출만 캐싱해야 합니다. 여기에 get_item, batch_get_item, query 및 scan도 추가되었습니다. 강력히 일관된 읽기 호출 또는 트랜잭션 읽기 호출을 캐싱해서는 안 됩니다. 이러한 호출은 본질적으로 캐시된 버전의 데이터를 보고 싶지 않기 때문입니다.

캐시 항목은 후속 요청과 동등한 요청을 식별하기 위해 요청의 서명을 이해해야 합니다. 각 호출의 서명은 결과에 영향을 미치는 요청의 모든 파라미터로 구성됩니다. get_item 호출의 경우 서명에는 , TableName, Key ProjectionExpression및 ExpressionAttributeNames 파라미터가 포함됩니다. 쿼리 호출의 경우 , TableName, IndexName, KeyConditionsFilterExpression, ScanIndexForward및 Limit 파라미터가 포함됩니다. 동일한 함수에 대한 두 호출의 서명이 동일한 경우 캐시 적중 가능성이 있습니다.

다음은 get_item 호출에 대한 샘플 로직 흐름입니다.

예를 들어이 코드가 있다고 가정합니다.

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

내부에서 cache_client코드는 호출의 해시 서명을 계산합니다. 서명은 TableName, Key, ProjectionExpression및 ExpressionAttributeNames 파라미터의 연결을 해싱하여 파생됩니다. 결정적이고 단일 문자열 값을 생성하는 한 모든 해시 시스템을 사용할 수 있습니다. 이 경우 로 해시한다고 가정해 보겠습니다0xad4c812a. 이 해시는이 파라미터 세트를 식별합니다.

이름이 변경된를 제외하고 동일한 다른 호출#attr1이 수행되면 어떻게 되나요#attribute1? 해당 호출의 서명이 동일한 것으로 간주해야 합니까? 의미상 동일하지만 모든 호출에서 의미론적 동등성을 파악하는 데 드는 오버헤드는 실용적이지 않기 때문에 가장 좋습니다. 파라미터 값을 시각적으로 해시하는 것이 훨씬 빠르며 정확한 일치가 필요합니다. 규칙은 호출이 실제로 동일한 호출인 경우 캐시 적중을 받을 수 있지만 기본적으로 동일한 호출인 경우에는 그렇지 않습니다.

내부에서 cache_client코드는 ElastiCache에서 아래에 저장된 항목 캐시의 항목을 찾습니다0xad4c812a. 항목이 있는 경우 캐시 적중입니다. 그렇지 않은 경우 값은 데이터베이스에서 가져오고 나중에 캐시 적중을 위해 ElastiCache에 저장됩니다.

다음은 세 가지 테이블, 키 및 프로젝션 파라미터 세트가 있는 세 가지 get_item 호출에 대한 캐시의 모습입니다.

query 및와 같은 다른 호출은 동일한 방식으로 scan작동하지만 다른 파라미터가 서명을 구성합니다.

이 설계는 HTTP 캐싱 프록시의 작동 방식을 상기시킬 수 있습니다. 동일한 요청이 다시 표시되면 이전 요청의 응답을 반환할 수 있습니다. HTTP에서 동일한 요청의 정의는 대부분 쿼리 문자열을 기반으로 합니다. DynamoDB를 사용하면 함수에 전달되는 호출 유형과 파라미터 세트가 결과에 영향을 미칩니다.

한 단계가 더 있습니다. 항목 캐싱은 각 항목의 기본 키와 해당 항목을 캐싱하는 데 적극적으로 사용되는 해시 목록 간의 매핑을 유지하는 것이 중요합니다. 이는 다음 섹션에 설명된 대로 쓰기 작업 중에 재생됩니다. 따라서 이전 키 및 값 외에도 다음과 같은 추가 캐시 항목이 있습니다.