아마존 다이너모DB

Amazon Dynamo
아마존 다이너모
DynamoDB.png
개발자아마존 닷컴.
초기 릴리즈2012년 1월, 10년 전(2012-01)[1]
운영 체제크로스 플랫폼
이용가능기간:영어
유형
면허증.독자 사양
웹 사이트aws.amazon.com/dynamodb/

Amazon DynamoDB는 키-밸류 및 문서 데이터[2] 구조를 지원하는 완전 관리형 NoSQL 데이터베이스 서비스로, Amazon.com에서 Amazon Web Services [3]포트폴리오의 일부로 제공합니다.DynamoDB는 이와 유사한 데이터 모델을 공개하고 Dynamo에서 이름을 따왔으나 기본 구현 방식이 다릅니다.Dynamo는 클라이언트가 버전 경합을 해결해야 하는 멀티 리더 설계를 가지고 있으며, DynamoDB는 높은 내구성과 가용성을 위해 여러 데이터[4] 센터에 걸쳐 동기식 복제를 사용합니다.DynamoDB는 [5]2012년 1월 18일 Amazon CTO Werner Vogels에 의해 발표되었으며 Amazon SimpleDB의 [6]진화로 제시되었습니다.

배경

Amazon.com의 CTO인 Werner Vogels는 2012년 [5]발표에서 프로젝트의 동기를 부여했습니다.아마존은 분산형 서비스 네트워크로 출발했다.원래 서비스는 서로의 데이터베이스에 직접 액세스할 수 있었습니다.이것이 엔지니어링 운영의 병목현상이 되었을 때, 서비스는 이 직접 액세스 패턴에서 벗어나 공개용 API를 선호했습니다.그러나 타사 관계형 데이터베이스 관리 시스템은 Amazon의 클라이언트 기반 처리에 어려움을 겪고 있었습니다.이것은 2004년 휴가철에 절정에 달했는데, 그 때 몇몇 기술이 트래픽 폭주로 인해 실패하였다.

엔지니어는 이러한 관계형 시스템을 표준화하여 데이터 중복을 줄이고 스토리지에 최적화된 설계를 수행했습니다.그 때문에, 복수의 관계에 걸쳐, 특정의 「항목」의 데이터(예를 들면, 제품 데이타베이스에 제품에 관한 정보)를 보존해, 조회를 위해서 분리된 부품을 조립하는 데 시간이 걸립니다.Amazon의 많은 서비스는 대부분 데이터에 대한 기본 키 읽기를 요구했으며, 속도를 최우선 과제로 하여, 이러한 조각들을 함께 만드는 것은 매우 [7]힘든 일이었다.

Amazon은 스토리지 효율성을 훼손한 채 내부용으로 구축된 고가용성 키-밸류 저장소인 Dynamo에 응답했습니다.[5]Dynamo는 엔지니어들이 필요로 하는 모든 것 같았지만 채택은 늦어졌다.Amazon의 개발자들은 S3와 SimpleDB를 사용한 "작업만 하는" 디자인 패턴을 선택했습니다.이들 시스템은 설계상 현저한 결함이 있었지만 하드웨어 프로비저닝과 데이터 확장 및 재분할에 따른 오버헤드를 요구하지 않았습니다.Amazon의 NoSQL 기술인 DynamoDB는 이러한 데이터베이스 관리 작업을 자동화했습니다.

개요

Web console
웹 콘솔

DynamoDB는 개발자가 스토리지가 아닌 throughput을 기반으로 서비스를 구매할 수 있도록 하는 점에서 다른 아마존 서비스와 다릅니다.자동 스케일링이 활성화되어 있으면 데이터베이스가 자동으로 [8]스케일링됩니다.또한 관리자는 스루풋 변경을 요구할 수 있으며 DynamoDB는 솔리드 스테이트 드라이브를 사용하여 데이터와 트래픽을 여러 서버에 분산시켜 예측 가능한 [3]성능을 제공합니다.Elastic MapReduce를 [9]통해 Hadoop과의 통합을 제공합니다.

2013년 9월, Amazon은 개발자가 DynamoDB 지원 애플리케이션을 [10]로컬로 테스트할 수 있도록 DynamoDB의 로컬 개발 버전을 출시했습니다.

개발상의 고려사항

데이터 모델링

웹 콘솔의 개요

