Amazon DynamoDB/NoSQL의 적절한 사용 사례입니까?

Question

저는 Amazon Web Services를 많이 사용하는 웹 응용 프로그램에서 작업하고 있습니다. DynamoDB를 응용 프로그램의 특정 부분에 사용하고 싶지만 적절한 유스 케이스인지 확실하지 않습니다.

사이트의 등록 된 사용자가 "작업"을 수행하면 해당 작업에 대한 항목이 기록되고 저장됩니다. 작업에는 관련된 세부 정보가 있지만 가장 관련성있는 것은 각 작업에 고유 한 식별자와 관련 사용자 이름이 있다는 것입니다. 사용자 이름도 고유하지만 당연히 동일한 사용자에 대해 각각 다른 작업 식별자가있는 여러 작업 항목이있을 수 있습니다.

내가이 데이터를 수행 할 필요가 유일한 쿼리는 다음과 같습니다 사용자 이름 X 나에게 모든 작업 항목 (및 관련 정보)를 제공합니다.

DynamoDB 테이블을 만들었지 만 맞는지 확실하지 않습니다. 내 이해는 선택한 해시 키가 테이블에 쿼리/인덱싱에 사용되는 키 여야하지만 항목/행마다 고유해야합니다. 사용자 이름은 내가 질의하고자하는 내용이지만 사용자 이름은 항목/행마다 고유하지 않습니다.

작업 식별자를 기본 해시 키로, 사용자 이름을 보조 인덱스로 설정하면 그 작업이 가능합니까? 보조 색인에 대해 중복 값을 사용할 수 있습니까? 그러나 그것은 내가 테이블의 쿼리/인덱싱을 위해 기본 해시 키를 절대 사용하지 않을 것이라는 것을 의미합니다.

누락되었거나 NoSQL에 적합하지 않습니다.

편집 :
허용 된 대답은 제가뿐만 아니라 this question으로 찾고 있었는지 알 수있었습니다.

Answer 1

는 당신이 요구하는지에 완전히 명확하지 않다,하지만 난 그것을 샷 ... DynamoDB의와

, 당신의 해시 키와 고유 항목을 식별해야합니다 범위 키의 조합을 줄 것이다. 범위 키는 선택 사항입니다. 이를 사용하지 않으면 해시 키만으로 항목을 고유하게 식별해야합니다.

또한 값의 목록 (단일 값이 아닌)을 항목의 속성으로 저장할 수도 있습니다. 예를 들어 각 항목이 사용자를 나타내는 경우 해당 항목의 속성은 해당 사용자의 작업 항목 목록 일 수 있습니다.

DynamoDB 레코드의 크기 제한에 관심이있는 경우 S3를 해당 목록의 백업 저장소로 사용할 수 있습니다. 기본적으로 DDB 항목을 사용하여 주어진 사용자의 전체 목록을 포함하는 S3 리소스에 대한 참조를 저장합니다 . 이렇게하면 다른 속성을 쉽게 쿼리하거나 저장할 수있는 유연성이 제공됩니다. 또는 (답안에서 제안한 것처럼) 전체 사용자의 레코드를 S3에 넣을 수도 있지만 DDB를 통해 쿼리/업데이트를 수행 할 때 유연성과 처리량을 잃을 수 있습니다.

Answer 2

필자는이 질문을 게시하기 전에 오랫동안 충분한 이해를 얻으려면 DynamoDB 콘솔을 사용하지 않았습니다. 필자는 DynamoDB 테이블 (그리고 아마도 다른 NoSQL 테이블)이 실제로는 거대한 사전/해시 데이터 구조라는 것을 이해했을뿐입니다. 그래서 내 질문에 대답, 그래 나는 DynamoDB의를 사용할 수 있으며, 각 항목/행은 다음과 같이 보일 것이다 :

