DynamoDB의 로컬 인덱스와 글로벌 인덱스의 차이점

이 두 개의 보조 인덱스와 차이점에 대해 궁금합니다. 이것이 어떻게 생겼는지 상상하기 어렵습니다. 그리고 이것은 저보다 더 많은 사람들을 도울 것이라고 생각합니다.

로컬 보조 인덱스는 여전히 원래 해시 키를 사용합니다. 해시 + 범위가있는 테이블을 제공 할 때 LSI를 hash + range1, hash + range2 .. hash + range6으로 생각하십시오. 쿼리 할 범위 속성이 5 개 더 있습니다. 또한 프로비저닝 된 처리량은 하나뿐입니다.

Global Secondary Indexes는 인덱스마다 다른 해시 / 범위 키인 새로운 패러다임을 정의합니다.
이로 인해 테이블 ​​당 하나의 해시 키 사용이 중단됩니다. 이것이 GSI를 정의 할 때 인덱스 당 프로비저닝 된 처리량을 추가하고 비용을 지불해야하는 이유이기도합니다.

차이점에 대한 자세한 정보는 GSI 발표 에서 찾을 수 있습니다

다음은 설명서의 공식적인 정의입니다.

Global secondary index — 테이블과 다를 수있는 해시 및 범위 키가있는 인덱스입니다. 인덱스의 쿼리는 모든 파티션에 걸쳐 테이블의 모든 데이터에 걸쳐있을 수 있으므로 글로벌 보조 인덱스는 "글로벌"로 간주됩니다.

Local secondary index — 테이블과 동일한 해시 키는 있지만 범위 키는 다른 인덱스입니다. local secondary index는 local secondary index의 모든 파티션이 동일한 해시 키를 갖는 테이블 파티션으로 범위가 지정된다는 점에서 "로컬"입니다.

그러나 차이점은 주요 정의 측면에서 가능성을 넘어 섭니다. 인덱스 유지 관리 비용과 노력에 직접적인 영향을 미치는 몇 가지 중요한 요소를 아래에서 찾으십시오.

• 처리량 :

로컬 보조 인덱스는 테이블에서 처리량을 소비합니다. 로컬 인덱스를 통해 레코드를 쿼리하면 테이블에서 읽기 용량 단위가 소비됩니다. 로컬 인덱스가있는 테이블에서 쓰기 작업 (만들기, 업데이트, 삭제)을 수행하면 두 개의 쓰기 작업이 있습니다. 하나는 테이블에 대한 것이고 다른 하나는 인덱스에 대한 것입니다. 두 작업 모두 테이블에서 쓰기 용량 단위를 소비합니다.

글로벌 보조 인덱스는 자체 프로비저닝 된 처리량을 가지며 인덱스를 쿼리 할 때 인덱스에서 읽기 용량을 소비하는 작업, 글로벌 인덱스가있는 테이블에서 쓰기 작업 (생성, 업데이트, 삭제)을 수행하면 두 가지가 있습니다. 쓰기 작업, 테이블 하나, 인덱스 *

* Global Secondary Index의 프로비저닝 처리량을 정의 할 때는 다음 요구 사항에 특히주의해야합니다.

테이블 쓰기가 성공하려면 테이블 및 모든 글로벌 보조 인덱스에 대해 프로비저닝 된 처리량 설정에 쓰기를 수용 할 수있는 충분한 쓰기 용량이 있어야합니다. 그렇지 않으면 테이블에 대한 쓰기가 제한됩니다.

• 관리 :

로컬 보조 인덱스는 테이블을 생성 할 때만 생성 할 수 있으며, 기존 테이블에 로컬 보조 인덱스를 추가 할 수 없으며 인덱스를 생성 한 후에는 삭제할 수 없습니다.

테이블을 생성하고 기존 테이블에 추가 할 때 글로벌 보조 인덱스를 만들 수 있으며 기존 글로벌 보조 인덱스를 삭제할 수도 있습니다.

• 일관성을 읽으십시오 :

지역 보조 인덱스는 최종 또는 강력한 일관성을 지원하는 반면, 글로벌 보조 인덱스는 최종 일관성 만 지원합니다.