DynamoDB 테이블에는 기본 [11]키를 구성하는 속성이 있는 항목이 있습니다.그러나 관계형 시스템에서는 항목이 각 테이블 속성을 특징으로 합니다(또는 없는 경우 "null"과 "unknown" 값을 저글링함). DynamoDB 항목은 스키마가 없습니다.단, 테이블을 작성할 때 개발자가 기본 키를 지정하고 테이블에는 모든 항목에 대한 키가 필요합니다.프라이머리 키는 스칼라(스트링, 숫자 또는 바이너리)여야 하며 두 가지 형식 중 하나를 사용할 수 있습니다.단일 속성 기본 키는 테이블의 "파티션 키"로 알려져 있으며, 이 키는 항목이 해시할 파티션을 결정합니다(아래 파티션에 대한 자세한 내용은 해당 파티션 키 범위 내에서 균일한 분포를 가집니다).프라이머리 키는 두 번째 속성을 가질 수도 있습니다.이것은 DynamoDB가 테이블의 "Sort Key"라고 부르는 것입니다.이 경우 파티션 키는 고유할 필요가 없습니다. 각 항목의 고유 식별자를 만들기 위해 정렬 키와 쌍을 이룹니다.파티션 키는 항목이 저장되는 파티션을 결정하는 데 계속 사용되지만 각 파티션 내에서 항목은 정렬 키에 따라 정렬됩니다.

인덱스

관계형 모델에서 인덱스는 일반적으로 표를 보완하는 "도움이 되는" 데이터 구조 역할을 합니다.이러한 기능을 통해 DBMS는 후드 아래에서 쿼리를 최적화할 수 있으며 쿼리 기능은 개선되지 않습니다.DynamoDB에는 쿼리 옵티마이저는 없으며 인덱스는 원래 [11]키 옆에 있는 다른 키(또는 두 개)를 가진 다른 테이블일 뿐입니다.개발자는 인덱스를 생성할 때 데이터의 새 복사본을 만들지만 지정한 필드만 복사됩니다(적어도 인덱스를 작성하는 필드 및 원래 테이블의 기본 키).

DynamoDB 사용자는 자신의 인덱스에 직접 쿼리를 발행합니다.두 가지 유형의 지수를 사용할 수 있습니다.전역 보조 색인은 원래 테이블의 파티션 키와 다른 파티션 키(및 선택적 정렬 키)를 특징으로 합니다.로컬 보조 인덱스는 원래 테이블과 동일한 파티션 키를 사용하지만 정렬 키는 다릅니다.두 인덱스 모두 새 키에 대한 쿼리를 허용함으로써 완전히 새로운 쿼리 기능을 DynamoDB 데이터베이스에 도입합니다.관계형 데이터베이스 관리 시스템과 마찬가지로 DynamoDB는 추가/업데이트/삭제 시 인덱스를 자동으로 업데이트하므로 인덱스를 작성할 때 신중해야 합니다.그렇지 않으면 다수의 인덱스 업데이트로 쓰기 부하가 높은 데이터베이스의 속도가 느려질 위험이 있습니다.

구문

DynamoDB는 [citation needed]JSON의 구문에 JSON을 사용합니다.테이블 작성 액션에는 다음 3개의 인수만 필요합니다.TableName, KeySchema – 파티션키와 옵션의 정렬키(및 AttributeDefinitions)를 포함하는 목록– 파티션키 및 정렬키로 사용되는 속성에 대한 정의를 적어도 포함해야 하는 정의 대상 속성 목록.관계형 데이터베이스가 강력한 쿼리 언어를 제공하는 반면, DynamoDB는 Put, Get, Update 및 Delete 작업만 제공합니다.put requests에는 TableName Atribute와 Item Atribute가 포함됩니다.Item Atribute는 항목이 가진 모든 Atribute와 값으로 구성됩니다.업데이트 요청은 동일한 구문을 따릅니다.마찬가지로 항목을 가져오거나 삭제하려면 TableName 및 Key를 지정하기만 하면 됩니다.

시스템 아키텍처

다이너모 작성 테이블DB

데이터 구조

DynamoDB는 해시 및 B-tree를 사용하여 데이터를 관리합니다.입력 시 데이터는 먼저 파티션 키로 해시하여 다른 파티션으로 배포됩니다.각 파티션에는 최대 10GB의 데이터와 처리를 저장할 수 있으며 기본적으로는 1,000개의 WCU(Write Capacity Unit)와 3,000개의 RCU([12]Read Capacity Unit)가 있습니다.1개의 RCU는 1초당 1회의 읽기 또는 [11]최대 4KB 크기의 항목에 대해 2회의 읽기 일관성을 나타냅니다.1개의 WCU는 최대 1KB 크기의 항목에 대해 초당 1회의 쓰기를 나타냅니다.

