DynamoDB 강력 vs 최종적으로 일관된 읽기

항목을 업데이트하고 즉시 다시 읽어 이전 값을 가져옵니다. 쓰기 성공 — 잠시 후 동일한 읽기가 새 값을 반환합니다. 아무것도 깨지지 않았습니다: DynamoDB의 기본 최종 일관성 읽기에 도달했으며 옵트아웃할 수 있습니다. 요청에 따라.

이는 DynamoDB가 사용자에게 직접 제공하는 몇 안 되는 정확성 노브 중 하나이며, 실제 가격이 붙어있습니다. 올바르게 수행한다는 것은 각 모드가 무엇을 보장하는지, 무엇을 보장하는지 아는 것을 의미합니다. 비용이 많이 들며 강력한 읽기를 사용할 수 없는 경우.

DynamoDB에서 강력한 일관된 읽기와 최종적인 일관된 읽기의 차이점은 무엇입니까?

최종적 일관된 읽기(기본값)는 모든 복제본에서 제공되므로 쓰기 직후 오래된 데이터를 잠시 반환할 수 있지만 비용은 절반 정도입니다. 요청당 ConsistentRead=true로 선택된 강력한 일관된 읽기는 파티션 리더로 라우팅되며 항상 커밋된 모든 쓰기를 반영합니다(읽기 용량의 2배).

• 최종 일관성(기본값) — 직후에 오래된 데이터를 잠시 반환할 수 있습니다. 쓰기. 가장 저렴한 읽기 모드.
• 강력한 일관성 — 읽기 전에 커밋된 모든 쓰기를 항상 반영합니다. 요청에 따라 ConsistentRead=true로 선택하세요.
• 강한 읽기 비용은 최종적으로 2배입니다. 강력한 일관된 읽기는 두 배의 비용을 소비합니다. 동일한 데이터에 대해 최종적으로 일관된 읽기 용량입니다.
• 모든 곳에서는 그렇지 않습니다. 기본 테이블과 로컬 테이블에서 강력한 읽기를 얻습니다. 보조 인덱스. Global Secondary Index는 최종적으로만 적용됩니다 — 선택이 없습니다.
• 기본값은 최종입니다. 방금 작성한 내용을 읽을 때만 강해집니다. 데이터와 순간적으로 오래된 것은 잘못된 것입니다.

문제: 최신 쓰기가 표시되지 않는 읽기

사용자 계정을 운영한다고 가정해 보겠습니다. 사용자가 알림 이메일을 변경하면 앱이 작성합니다. 업데이트가 완료되고 확인 화면에서 즉시 프로필을 다시 읽어서 새 주소. 기본 읽기 모드를 사용하면 해당 다시 읽기는 다음과 같은 복제본에 도달할 수 있습니다. 아직 변경 사항을 받지 못했기 때문에 사용자는 이전 이메일을 보고 저장에 실패했습니다.

창은 작으며(일반적으로 1초 미만) 저절로 닫힙니다. 하지만 "보통 정확함"은 쓰기 후 읽기 확인에 충분하지 않습니다. 그건 바로 강력한 일관성이 존재하는 경우입니다.

최종 일관성이 발생하는 이유

DynamoDB는 모든 파티션을 3개의 스토리지 노드(기본 하나와 두 개)에 저장합니다. 복제본 — 별도의 가용 영역에 걸쳐 있습니다. 쓰기가 실행되면 승인됩니다. 기본 및 하나의 복제본에; 그런 다음 세 번째 노드로 전파됩니다. asynchronously.

로드 분산을 위한 읽기는 세 노드 중 모든 노드에서 제공될 수 있습니다. 결국 일관된 읽기는 아직 가장 최근의 쓰기를 수신하지 않은 노드에 도달할 수 있습니다. 약간 오래된 값을 반환합니다. 강력한 일관성 읽기는 다음으로 라우팅됩니다. 항상 최신 커밋된 데이터를 보유하는 파티션의 리더입니다. 오래된 결과를 반환합니다.

복제 지연이 전체 차이점입니다. 또한 2× 비용에 대해서도 설명합니다. 강력한 읽기는 최종 읽기와는 달리 복제본 간에 로드 밸런싱을 수행할 수 없습니다. DynamoDB는 용량의 두 배 가격을 책정합니다.

구체적인 비용