{ 
    "Username": "SomeUser", 
    "Jobs": { 
     "gdjk345nj34j3nj378jh4": { 
      "Status": "Active", 
      "CreationDate": "2014-10-05", 
      "FileRef": "some-reference" 
     }, 
     "ghj3j76k8bg3vb44h6l22": { 
      "Status": "Closed", 
      "CreationDate": "2014-09-14", 
      "FileRef": "another-reference" 
     } 
    } 
} 

을하지만 그것은 모두 그 후 DynamoDB의를 사용하는 경우에도 가치가 확실하지 않다. 그냥 파일 이름이 .json

가 편집 이름 인 S3 버킷에 위의 콘텐츠 구조를 포함하는 JSON 파일을 저장하기 위해 더 간단 할 수 있습니다 그것은 가치가 무엇인지에 대한
가, 난 그냥 것을 깨달았다를 DynamoDB의 아이템에 대한 400KB 크기 제한이 있습니다. 그것은 엄청난 양의 데이터로 비교적 유스 케이스에 대해 말하지만 S3로 가야만 할 수있는 기회를 잡을 수는 없습니다.

Answer 3

아마도 "작업"테이블이 "사용자"테이블보다 나을 것입니다. 여기에 의미하는 바가 있습니다. 당신이 더 많은 같은 테이블에서 개별적으로 작업을 저장하지 왜 400킬로바이트 제한,보다까지 추가 사용자 문서 안에 그 모든 작업에 대해 걱정하는 경우

:

my_jobs_table: 
    { 
     { 
      Username:toby, 
      JobId:1234, 
      Status: Active, 
      CreationDate: 2014-10-05, 
      FileRef: some-reference1 
     }, 
     { 
      Username:toby, 
      JobId:5678, 
      Status: Closed, 
      CreationDate: 2014-10-01, 
      FileRef: some-reference2 
     }, 
     { 
      Username:bob, 
      JobId:1111, 
      Status: Closed, 
      CreationDate: 2014-09-01, 
      FileRef: some-reference3 
     } 
    } 

이름이 해시이며, JobId가 범위입니다. 사용자 이름을 쿼리하여 모든 사용자의 작업을 가져올 수 있습니다.

이제 각 문서의 크기가 제한되어 있으므로 FileRef를 사용하지 않고 S3에서 모든 작업을 모든 데이터를 Dynamo 데이터베이스 레코드에 저장하는 방법을 생각해 볼 수 있습니다. 이렇게하면 대기 시간이 크게 줄어들 것입니다. 다른 사람이 이미 DynamoDB의에서 당신을 잘 봉사 할 것입니다 제안대로, 해시 키와 범위 등의 고유 한 작업 ID로 해당 사용자 이름을 보인다

{ 
    Username:bob, 
    JobId:1111, 
    Status: Closed, 
    CreationDate: 2014-09-01, 
    JobCategory: housework, 
    JobDescription: Doing the dishes, 
    EstimatedDifficulty: Extreme, 
    EstimatedDuration: 9001 
} 

Answer 4

: 같은

각 레코드는 다음 보일 수 있습니다. 쿼리를 사용하면 사용자 이름에 대한 모든 레코드를 빠르게 검색 할 수 있습니다.

또 다른 옵션은 로컬 보조 인덱스와 스파 스 인덱스를 이용하는 것입니다. 상태 열이있는 것 같지만 다른 열 ('not_processed': 'x')을 추가하여 사용자 이름 + not_processed에 로컬 보조 인덱스를 만들 수 있습니다. 이 필드가있는 레코드 만 인덱싱되고 작업이 완료되면이 필드가 삭제됩니다. 즉, 사용자 이름에 대한 색인을 사용하여 not_processed = x에서 효과적으로 표 스캔을 수행 할 수 있습니다. 또한 색인은 작을 것입니다.

내 모든 관계형 DB 경험이 내 이해 dynamodb에 방해가되는 것처럼 보입니다. 행운을 빕니다!