데이터 손실을 방지하기 위해 DynamoDB는 복제 및 장기 [13]스토리지로 구성된 2계층 백업 시스템을 갖추고 있습니다.각 파티션에는 3개의 노드가 있으며, 각 노드에는 해당 파티션의 데이터 복사본이 포함되어 있습니다.각 노드에는 항목을 찾는 데 사용되는 B 트리와 노드에 대한 모든 변경을 기록하는 복제 로그의 두 가지 데이터 구조도 포함됩니다.DynamoDB는 정기적으로 이들 2개의 데이터 구조의 스냅샷을 생성하여 S3에 한 달 동안 저장합니다.이것에 의해, 엔지니어는 데이타베이스의 포인트 인 타임 리스토어를 실행할 수 있습니다.

각 파티션 내에서 3개의 노드 중 하나가 "리더 노드"로 지정됩니다.모든 쓰기 작업은 전파하기 전에 먼저 리더 노드를 통과하므로 DynamoDB에서 쓰기가 일관됩니다.상태를 유지하기 위해 리더는 1.5초마다 다른 노드에 "하트비트"를 전송합니다.다른 노드가 하트비트 수신을 중지하면 새로운 리더 선정을 시작할 수 있습니다.DynamoDB는 Paxos 알고리즘을 사용하여 리더를 선출합니다.

Amazon 엔지니어는 파티션과 [7]노드의 프로비저닝과 관리와 같은 엔지니어링 오버헤드 때문에 Dynamo를 피했습니다.이에 대응하여 DynamoDB 팀은 데이터베이스를 [13]관리하기 위해 AutoAdmin이라고 하는 서비스를 구축했습니다.AutoAdmin은 노드가 응답을 정지하면 다른 노드에서 데이터를 복사하여 노드를 바꿉니다.파티션이 3개의 임계값(RCU, WCU 또는 10GB) 중 하나를 초과하면 AutoAdmin은 자동으로 파티션을 추가하여 데이터를 [12]더 세분화합니다.

관계형 모델의 인덱싱 시스템과 마찬가지로 DynamoDB는 테이블에 대한 모든 업데이트가 각 테이블의 인덱스에 반영되도록 요구합니다.DynamoDB는 각 노드의 복제 로그를 구독하고 필요에 [13]따라 추가 Put, Update 및 Delete 요청을 인덱스에 보내는 "log 전파자"라고 하는 서비스를 사용하여 이 문제를 처리합니다.인덱스는 쓰기 요청에 대해 상당한 성능 히트를 일으키기 때문에 DynamoDB는 사용자가 원하는 [citation needed]테이블에서 최대 5개까지 사용할 수 있도록 합니다.

쿼리 실행

DynamoDB 사용자가 쓰기 작업(Put, Update 또는 Delete)을 실행했다고 가정합니다.일반적인 관계형 시스템은 SQL 쿼리를 관계형 대수로 변환하고 최적화 알고리즘을 실행하지만 DynamoDB는 두 프로세스를 모두 건너뛰고 작업을 [13]수행할 수 있습니다.요구는 DynamoDB 요청 라우터에 도착하여 인증됩니다.– "요구는 어디서 온 것입니까?"– – "요구를 제출하는 사용자에게 필요한 권한이 있습니까?"이러한 체크에 합격했을 경우, 시스템은 요청의 파티션 키를 해시하여 적절한 파티션에 도달합니다.내부에는 3개의 노드가 있으며 각각 파티션의 데이터 복사본이 있습니다.시스템은 처음에 리더 노드에 쓴 후 두 번째 노드에 쓴 후 "성공" 메시지를 보내고 마지막으로 세 번째 노드에 전파를 계속합니다.쓰기는 항상 리더 노드를 먼저 통과하기 때문에 일관됩니다.

마지막으로 로그 전파기는 변경을 모든 인덱스에 전파합니다.각 인덱스에 대해 항목에서 인덱스의 기본 키 값을 가져온 다음 로그 전파 없이 해당 인덱스에 동일한 쓰기를 수행합니다.작업이 기존 항목에 대한 업데이트인 경우 업데이트된 속성이 인덱스의 기본 키로 사용될 수 있으므로 해당 인덱스의 B 트리도 업데이트해야 합니다.B는 삽입, 삭제 및 읽기 작업만 처리하므로 실제로는 로그 전파자가 업데이트 작업을 수신하면 모든 인덱스에 삭제 작업과 풋 작업을 모두 실행합니다.