• 투사:

로컬 보조 인덱스를 사용하면 인덱스에 투영되지 않은 속성을 검색 할 수 있습니다 (추가 비용이 들더라도 성능 및 소비 용량 단위). Global Secondary Index를 사용하면 인덱스에 투영 된 속성 만 검색 할 수 있습니다.

보조 인덱스에 정의 된 키의 고유성에 대한 특별 고려 사항 :

로컬 보조 인덱스에서 범위 키 값은 주어진 해시 키 값에 대해 고유하지 않아도되며, 글로벌 보조 인덱스에도 동일하게 적용되며 키 값 (해시 및 범위)은 고유하지 않아도됩니다.

출처 : http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

다음은 색인별로 가능한 검색입니다.

• 해시
• 해시 + 범위
• 해시 + 로컬 인덱스
• 글로벌 인덱스
• 글로벌 인덱스 + 범위 인덱스

테이블의 해시 및 범위 인덱스 : 이전 버전의 Amazon AWS SDK의 일반적인 인덱스입니다.

글로벌 및 로컬 인덱스 : 테이블의 기존 해시 및 범위 인덱스 외에 테이블에 생성 된 '추가'인덱스입니다. 글로벌 인덱스 는 해시와 유사합니다. 범위 색인 은 테이블의 해시와 함께 사용되는 범위 색인과 유사하게 작동합니다. 코드의 엔티티 모델에서 getter는 다음과 같이 주석을 달아야합니다.

• 글로벌 인덱스의 경우 :

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• 글로벌 인덱스와 관련된 범위 인덱스의 경우 :

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

또한 글로벌 인덱스로 테이블을 읽는 경우 결과 읽기 (일관된 읽기 아님) 여야합니다.

queryExpression.setConsistentRead(false);

그것을 넣는 한 가지 방법은 다음과 같습니다.

LSI-여러 개의 다른 속성을 사용하여 쿼리를 "필터링"하거나 제한하는 동안 단일 해시 키에서 쿼리를 수행 할 수 있습니다.

GSI-테이블의 여러 해시 키에 대한 쿼리를 수행 할 수 있지만 결과적으로 처리량이 추가로 증가합니다.

테이블 유형과 작동 방식에 대한보다 광범위한 분석은 다음과 같습니다.

해시 만

아마 이미 알고 있듯이; 이미 존재하는 해시 키에 쓰면 기존 데이터를 덮어 쓰므로 해시 키 자체는 고유해야합니다.

해시 + 범위

해시 키 + 범위 키를 사용하면 범위 키가 다른 한 동일한 해시 키를 여러 개 가질 수 있습니다. 이 경우 이미 존재하는 해시 키에 쓰지만 해당 해시 키에 의해 아직 사용되지 않은 범위 키를 사용하면 새 항목을 만드는 반면 해시 + 범위 조합이 동일한 항목은 이미 존재하는 경우 일치하는 항목을 덮어 씁니다.

이것을 생각하는 또 다른 방법은 형식의 파일과 같습니다. 형식 (범위)이 다른 한 동일한 폴더 (테이블)에서 다른 폴더와 이름이 같은 파일 (해시)을 가질 수 있습니다. 마찬가지로, 이름이 다른 한 동일한 형식의 파일을 여러 개 가질 수 있습니다.

LSI

LSI는 기본적으로 해시 키 + 범위 키와 동일하며 항목을 만들 때와 동일한 규칙을 따릅니다. 단, LSI에도 값을 제공해야합니다. 비워 둘 수 없습니다.

:는 LSI는 "범위-키 2"라고하려면 명명 된 파일 (이전에서 내 파일 형식 비유를 사용)하지 수 완전히 정확하지 않습니다 file.format.lsi와 file.format.lsi2. 당신은, 그러나, 수 file.format.lsi및 file.format2.lsi또는 file.format.lsi과 file2.format.lsi.