읽기는 RCU(읽기 용량 단위)로 측정되며 각각 최대 4KB를 포함합니다. RCU 1개 4KB의 강력한 일관된 읽기 1개 또는 최종적 일관된 읽기 2개 구매 아이템. 따라서 핫 읽기 경로에서 ConsistentRead=true을 뒤집으면 읽기 비용이 두 배가 됩니다. 눈에 띄는 품목인 트래픽이 많은 엔드포인트입니다.

다음을 사용하여 자신의 품목 크기와 요청 비율에 대한 차이를 모델링하십시오. DynamoDB pricing calculator 만들기 전에 Strong은 기본값을 읽습니다. 전반적으로 두 번 지불할 가치가 있는 경우는 거의 없습니다.

강력한 읽기가 가능한 경우(또는 불가능한 경우)

GSI는 기본 테이블에서 복제된 자체 데이터 복사본을 유지 관리합니다. 비동기식이므로 강력한 읽기를 제공할 수 없습니다. 접속 패턴이 진짜라면 쓰기 후 읽기가 필요하고 이를 GSI에서 제공할 계획이었다면 이는 신호입니다. 대신 기본 테이블이나 LSI에서 제공합니다.

함정과 다음 단계

• 강력한 읽기를 기본값으로 설정하지 마세요. 대부분의 읽기는 1초 미만의 읽기 시간도 허용합니다. 창; 어디에서나 2배를 지불하는 것은 낭비되는 지출입니다.
• GSI에서 쓰기 후 읽기를 기대하지 마세요. 이는 최종적으로 설계되었습니다. why a GSI is eventually consistent.
• 트랜잭션은 강력하게 읽혀집니다. TransactGetItems는 항상 강력하게 일관됩니다 — DynamoDB transactions를 참조하세요.
• 일관성은 용량과 상호 작용합니다. 2배 승수는 on-demand vs provisioned 비용 계획.

API 호출을 작성하지 않고 DynamoDB 테이블과 인덱스를 탐색하고 싶으십니까? Download DynoTable 데이터를 직접 검사해 보세요.

작동된 RCU 비교

기본 테이블에서 동일한 6KB 항목을 두 번 읽습니다.

초당 1,000회의 읽기에서 강력한 모드 비용은 온디맨드 비용의 약 2배입니다. 최종 모드의 읽기 지출 - 델타를 모델링합니다. pricing calculator 뜨거운 음식을 뒤집기 전에 전역적으로 ConsistentRead=true에 대한 경로입니다.

BatchGetItem 일관성

BatchGetItem의 각 테이블 항목은 ConsistentRead를 독립적으로 설정할 수 있습니다. 에이 사용자 프로필(강력) 및 관련 설정(최종)을 로드하는 대시보드는 하나의 일괄 호출에 플래그를 혼합합니다. 여전히 테이블별 강력한 읽기가 적용됩니다. 가용성 규칙(GSI에서는 강력하지 않음)

애플리케이션 코드에서 쓰기 후 읽기

프로필 업데이트 확인 패턴:

1. UpdateItem 새 이메일로.
2. 기본 테이블에 ConsistentRead: true가 있는 즉시 GetItem.

2단계에서는 최종 읽기 RCU의 2배가 소요되지만 확인이 보장됩니다. 화면이 쓰기와 일치합니다. 백그라운드 집계에 대한 강력한 읽기를 건너뜁니다. 1초 미만의 지연을 허용합니다.

DynoTable 기본값

DynoTable의 탐색적 읽기는 최종적으로 일관된 기본 테이블 쿼리를 사용합니다. 고급 설정에서 더 강력한 의미를 선택하지 않는 한 — 대부분과 일치 대시보드 사용 사례. 쓰기를 준비한 후 항목 편집기 새로 고침이 표시됩니다. 별도의 일관성 없이 성공적인 응답에서 커밋된 값 공통 경로로 전환합니다.

query builder을 사용하여 다음과 같은 샘플 판독값을 내보냅니다. ConsistentRead SDK 코드를 필요한 서비스에 복사할 때 명시적으로 설정됩니다. 쓰기 후 읽기가 보장됩니다.

전역 테이블 참고

글로벌 테이블은 리전 간에 비동기식으로 복제됩니다. 강력한 일관성이 적용됩니다. 전역이 아닌 한 지역의 복제본 내에서. us-east-1의 쓰기는 그렇지 않습니다. eu-west-1에서는 즉시 강력한 읽기가 가능합니다. 이에 따라 지역 간 UX를 계획하세요. 복제 지연 예상은 global tables를 참조하세요.