다음으로 DynamoDB 사용자가 Get 조작을 실행했다고 가정합니다.요구 라우터는 이전과 같이 인증 및 인가를 진행합니다.다음으로 위와 같이 파티션 키를 해시하여 적절한 해시에 도달합니다.이제 문제가 생겼습니다. 3개의 노드가 서로 일관성을 유지하는데 어떤 노드를 조사할지 어떻게 결정할 수 있을까요?DynamoDB는 사용자에게 판독치를 발행할 때 일관성 있는 옵션과 최종 일관성 옵션 두 가지를 제공합니다.일관된 읽기가 리더 노드를 방문합니다.그러나, 일관성과 가용성의 균형은 여기서 다시 고개를 들고 있습니다.읽기 부하가 높은 시스템에서는, 항상 리더의 판독치를 읽으면, 단일의 노드에 부하가 걸려, 가용성이 저하될 가능성이 있습니다.

두 번째 옵션(결국 일관된 읽기)은 랜덤 노드를 선택합니다.실제로 DynamoDB는 가용성을 위해 일관성을 교환합니다.이 길로 가면 불일치가 생길 확률이 얼마나 됩니까?"성공"을 반환하고 세 번째 노드로 전파를 시작하지만 완료하지 않으려면 쓰기 작업이 필요합니다.이 세 번째 노드를 타겟으로 하는 것도 필요합니다.즉, 쓰기 작업의 전파 시간 내에 불일치가 발생할 가능성은 3분의 1입니다.이 창문은 길이가 얼마나 됩니까?어떤 재해가 발생하더라도 노드가 뒤처질 수 있지만 대부분의 경우 세 번째 노드는 리더로부터 밀리초 이내에 최신 상태로 유지됩니다.

성능

용량 탭, 스케일링

DynamoDB는 사용자가 올바르게 프로비저닝하고 DynamoDB를 사용하여 애플리케이션을 원활하게 실행할 수 있도록 지원하는 성능 메트릭을 제공합니다.

  • 요구 및 조절
  • 오류: 프로비저닝됨스루풋 초과예외, Conditional Check Failed Exception,내부 서버 오류(HTTP 500)
  • 글로벌 보조 인덱스[14] 생성 관련 메트릭

이러한 메트릭은 AWS Management Console, AWS 명령줄 인터페이스 또는 Amazon CloudWatch와 [15]통합된 모니터링 도구를 사용하여 추적할 수 있습니다.


언어 바인딩

DynamoDB 바인딩 언어 및 프레임워크에는 Java, JavaScript, Node.js, Go, C# 등이 있습니다.NET, Perl, PHP, Python, Ruby, Rust, Haskell, Erlang, Django 및 Grails.[16]

코드 예시

AWS 다이너모DB: 항목 보기

HTTP API

HTTP API에 대해 다음 항목을 쿼리합니다.

