프로비저닝 된 읽기 용량 단위가 1 개만 있으면 DynamoDB 스캔이 빠른 이유는 무엇입니까?
각 항목의 크기가 4KB 미만인 1346 개의 항목이있는 테이블을 만들었습니다. 읽기 용량 단위 1 개를 프로비저닝 했으므로 초당 평균 1 개 항목 읽기를 기대합니다. 그러나 모든 1346 항목을 간단히 스캔하면 거의 즉시 반환됩니다.
내가 여기서 무엇을 놓치고 있습니까?
답변
이는 버스트 가능한 작업 (예 : 전체 테이블 스캔)에 사용하기 위해 300 초 동안 용량을 확보하는 버스트 용량 때문일 수 있습니다.
이는 이러한 크레딧을 모두 사용하면 사용 가능한 용량이 충분하지 않아 다른 상호 작용에 어려움을 겪을 수 있음을 의미합니다.
CloudWatch 지표를 통해 또는 DynamoDB 인터페이스 자체에서 (Metrics 탭을 통해) 소비 된 WCU / RCU의 양을 볼 수 있습니다.
"각 항목이 4KB 미만"이라고 말하는 것 외에는 항목 크기를 지정하지 않습니다. 얼마나 적습니까?
1 RCU는 최대 4KB의 항목에 대해 초당 2 개의 최종 일관성 읽기를 지원합니다.
다시 말해, 1 개의 RCU와 최종적으로 일관된 읽기를 사용하면 초당 8KB의 데이터를 읽을 수 있습니다.
레코드가 4KB이면 2 개 레코드 / 초
1KB, 8 / 초
512B, 16 / 초
256B, 32 / 초 를 얻습니다.
따라서 이미 언급 한 "버스트"기능을 통해 55 RCU를 사용할 수 있습니다. 하지만 레코드 크기가 작아서 55 RCU가 "거의 즉시"데이터를 반환 할 수있었습니다.
여기에서 유리하게 작동하는 두 가지가 있습니다. 하나는 Scan작은 항목에 대해 생각했던 것보다 훨씬 적은 RCU를 작업에 사용한다는 것입니다. 다른 것은 "버스트 용량"입니다. 두 가지를 모두 설명하겠습니다.
DynamoDB의 가격 페이지는 "최대 크기 4킬로바이트에 항목의 경우, 하나의 RCU 초당이 개 결국 일관된 읽기 요청을 수행 할 수 있습니다."라고 말한다. 이는 항목의 크기가 10 바이트 인 경우에도 최종 일관성으로 항목을 읽는 데 RCU의 절반이 든다는 것을 의미합니다. 그들이이 어디를 명시하지 않지만 그러나,이 비용은 단지 A에 대한 진정한 GetItem작업이 하나의 항목을 검색 할 수 있습니다. A의 Scan또는 Query, 당신이 각 개별 항목에 대해 별도로 지불하지 않는 것으로 나타났다. 대신 이러한 작업은 디스크에 저장된 데이터를 순차적으로 스캔하므로 읽은 데이터 양에 대한 비용을 지불합니다. 1000 개의 작은 항목과 DynamoDB가 디스크에서 읽어야했던 총 크기가 80KB 인 경우, 500 개의 RCU가 아닌 80KB / 4KB / 2 또는 10 개의 RCU를 지불하게됩니다.
이것은 1346 개의 항목을 읽고 1346/2 = 673이 아닌 55 개의 RCU 만 측정 한 이유를 설명합니다.
두 번째로 유리한 점은 DynamoDB에 여기 에 설명 된 "버스트 용량"기능이 있다는 것입니다 .
DynamoDB는 현재 미사용 읽기 및 쓰기 용량을 최대 5 분 (300 초)까지 유지합니다. 가끔씩 읽기 또는 쓰기 활동이 급증하는 동안 이러한 추가 용량 단위는 테이블에 대해 정의한 초당 프로비저닝 된 처리량 용량보다 더 빨리 소모 될 수 있습니다.
따라서 데이터베이스가 요청 전 5 분 동안 존재했다면 DynamoDB는 300 개의 RCU를 절약하여 매우 빠르게 사용할 수 있습니다. 300 개의 RCU는 스캔에 필요한 것보다 훨씬 많기 때문에 (55), 스로틀 링없이 스캔이 매우 빠르게 이루어졌습니다.
쿼리를 수행 할 때 RCU 개수는 읽은 항목 수를 고려 하지 않고 읽은 데이터 양에 적용됩니다 . 따라서 항목이 작은 경우 (예 : 각각 몇 바이트) 단일 4KB RCU 내에서 쉽게 쿼리 할 수 있습니다.
이는 DynamoDB에서 많은 항목을 읽을 때도 특히 유용합니다. 많은 작은 항목을 쿼리하는 것이 BatchGetting보다 훨씬 저렴하고 효율적이라는 것은 당장 분명하지 않습니다.