AWS에서 지원하는 NoSQL 데이터베이스이다.
지난번에 공부한 RDS는 관계형 데이터 베이스인데 NoSQL은 무엇일까 ?
관계형 데이터 베이스
대부분 데이터베이스를 공부하면 관계형 데이터베이스를 생각한다.
관계형 데이터베이스는 키와 값들의 간단한 관계를 테이블화 시킨 데이터 베이스이다.
예를 들어 세로에는 물품 가로에는 가격, 분류 등등을 지정할 수 있다.
NoSQL
NoSQL에 대한 정의는 보통 Not Only SQL로 인식된다.
즉 관계형 DB가 가지고 있는 SQL 특성뿐이 아닌 다른 특성들을 부가적으로 지원한다.
1. 관계형 DB보다 융통성있는 모델이고 데이터의 저장 및 검색을 위한 메커니즘을 제공하고 최적화된 키-값 저장 방벙을 사용하고, 응답속도나 처리 효율등 관계형 DB에 비해 좋다.
2. 스키마가 필요 없으며 분산이 용이함
(스키마가 필요 없다는것은 데이터를 정의할떄 문자에 대한 제한, 숫자에 대한 제한등을 지정해야하는데 이런게 필요없다.)
3. SNS가 등장하여 정형데이터가 아닌 데이터가 등장하며 쉽게 저장하고 처리하는것에 대해 이목을 이끈다.
(비정형 데이터란 ? 문서, 컬럼 키벨류, 그래프등이 존재한다)
이런 NoSQL특성을 가진 DynamoDB는 AWS에서 지원하는 NoSQL 데이터베이스이다.
AWS플랫폼에서 가용영역이 있기에 따로 백업이나 할 필요가 없다.
기존 데이터베이스는 테이블의 용량이 커지만 샤딩이라는방법을 통해 데이터를 여러 서버에 분산해서 저장하였습니다. 그래서 애플리케이션 레벨에서 샤딩을 직접 구현하거나, DB에서 지원하는 샤딩 기능을 이용하는 등 개발과 운영이 상당히 번거로웠습니다. DynamoDB는 이런 것들을 자동으로 처리해주기 때문에 데이터가 늘어나는 것에 대해 신경을 쓸 필요가 없다.
기본적인 구성요소로는 Table, Item, Attribute가있다.
1) Table
- Table은 Item 들의 모임이다. 아이템 갯수는 제한이 없고, 기본키를 반드시지정해야하고, 리전당 테이블의 최대갯수는 256개
2) Item
- Item은 Attribute의 모임이다.
- Attribute의 갯수 제한은 없다.
- 아이템의 크기는 속성 이름과 값을 포함하여 64KB까지 이다.
- 기본 키는 필수로 포함하고 있어야 하며 복합키와 기타 속성을 가진다.
3) Attribute
- key-value 방식이다. key는 문자열이라고 한다.
지원하는 데이터값은 2가지이다.
1) 스칼라 데이터 형식 : 숫자, 문자열, 바이너리
* 숫자 : 정수와 실수를 지원하며 실수는 소수점 이하 38자리입니다. 숫자는 0을 트림(Trim)해서 다룹니다. 예를 들어, 0.3->.3 , 00300->300
* 문자열 : UTF-8 형식이고 대소를 비교할 때는 ASCII Code를 기준이로 합니다.
* 바이너리 : 바이너리 데이터는 BASE64 형식으로 인코딩하여 저장하면 됩니다. 대소를 비교할 때는 각 바이트를 부호없는 정수로 취급합니다.
2)다중 값 형식(Multi-valued types) : 스칼라 데이터 형식의 배열 형태로, 숫자 세트(Number Set), 문자열 세트(String Set), 바이너리 세트(Binary Set)가 있습니다.
* 다중 값 형식은 들어가는 값이 중복될 수 없으며, 값이 하나라도 들어가 있어야 합니다..
* 값들은 정렬되지 않고 정렬 순서도 저장되지 않습니다.
* 다중 값 형식은 기본 키로 사용할 수 없습니다.
* NULL이나 빈 문자열은 저장이 불가합니다.
DynamoDB에서 검색을 하려면 기본 키Primary Key로 인덱스Index를 생성해야 합니다. 그리고 이 기본 키는 테이블을 생성할 때 반드시 지정해야 하며 이 기본 키로 생성되는 인덱스를 테이블 인덱스라고 합니다. DynamoDB가 지원하는 기본 키 형식은 두 가지입니다.
해시 기본 키는 일치Equal 방식 검색만 지원하며 범위 기본 키는 일치, 부등호, 포함, ~로 시작 등의 검색을 지원합니다. 그리고 해시 기본 키 속성 값의 최대 크기는 2048 바이트이며 범위 기본 키 속성 값의 최대 크기는 1024 바이트입니다.
두가지 보조 인덱스 키의 차이점은 해시키와 범위키와 상관없이 인덱스 기능을 하기 위해 검색을 사용하는데,
검색 기능을 하나의 테이블에서 로컬하게 해시키를 기본키를 두고 인덱싱을 할 것인가?
아니면 모든 테이블에 완전 따로 해시 키, 범위 키와 다르게 설정해서 사용하는 것인 가에 차이입니다.
1) Eventually Consistent Read
: 읽기 처리량(Read Throughput)을 최대화하지만 읽은 데이터가 최근 완료된 쓰기 결과를 반영하지 못했을 수 있습니다.
쓰기가 데이터의 모든 복사본에 반영되는 것은 1초내에 이루어지는데, 최신 데이터를 얻으려면 짧은 시간 내에 읽기를 반복해야 합니다.
2) Strongly Consistent Read
: 위의 Eventually Consistent Read 에서 가지는 복사본에 반영되는 데이터의 시간 1초내에 읽기를 요청하는 경우,
데이터를 최신 데이터로 못가져오는 결과가 있는데 그러한 경우를 없애고 최근 완료된 쓰기 결과가 모두 반영된 데이터를 가져옵니다.
Provisioned Throughput은 사용자가 원하는 수치를 지정하면 DynamoDB가 알아서 지정된 수치만큼 처리량을 제공해주는 것을 말합니다.
- 필요한 읽기 용량 유닛(Read Capacity Units) : 초당 읽은 아이템 수 X KB 단위 아이템 크기 (근사치 반올림) (Eventually Consistent Read를 사용하는 경우 초당 읽은 아이템 용량은 두배가 됩니다.)
- 필요한 쓰기 용량 유닛(Write Capacity Units) : 초당 쓴 아이템 수 X KB 단위 아이템 크기 (근사치 반올림)
으로 필요한 Read/Write Capacity Units을 설정합니다.
예) 512바이트(1KB로 반올림 됨)를 초당 200개 항목을 읽으면(쓰면), 1KB x 200 = 200 유닛 1.5KB(2KB로 반올림 됨)를 초당 200개 항목을 읽으면(쓰면), 2KB x 200 = 400 유닛
Strongly Consistent Read는 1000 읽기 용량 유닛으로 1KB 짜리 아이템을 초당 1000번 읽을 수 있으며 Eventually Consistent Read는 500 읽기 용량 유닛으로 1KB 짜리 아이템을 1000번 읽을 수 있습니다.
그리고 읽기 용량의 유닛 수는 API 호출 수가 아닌 초당 읽은 아이템 수로 결정됩니다. 500 유닛을 읽는다고 하면 1KB 짜리 아이템을 GetItem으로 500번 호출하는 것과, BatchGetItem으로 아이템 10개씩 50번 호출하는 것은 동일합니다.
DynamoDB의 데이터 조회 방법은 두 가지입니다. 두 가지 모두 한 번에 조회할 수 있는 용량은 1MB입니다.
https://interconnection.tistory.com/60
자세한 설명은 이 url을 참고하길 바란다.
https://wbluke.tistory.com/?page=3
함께 자라기
wbluke.tistory.com
테이블을 생성해보자
기본키(Primary key)의 상단 Partition key에는 해시기본키의 속성(Attribute) 이름과 데이터 형식을 입력합니다. 아래는 범위키로 사용할 속성(Attirubte) 이름과 데이터 형식을 입력합니다.
저는 해시키(Partition key)에는 Id(Number)을 아래 범위키(Range key)에는 Week(String)을 선택했습니다.
생성을 누르면 DB가 생성이 된다.
인덱스 키는 테이블 검색에 필요하다.
인덱스 생성 클릭
인덱스 해시 키로 Week(String)와 인덱스 범위 키로 TopScore(Number)를 등록했습니다.
이전에는 인덱스키 분류가 글로벌과 로컬이 있엇는데 없어졌다.
테이블을 하나 더 생성한다.
항목에서 항목만들기 클릭
추가 후 생성한다.
생성 완료!
스캔은 인데스나 표에 따라 모든 데이터가 검색된다.(필터도 사용가능)
아래에 쿼리와 스캔에 차이가 있다.