POST/HTTP/1.1 호스트: dynamodb.<지역>.<domain>; Accept-Encoding: ID Content-Length: <PayloadSizeBytes> 사용자 에이전트: <UserAgentString> 콘텐츠 유형: application/x-amz-json-1.0 인가: AWS4-HMAC-SHA256 credential=<Credential><Credential>헤더>, 시그니처=<시그니처>X-Amz-Date:<날짜>X-Amz-Target:DynamoDB_20120810.쿼리 { "TableName": "Reply", "IndexName": "PostedBy-Index", "Limit": 3, "ConsistentRead": true, "ProjectionExpression": "Id, PostedBy, ReplyDateTime", "KeyConditionExpression: 1": "Id": "Id: 1"DB#DynamoDB 스레드 1", ":v2a": {"S": "사용자 A", ":v2b": {"S": "사용자 C"}, "Return Consumed Capacity": "TOTAL"}

샘플 응답:

HTTP/1.1 200 네 알겠습니다 x-amzn-RequestId: <RequestId> x-amz-18032: <체크섬> 콘텐츠 타입: 응용 프로그램/x-amz-json-1.0 콘텐츠 길이: <Payload Size Bytes> 날짜.: <날짜>  {     "소비용량": {         "용량유닛": 1,         "TableName" : "응답"     },     "카운트": 2,     "항목" : [         {             "ReplyDateTime" : {"S" : "2015-02-18T20:27:36.165Z" ,             "Posted By": {"S": "사용자 A"},             ID: {S}: "Amazon Dynamazon DynamoDB#DynamoDB 스레드 1"}         },         {             "ReplyDateTime" : {"S" : "2015-02-25T20:27:36.165Z" ,             "Posted By": {"S": "사용자 B"},             ID: {S}: "Amazon Dynamazon DynamoDB#DynamoDB 스레드 1"}         }     ],     "Scanned Count" : 2 }

가세요

Get Item in Go:

getItemInput := &동적.Get Item Input(Get Item 입력){  테이블명: AWS.스트링('해피마케터),  열쇠: 지도[스트링]*동적.속성값{   "실패": {    S: AWS.스트링('프로젝트'),   },   "sk": {    S: AWS.스트링(이메일 + " " + 이름.),   },  }, } get Item Output (get Item 출력), 에러 := dynamicodbClient(다이나믹 클라이언트).Get Item(Get Item)(getItemInput)

이동 시 항목 삭제:

delete Item(항목 삭제)입력 := &동적.아이템 삭제입력{  테이블명: AWS.스트링('해피마케터),  열쇠: 지도[스트링]*동적.속성값{   "실패": {    S: AWS.스트링('프로젝트'),   },   "sk": {    S: AWS.스트링(이메일 + " " + 이름.),   },  }, }  _, 에러 := dynamicodbClient(다이나믹 클라이언트).아이템 삭제(delete Item(항목 삭제)입력) 한다면 에러 != 제로 {  패닉(에러) }

식 빌더를 사용하여 이동 시 항목 업데이트:

갱신하다 := 표현.세트(  표현.이름.(이름.),  표현.가치(가치), )  expr, 에러 := 표현.신규 빌더().업데이트 포함(갱신하다).빌드() 한다면 에러 != 제로 {  패닉(에러) }  update Item(업데이트 항목)입력 := &동적.아이템 갱신입력{  테이블명: AWS.스트링(테이블명),  열쇠: 지도[스트링]*동적.속성값{   "실패": {    S: AWS.스트링('프로젝트'),   },   "sk": {    S: AWS.스트링("mySortKeyValue"),   },  },  UpdateExpression(업데이트 표현):          expr.갱신하다(),  Expression Attribute Names(식 속성 이름):  expr.이름(),  ExpressionAttributeValues: expr.가치(), } fmt.프린트(「항목의 갱신입력: %#v\n", update Item(업데이트 항목)입력)  _, 에러 = dynamicodbClient(다이나믹 클라이언트).아이템 갱신(update Item(업데이트 항목)입력) 한다면 에러 != 제로 {  패닉(에러) }

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications - All Things Distributed". www.allthingsdistributed.com.
  2. ^ "Amazon DynamoDB - FAQs". Amazon Web Services, Inc.
  3. ^ a b Clark, Jack (2012-01-19). "Amazon switches on DynamoDB cloud database service". ZDNet. Retrieved 2012-01-21.
  4. ^ "FAQs: Scalability, Availability & Durability". Amazon Web Services.
  5. ^ a b c Vogels, Werner (2012-01-18). "Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications". All Things Distributed blog. Retrieved 2012-01-21.
  6. ^ "Amazon DynamoDB - FAQs". Amazon Web Services, Inc. Retrieved 2019-06-03.
  7. ^ a b DeCandia, Giuseppe; Hastorun, Deniz; Jampani, Madan; Kakulapati, Gunavardhan; Lakshman, Avinash; Pilchin, Alex; Sivasubramanian, Swaminathan; Vosshall, Peter; Vogels, Werner (October 2007). "Dynamo: Amazon's Highly Available Key–value Store". SIGOPS Oper. Syst. Rev. 41 (6): 205–220. doi:10.1145/1323293.1294281. ISSN 0163-5980.
  8. ^ "Managing Throughput Capacity Automatically with DynamoDB Auto Scaling". Amazon DynamoDB. Retrieved 2017-07-05.
  9. ^ Gray, Adam (25 January 2012). "AWS HowTo: Using Amazon Elastic MapReduce with DynamoDB (Guest Post)". AWS News Blog. Retrieved 29 October 2019.
  10. ^ "DynamoDB Local for Desktop Development". Amazon Web Services. 12 September 2013. Retrieved 13 September 2013.
  11. ^ a b c "Amazon DynamoDB Developer Guide". AWS. August 10, 2012. Retrieved July 18, 2019.
  12. ^ a b Gunasekara, Archie (2016-06-27). "A Deep Dive into DynamoDB Partitions". Shine Solutions Group. Retrieved 2019-08-03.
  13. ^ a b c d AWS re:Invent 2018: Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321), retrieved 2019-08-03
  14. ^ "Top DynamoDB performance metrics".
  15. ^ "How to collect DynamoDB metrics".
  16. ^ "Amazon DynamoDB Libraries, Mappers, and Mock Implementations Galore!". Amazon Web Services.

외부 링크