기본적으로 LSI는 실제 범위 키가 아닌 "필터 키"일뿐입니다. 기본 해시 및 범위 값 조합은 여전히 ​​고유해야하지만 LSI 값은 고유하지 않아도됩니다. 보다 쉽게 ​​볼 수있는 방법은 LSI를 파일 내의 데이터로 생각하는 것입니다. "PROJECT101"이라는 이름의 파일을 모두 찾은 fileFormat다음 내부 데이터를 읽어서 쿼리에 포함되어야 하는 파일과 생략 된 파일을 확인하는 코드를 작성할 수 있습니다. 이것은 기본적으로 LSI의 작동 방식입니다 (파일 내용을 읽기 위해 파일을 여는 오버 헤드없이).

GSI

GSI의 경우 기본적으로 각 GSI에 대해 다른 테이블을 작성하지만 그 사이에 데이터를 미러링하는 여러 개의 별도 테이블을 유지 관리해야하는 번거 로움이 없습니다. 이것이 더 많은 처리량을 요구하는 이유입니다.

따라서 GSI의 경우 fileName기본 해시 키 및 fileFormat기본 범위 키로 지정할 수 있습니다. 그런 다음 해시 키 fileName2와 범위 키가있는 GSI를 지정할 수 있습니다 fileFormat2. 에 대해서만 쿼리 할 수있는 LSI와 달리 원하는 경우 fileName또는 원하는 fileName2경우 쿼리 할 수 ​​있습니다 fileName.

주요 장점은 2 개 대신 하나의 테이블 만 유지하면되고 기본 해시 / 범위 또는 GSI 해시 / 범위에 쓸 때마다 다른 테이블도 자동으로 업데이트된다는 것입니다. 따라서 다중 테이블 설정으로 할 수있는 것처럼 다른 테이블을 업데이트하는 것을 "잊어 버릴"수 없습니다. 또한 멀티 테이블 설정과 같이 하나를 업데이트 한 후 다른 하나를 업데이트하기 전에 연결이 끊어 질 가능성이 없습니다.

또한 GSI는 기본 해시 / 범위 조합을 "중복"할 수 있습니다. 당신이 테이블을 만들고 싶어한다면 fileName및 fileFormat기지 해시 / 레인지와로 filePriority와 fileName당신의 GSI, 당신은 할 수 있습니다.

마지막으로 GSI Hash + Range 조합은 고유하지 않아도되며 기본 Hash + Range 조합은 고유해야합니다. 이것은 듀얼 / 멀티 테이블 설정으로는 불가능하지만 GSI에서는 가능합니다. 결과적으로 업데이트 할 때 기본 및 GSI Hash + Range 모두에 대한 값을 제공해야합니다. 이 값 중 어느 것도 비워 둘 수 없습니다.

설명하는 또 다른 방법 : LSI를 사용하면 동일한 해시 키가있는 항목에 대해 추가 쿼리를 수행 할 수 있습니다. GSI를 사용하면 "테이블에서"항목에 대해 유사한 쿼리를 수행 할 수 있습니다. 매우 유용합니다.

사용자 프로필 테이블이있는 경우 : 고유 ID, 이름, 이메일. 여기서 이름, 이메일로 테이블을 쿼리 가능하게 만들어야하는 경우 유일한 방법은 테이블을 GSI로 만드는 것입니다 (LSI가 도움이되지 않음).

이 문서는 꽤 좋은 설명을 제공합니다.

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

이 질문에 대해서는 언급 할 수 없었지만 쓰기 및 읽기 성능면에서 더 좋습니다.

(테이블 읽기 및 쓰기 처리량이 100 인 로컬 인덱스) 또는 (테이블의 읽기 / 쓰기 처리량이 50? 인 읽기 / 쓰기 처리량이 50 인 글로벌 인덱스)

유스 케이스에 별도의 파티션 키가 필요하지 않으므로 필요한 기능을 위해 로컬 인덱스로 충분해야합니다.

일관성있는 읽기에는 GSI를 사용할 수 없습니다.

LSI는 일관된 읽기에 사용될 수 있지만 주 파티션 크기는 10GB로 제한됩니다. 또한 LSI는 테이블 작성시에만 작성할 수 있습니다.