[ DevOps ] - (DynamoDB) DynamoDB 개요와 Index 구성

DynamoDB는 수평확장(Scale-out)이 매우 쉽고 유연합니다. 그리고 쿼리 속도가 매우 빠릅니다. 또한 어떠한 데이터의 자율성이 높아지면 높아질 수록 공간대비 비용이 낮아지는 경향이 있습니다. 왜냐하면 스키마 같은 제약을 연산하는데 추가적인 비용과 신경쓸게 더 많아지기 때문입니다.

 

그리고 DynamoDB는 쿼리 속도가 매우 빠릅니다. 스키마도 없는데 왜 빠를까요? 바로 DynamoDB는 pK, global gsi외에 많은 키가 있는데, 이는 이 키 값을 기준으로 동일한 것을 찾거나, range를 정해준다거나 이 키 값에 대해서만 매우 빠르게 됩니다.

 

또한 맨 마지막에 Ideal of applications with known access patterns가 있는데, 만약 주문 내역을 조회하는데 정해진 패턴인 주문 id로만 이를 찾아낼거야 라고 하면 DynamoDB는 매우 빠른 속도로 이를 찾아냅니다. 하지만 정해지지 않은 패턴으로 막 지역별로 필터링하고 이상한 컬럼으로 필터링을 진행한다면 수행하는 속도가 느린 상황이 나올 수 있습니다.

 

DynamoDB 핵심 구성요소 

우선 DynamoDB에는 Table이 있는데, 이는 Mysql의 Table과 개념이 똑같습니다. 그리고 Item이라는 개념이 있는데 이는 mysql에서 row와 같습니다. 즉 하나의 행을 아이템이라고 합니다. 그리고 Attribute는 행에 대한 추가적인 key-value쌍들의 모음을 저장해 놓는 것이라고 보시면 됩니다. 그리고 index는 다양한 key들을 가지고 있습니다. 크게 3가지로 나눌 수 있는데, Partition Key, Sort Key, )Primary Key ), GSI입니다. 하나하나 차근차근 알아보겠습니다.

 

우선 위 그림에서 저는 OrderID, Date, Region을 다 index로 설정했습니다. 그리고 index는 데이터를 추가할 때 꼭 필요한 값입니다. 그래서 데이터를 넣을 때에는 무조건 위 값이 포함되어야 합니다. 그리고 상세 정보는 Attribute는 아무거나 들어와도 됩니다. 즉 극단적인 자율도를 자랑합니다.

 

사실 위 키 3개가 다 필요한 것은 아닙니다. Sort Key, GSI는 필요없어도 됩니다. 그럼 Partition Key는 mysql에서 pK와 같은 역할을 하게 됩니다. 하지만 만약 Partition Key가 같은 값이 여러개가 있다고 해 봅시다. 그럼 Sort Key가 없는 경우 오류가 납니다. 이럴 떄 쓰는 것이 Sort Key입니다. 즉 Partition Key + Sort Key를 통해 item을 unique하게 구별합니다. 만약 두개의 조합이 같은것이 존재하면 이 때는 DynamoDB가 오류를 뱉습니다.

 

나중에 막 Partition을 구분한다는 용어가 생깁니다. 이는 그냥 예를 들자면 Partition Key가 2인 것중에 210701인 것을 찾는다는 의미와 같습니다. 

 

그리고 GSI가 있는 이유에 대해서 설명하겠습니다. 위에서 말했다 싶이 Attribute즉 정해진 패턴이 아닌 것을 통해 쿼리문을 돌리면 이는 매우 느려지게 됩니다. 만약 제가 Region이라는 정해진 패턴으로 많이 쿼리문을 돌릴거다 라고 하면 Attribute에 들어가면 안되고 무조건 GSI로 빼는것이 좋습니다. 즉 Partition Key와 Sort Key로 넣기는 애매하지만 아이템을 찾을 때 자주 사용할 값이면 이때 이를 GSI로 빼는게 좋다는 얘기입니다. 

 

다음시간에는 DynamoDB를 생성하고 쿼리문을 짜서 이런식으로 필터링을 하는거구나에 대해서 알아보겠습니다.