개발자는 데이터베이스를 이용함으로 애플리케이션 개발엘 더욱 집중 할 수 있다.
데이터베이스는 관계형 및 비관계형 두가지 유형이며, 데이터를 어떤 방식으로 저장, 조직화, 인출할 것인지에 따라 적합한 데이터베이스를 결정할 수 있다.
관계형 데이터베이스
칼럼 및 속성
관계형 데이터베이스 테이블에 데이터를 넣기전에 칼럼 이름과 데이터 타입을 미리 정의해야한다. 칼럼은 순서에 따라 조직화 되기때문에 생성 후에는 순서를 바꿀 수 없다.
데이터는 칼럼별로 미리 정의된 타입과 일치해야한다.
장점으로는 데이터의 조회 작업을 유연하게 할 수 있다는 것으로 데이터 쿼리 작업에 앞서 데이터의 구조나 특성을 미리 알고 있어야 한다.
관계형 데이터베이스는 데이터의 저장 및 관리 작업을 쉽고 빠르게 처리할 수 있도록 돕는다.
어러개의 테이블 활용하기
하나의 테이블에 모든 데이터를 저장하면, 불필요한 복제가 발생하고, 데이터베이스의 크기가 불필요하게 커지며, 쿼리 속도도 느려지기 때문에 보통은 여러개의 연관 테이블을 사용한다.
테이블을 사용할때는 기본 키와 외래키를 이용해 서로 다른 테이블에 존재하는 칼럼의 관계성을 설명할 수 있다.
구조화 질의어
데이터를 조회할때는 구조화 질의어(SQL) 을 사용한다.
SQL 명령은 관계형 데이터베이스 관리 시스템(RDBMS)에 따라 약간의 차이가 있을 수 있다.
OLTP/OLAP
관계형 데이터베이스는 환경 구성 방식에 따라 아래의 두가지로 나눠서 사용가능하다.
- OLTP(online transcation processing) 온라인 입출력 처리
- OLAP(online Analytic processing) 온라인 분석처리
OLTP
OLTP는 데이터의 빈번한 읽기 및 쓰기 작업이 요구되는 애플리케이션에 적합하며, 신속한 쿼리 작업에 최적화되어있으며 비교적 정형화된 쿼리를 주로 사용하게 된다.
기본적으로 OLTP 데이터베이스는 데이터에 대한 신속한 접은을 위해 높은 수준의 메모리 용량을 지니며 보통 충분한 수준의 메모리 및 컴퓨트 용량을 지닌 단일 버서를 통해 모든 쓰기 및 읽기 작업을 처리한다.
주로 분당 수백건의 주문을 처리하는 온라인 주문 시스템 등에 사용된다.
OLAP
OLAP는 대규모 데이터에 대한 복잡한 쿼리 작업에 적합하며, 높은 수준의 컴퓨트 및 스토리지 성능이 요구된다.
데이어 웨어하우스 애플리케이션의 경우 단일 OLAP데이터베이스에 다수의 OLTP 데이터베이스를 결합해 사용한다.
대규모 OLAP 데이터베이스의 경우 여러개의 서버를 두고 복잡한 쿼리 작업의 처리를 나눠서 한다. 이러한 파티셔닝 또는 샤딩 작업을 통해 각 서버가 처리해야할 부분만 맡아서 처리하도록 할 수 있다.
Amazon RDS
Amazon Relational Database Service 는 관리형 데이터베이스 서비스로서 클라우드 기반 관계형 데이터베이스다.
RDS는 데이터베이스 실행을 위한 모든 작업을 수행하며, 데이터베이스 복원, 데이터 복구, 확장 등의 업무도 자동으로 수행한다.
RDS를 배포하려면 격리된 데이터베이스 환경에서 데이터베이스 인스턴스를 구성한다.데이터베이스 인스턴스는 우리가 지정한 VPC에 생성되며 EC2인스턴스와 다르게 약간의 수작업도 필요 없이 AWS가 전부 알아서 해준다.
데이터베이스 인스턴스는 SSH 접속이 불가능하며, EC2인스턴스에서 바로 접근할 수 없다.
데이터베이스 엔진의 종류
데이터베이스 엔진은 데이터베이스에 데이터를 저장, 조직화, 인출하는 소프트웨어이며, 각 데이터베이스 인스턴스는 오직 하나의 데이터베이스 엔진만 실행한다.
- MySql
- 블로그, 커머스등 OLTP 애플리케이션에 적합하다.
- RDS는 자동 백업 기능과 호환성이 있는 InnoDB 스토리지 엔진을 사용한다.
- MariaDB
- Mysql의 대체품이라고 할 수 있다.
- Oracle
- 가장 널리 사용되는 DBMS로 일부 어플리케이션은 오직 Oracle 기반으로 실행되기도 한다.
- PostgreSQL
- Oracle 호환 오픈소스 데이터베이스이며, Oracle 용으로 개발된 내부용 애플리케이션을 좀 더 저렴하게 실행할 수 있는 방법이라 할 수 있다.
- Amazon Auraro
- Amazon이 제공하는 Mysql 및 PostgreSql의 대체품이라고 할 수 있다.
- 스토리지 쓰기 횟수를 감소시키는 가상화 스토리지 레이어를 이용해 좀 더 높은 수준의 쓰기 성능을 제공한다.
- Mysql 호환형, PostgreSql 호환형의 에디션으로 제공된다.
- 이들 에디션을 선택하면 postgresql,mysql의 임포트.익스포트 도구와 스냅샷과도 호환되는 데이터베이스 구성이 가능하다. 마이그레이션에도 용의하다.
라이선스 계약에 대한 고려사항
RDS는 DB엔진 소프트웨어 사용과 관련하여 두 가지 라이선스 모델을 제공한다.
라이선스 포함 모델(Mysql,mariaDB등)은 RDS 인스턴스 사용료에 라이선스 비를 포함한 것이고, 자체 보유 라이선스 모델(오라클 DB엔진들)은 사용자가 데이터베이스 엔진 실행에 필요한 라이선스를 직접 확보하도록 한 것이다.
데이터베이스 옵션 그룹
각각의 데이터베이스 엔진은 관리 및 보안을 위해 다야한 기능과 옵션을 제공하며, 사용자는 옵션 그룹을 이용해 하나 이상의 인스턴스에 이들 기능과 옵션을 쉽게 적용할 수 있다.
단 옵션을 적용을 위해서는 상당한 양의 메모리가 필요하므로 인스턴스에 충분한 메모리가 있는지를 먼저 확인해야한다.
데이터베이스 인스턴스 클래스의 종류
RDB는 데이터베이스의 성능 요구 수준에 맞춰 다양한 데이터베이스 인스턴스 타입을 제공한다.
데이터베이스 인스턴스를 사용한 뒤에 요구 성능이 변경되면 인스턴스 또는 클래스를 변경해 맞추 수 있다.
RDS는 스탠다드, 메모리 최적화, 성능 가속 등 세 가지 타입의 데이터베이스 인스턴스를 제공한다.
스탠다드 데이터베이스 인스턴스
대부분 사용자의 데이터베이스에 대한 요구 수준에 맞춘 클래스로서 최신의 인스턴스 클래스인 db.m5는 다음과 같은 성능을 지닌다.
- 384GB메모리
- 96vCPU
- 25Gbps 네트워크 대역폭
- 19,000Mbps 디스크 처리용량
메모리 최적화 데이터베이스 인스턴스
높은 수준의 성능을 요구하는 데이터베이스에 적합한 인스턴스 타입으로 메모리에 훨씬 더 많은 데이터를 저장할 수 있도록 충분한 메모리를 제공해 쿼리 속도를 높여준다.
성능 가속 데이터베이스 인스턴스
개발, 테스트, 비상용화를 고려한 데이터베이스 인스턴스이며, 구세데 데이터베이스 인스턴스 클래스에 비해 월등히 높아진 성능을 제공한다.
스토리지
데이터베이스 인스턴스에 적합한 스토리지를 선택하는 일은 굉장히 중요하다. 또한 데이터베이스 기반 애플리케이션이 원활하게 작동할 수 있는 스토리지의 처리 속도도 중요한 요소다.
초당 입출력 작업량의 이해
AWS는 스토리지의 성능을 초당 입출력 작업량 즉 IOPS(input/output operations per second)로 측정한다.
IOPS가 높을 수록 데이터베이스가 더 빠르게 데이터를 저장하고 인출할 수 있다.
RDS는 사용자가 선택한 선택한 스토리지 타입에 따라 IOPS를 할당하며, 사용자는 이 한계치를 넘어서 사용할 수 없다. (즉 DB의 속도는 할당받은 IOPS 수준에 맞춰진다)
얼마만큼의 IOPS가 필요한지 알기 위해선, 우리가 필요로 하는 디스크 처리용량 (disk throughput)이 얼마인지를 알아야 한다.
예를 들어 mysql의 페이지 크리는 16KB인데 이는 디스크에 16KB의 데이터를 기록하면 하나의 I/O 작업을 한것으로 간주한다는 의미이다.
반면 PostgreSQL의 페이지 크기는 8KB인데 이는 디스크에 16KB의 반으로 mysql 엔진에 비해 두 배 많은 I/O작업을 처리한다는 의미이다.
즉 페이지 크기가 클 수록 하나의 I/O작업에서 전송할 수 있는 데이터의 양이 많다고 할 수 있다.
(페이지 크기가 클수록 동일한 처리용량 수준을 얻기 위해 더욱 적은 수준의 IOPS 성능이 필요하다)
RDS 스토리지 종류
범용 SSD 스토리지
대부분의 데이터베이스에서 범용 SSD스토리지는 충분한 성능 및 밀리초 수준의 저지연성을 제공한다. 최대 64TB의 볼륨을 할당 할 수 있으며, 볼륨의 기가바이트 당 3IOPS의 기본성능을 제공하고, 볼륨당 최대 16,000IOPS의 처리 성능을 활용할 수 있다.
볼륨의 크기가 클수록 성능이 좋아진다.
순간 가속이라는 개념이 존재한다.
프로비전 IOPS SSD(io1)스토리지
직관적인 RDS 옵션을 선택할 수 있는 스토리지 이다.
인스턴스 생성시 우리가 원하는 수준의 IOPS를 직접 할당할 수 있다.
성능 가속의 개념이 없으며 우리가 필요한 만큼의 IOPS를 할당하고 그에 따른 비용을 지불하면되기 때문에 일관되게 높은 수준의 성능이 필요한 경우 유용한 옵션이다.
마그네틱 스토리지(스탠다드)스토리지
RDS는 역호환성 유지를 위해 구형 인스턴스를 위한 마그네틱 스토리지를 제공하며,
1TB의 저장 용량에 100IOPS의 처리 성능을 제공한다.
AWS는 이 타입의 스토리지 지원을 줄이기 있기때문에 사용이 권장되지는 않는다.
읽기 전용 복제본
데이터베이스 인스턴스가 요구 성능 수준에 미치지 못할 경우 수직적 확장(scale up) 또는 수평적 확장(scale out) 옵션으로 성능 수준을 높일 수 있다.
수직적 확장
메모리양, 컴퓨트 성능, 네트워크 속도, 디스크 처리용량등이 문제가 되면,
애플리케이션 또는 데이터베이스는 그대로 둔 채 인스턴스와 관련된 리소스만 추가하는 방법으로 문제를 해결할 수 있다.
인스턴스 클래스를 업그레이드하는 이런 방식을 수직적 확장 또는 스케일 업이라고 부른다.
수평적 확장
스케일 아웃은 읽기 전용 복제본(read replicas)이라 부르는 데이터베이스 인스턴스를 추가하는 방법으로 구현 가능하다.
대부분의 데이터베이스 엔진이 읽기 전용 복제본을 지원하며, Aurora의 경우 독자적인 읽기 전용 복제본인 Aurora replica를 제공한다.
읽기 전용 복제본은 데이터베이스에 대한 쿼리 작업만 가능한 또 다른 형태의 데이터베이스 인스턴스이며, 마스터 데이터베이스 인스턴스의 쿼리 작업 부담을 주령 주어 쓰기 작업에 집중할 수 있도록 한다. 읽기 전용 복제본은 읽기 작업이 많은 애플리케이션에 유용하다.
RDS는 5개의 읽기 전용 복제본을 지원하고 Aurora의 경우 15개를 생성할 수 있다. 마스터의 데이터는 비동기적으로 읽기 전용 복제본에 저장되므로 마스터에 데이터가 기록된 시점과 읽기 전용 복제본에서 해당 데이터를 읽을 수 있는 시점에는 약간의 차이가 발생한다.
데이터 유실의 문제가 중요한 이슈인 경우 일긱 전용 복제본은 재난 복구용으로 적합하지 않다. 마스터가 사본으로 데이터를 전달하기 전 중단되면 복제 작업을 완료할 수 없고 비동기화된 데이터는 유실될 것이기 때문이다.
여러 개의 읽기 전용 복제본이 있는 경우 RDS는 로드 밸런서를 통해 연결 상태를 관리한다.
고가용성 구현 (멀티 AZ)
데이터베이스 인스턴스 중단 상태가 발생하더라도 데이터베이스가 문제 없이 실행 되도록 하려면, 다수의 AZ에 다수의 데이터베이스 인스턴스를 배포하는 것이 좋다. RDS에서는 이를 멀티 AZ배포라고 부른다.
멀티 AZ배포는 하나의 AZ에 기본 또는 프라이머리 데이터베이스 인스턴스를 두어 읽기 및 쓰기 작업을 담당하도록 하고, 또 다른 AZ에 대기 또는 스탠바이 데이터베이스 인스턴스를 두는 방식이다.
프라이머리 인스턴스가 중단되면, 2분 내에 스탠바이 인스턴스로 데이터베이스를 복구하게 된다.
멀티 AZ배포는 데이터베이스 인스턴스 생성 시 또는 생성 후에 설정 가능하며, 모든 데이터베이스 엔진이 멀티 AZ배포를 지원하지만 설정 방식에는 약간의 차이가 있다.
데이터베이스 인스턴스 생성 후 멀티 AZ 배포를 활성화하면 성능 저하가 발생할 수 있으므로 가급적 유지보수 기간에 활성화하는 것이 좋다.
백업과 복원
RDS를 사용하면 데이터베이스 인스턴스의 EBS볼륨 스냅샷을 기록할 수 있다.
스냅샷에는 인스턴스에 있는 모든 데이터베이스와 S3에 저장된 데이터까지 기록되며, 중복구현을 위해 동일 리전, 다수의 AZ에 저장된다.
멀티 AZ기반의 데이터베이스 엔진을 사용하지 않는 한, 스냅샷을 생성할 떄 몇 초간 모든 I/O 작업이 중단되므로, 스냅샷은 피크 타임을 피해서 기록하는 것이 좋다.
백업 및 복원 작업과 관련해서는 RTO 및 RPO 두 가지 지표를 기억해야 한다.
RTO (Recovery Time Objective) : 데이터 복원 및 데이터 처리 재개가 가능한 최대 허용 시간
RPO (Recovery Point Objective) : 최대 데이터 손실 허용 기간
자동 스냅샷
RDS는 자동으로 매일 30분간의 백업 윈도우 기간 동안 인스턴스의 스냅샷을 생성 할 수 있다. 스냅샷 생성 시 성능 저하 현상이 발생할 수 있으므로 피크 타임은 피해야한다.
RDS는 일정 기간만 스냅샷을 유지한 후에는 삭제하며, 보관기간으로 1일에서 35일을 설정할 수 있다. 기본 보관기간은 7일이다. 자동스냅샷 기능을 끄면 보관기능은 0이다.
유지보수 항목
RDS는 관리형 서비스이므로 패치 및 업그레이드 등 데이터베이스 관리와 관련된 모든 작업을 AWS가 처리한다. AWS는 몇달에 한번 주기적으로 데이터베이스 인스턴스에 대한 유지보수 업무를 수행하며, OS 보안 패치, 신뢰성 요소 추가 등이 포함된다.
Amzaon RDS Proxy
애플리케이션과 데이터베이스 인스턴스를 연결하기 위한 프록시 서비스이다.
보통은 애플리케이션은 필요에 따라 데이터베이스와 직접 소통하지만, 이런 방식이 성능 또는 보안성 측면에서 문제가 되는 경우가 있다. AmazonRDS Proxy는 이와 같은 문제를 해소하기 위해 애플리케이션과 데이터베이스 인스턴스 사이에서 서로의 통신을 지원한다.
데이터베이스 인스턴스와 최소한의 연결만을 유지하면서 애플리케이션 측의 연결을 동적으로 확장 및 축소할 수 있다.
장애 대응 및 재연결 작업에서 더 원할한 처리를 할 수 있다.
Amazon RDS Proxy는 IAM 롤 기반의 신뢰 인증 체계를 사용하므로 애플리케이션은 별도로 암호화된 연결 정보를 제공할 필요가 없다.
Amazon Redshift
OLAP는 고성능의 컴퓨팅 파워가 요구되는 복잡한 쿼리를 위해서 여러 개의 데이터베이스가 하나의 큰 데이터베이스로 통합된 데이터 웨어하우스 애플리케이션에 최적화된 솔루션이다. Redshift는 바로 그런 목적으로 만들어진
관리형 데이터 웨어하우스 서비스 이다.
- PostgreSQL을 기반으로 하지만 RDS와는 별개로 존재한다.
- 칼럼 단위로 데이터를 저장하는 칼럼형 스토리지로 저장 속도가 빠르고 효율적이며, 개별 칼럼에서 신속하게 쿼리 작업을 수행한다.
- ODBC(open database connectivity) 및 JDBC 데이터베이스 커넥터를 지원한다.
- 스토리지에서 소요되는 칼럼 수를 줄이기 위해 압축 인코딩 기법을 사용한다.
컴퓨트노드
Redshift클러스터는 하나 이상의 컴퓨트 노드를 지닌다.
데이터 분산 유형
Redshift 데이터베이스의 행은 다수의 컴퓨트 노드에 분산 저장되며, 데이터 분산 방식으로는 EVEN, KEY, ALL등의 유형이 있다.
- EVEN : 기본 분산유형으로 리더 노드가 모든 컴퓨트 노드에 균일하게 분산된다.
- KEY : 단일 칼럼 내 값에 따라 데이터가 분산되며, 동일한 값의 칼럼은 동일한 노드에 저장된다.
- ALL : 각각의 테이블이 모든 컴퓨트 노드에 분산 저장된다.
Redshift Spectrum
redshift spectrum 은 s3에 저장된 파일에서 데이터를 쿼리할 수 있는 서비스로서 클러스터로 데이터를 임포트 할 필요가 없다는 장점이 있다.
AWS DMS
AWS Database Migration Service(DMS)는 기존 데이터베이스와 스키라를 자동으로 복사해서 다른 데이터베이스에 저장할 수 있다.
DMS의 가장 큰 장점이자 주요기능은 서로 다른 데이터베이스 엔진 간의 마이그레이션, 관계형 및 비관계형 데이터베이스 간의 마이그레이션을 지원한다는 점이다.
DMS는 DMS인스턴스라 부르는 EC2 인스턴스를 프로비전해 소스 데이터베이스와 타겟 데이터베이스 간의 연결을 생성하고, 이들 데이터베이스 간의 변환 작업에 필요한 스키마의 복제 작업을 수행한다.
일반적인 네트워크로 전송하기에 너무 큰 데이터베이스를 마이그레이션 해야할경우 Snowball edge사용을 권장한다.
비관계형 데이터베이스(NoSQL)
비관계형 데이터베이스는 초당 수 만 회 이상의 데이터 트랜잭션을 일관되게 처리 할 수 있도록 설계되었다. 관계형 데이터베이스의 데이터도 저장할 수 있지만 비구조화 데이터를 저장하는데 최적화된 데이터베이스 모델이다.
비관계형 데이터베이스에 저장되는 데이터는 다양한 구조를 지니며, 시간 경과에 따라 이들 구조가 바뀔 수 있다는 특징이 있다.
데이터 정렬하기
비관계형 데이터베이스의 경우 스키마가 없다. 데이블 내 모든 아이템이 동일한 속성을 지닐 필요가 없다. 각 아이템은 테이블 내에서 유일한 값을 지닌 기본 키 속성을 지닌다. 기본 키는 아이템을 식별하고 아이템 정렬 시 값을 부여하는 데 사용된다.
기본키 속성을 제외하고는 테이블 생성 시 별도의 속성을 정의할 필요가 없으며, 아이템 생성 또는 변경 시 속성을 추가하면 된다.
데이터 조회하기
비관계형 데이터베이스는 기본 키를 기준으로 한 쿼리 작업에 최적화 되어있다. 다른 속성으로 쿼리 작업을 수행하면 속도가 느려지게 된다.
이러한 이유로 비관계형 데이터베이스는 복잡한 쿼리 작업 또는 임의의 쿼리 작업에는 적함하지 않다.
사용자는 테이블 생성 전, 데이터에서 어떤 속성을 쿼리할 것인지 미리 파악하고 있어야 한다.
비관계형 데이터베이스의 종류
비관계형 데이터베이스는 키/밸류 스토어 타입과 도큐먼트 지향 스토어 타입 두가지가 존재한다고 하지만, 엄밀히 말하면 기본적으로 키/밸류 스토어 데이터베이스로 볼 수 있다.
도큐먼트 지향 스토어는 비관계형 데이터에비스의 특수한 유형으로 값으로 저장된 도큐먼트의 콘텐츠를 분석하고 그 속에 포함된 메타데이터를 추출한다.
DynamoDB
DynamoDB는 각종 관리 업무를 지원하는 비관계형 데이터베이스 서비스로서 다수의 파티션에 분산된 데이터 구조를 이요해서 초당 수천 회의 읽기 및 쓰기 작업을 처리한다. 여기서 파티션이란 데이블을 위한 스토리지 할당 영역이며, 다수의 AZ에 존재하는 SSD장치를 이용한다.
파티션과 해시 키
테이블 생성 시, 기본키와 데이터 타입을 명시해야 하며 기본키는 테이블 내 유일한 식별자로서 그에 대응하는 값 또한 테이블 내에서 유일해야한다.
사용자는 두 가지 타입의 기본키 중 하나를 사용할 수 있다.
파티션 키 해시키로도 부르며 하나의 값을 지닌 기본키다. 2,048 바이트를 넘지 않는 선에서 임의로 생성한 식별자를 사용하면 된다.
기본키로 파티션키와 소트 키(sort key) 또는 레인지 키(range key) 라는 두 개 키조합을 사용할 수 있으며 이를 복합 기본키라고 한다.
파티션 키는 유일할 필요가 없지만, 파티션 키와 소트키 조합은 유일해야 한다.
예를들어 사람의 서을 파티션 키로 이름을 소트 키로 사용할 수 있다.
DynamoDB는 기본 키를 사용해 파티션에 저장 아이템을 분산 해서 관리한다.
속성과 아이템
속성이란 하나의 키/밸류 쌍을 의미하고, 하나 이상의 속성이 모인 것을 아이템이라 부른다. DynamoDB에서 아이템의 최대 용량을 400KB이며 약 50,000개의 영어 단어를 저장할 수 있는 수준이다.
모든 아이템은 최소 하나의 기본키와 그에 상응하는 값을 지니도록 하고, 속성에는 다음 세가지 데이터 타임중 하나를 지정한다.
- Scalar 데이터 타입 : 하나의 값만 지닐 수 있으며 string, number,binary, Boolean, and null 타입이 이에 해당한다.
- Document 데이터 타입 : 스칼라 또는 세트 데이터 타입이 아닌 또 다른 유형의 데이터를 정의하기 위한 타입으로 32단계의 계층으로 문서 요소 간의 중첩 관계를 정의할 수 있다.
- 리스트 토큐먼트 타입 : 다양한 타입의 순위형 데이터 모음을 저장할 수 있다.
처리 용량(스루풋) 옵션 선택
테이블 생성시 DynamoDB를 온디맨드 모드 또는 프로비전 모드로 선택해서 사용 할 수 있다. 온디맨드 모드의 경우 DynamoDB는 자동으로 워크로드에 맞춰 확장하므로 본인이 요구되는 워크로드 수준을 파악할 수 없을때 혹은 사용한 용량만큼 지불하고 싶을 때 유용하다.
프로비전 모드의 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정할 수 있다. 이렇게 지정하는 작업량을 프로비전 스루풋이라 부른다.
DynamoDB는 테이블 생성 시 읽기 용량 유닛(RCU) 및 쓰기 용량 유닛(WCU)의 수르르 기준으로 파티션을 제공한다.
Auto Scaling
데이터베이스로 처리할 용량에 대해 정확하게 판단을 내릴 수 없는 경우, 혹은 시간에 따라 처리용량이 바뀌는 경우에는 auto scaling을 이용해 사용자가 미리 정해둔 한계점을 넘어설 때 자동으로 처리용량을 추가할 수 있다.
이는 RCU 또는 WCU를 정의할 필요가 없는 온디맨드 모드와는 다르다는 점에 주의한다.
데이터 일기
DynamoDB는 스캔과 쿼리, 두 가지의 데이블 읽기 방식을 제공한다.
먼저 스캔은 데이블 내 모든 아이템을 반환한다. 스캔은 읽기 집약적인 방식으로 우리의 읽기 유닛을 모두 소진할 수 있다.
쿼리는 파티션 키 값에 따라 아이템을 반환한다. 쿼리 실행 시 파티션 키와 정확하게 일치하는 아이템만 반환된다. 테이블에 소트 키가 있는 경우 소트 키를 이용해서 쿼리 작업을 할 수 있다.
보조 인덱스
보조 인덱스를 통해서 데이블의 기본 키 없이 속성으로 데이터를 조회할 수 있다.
보조 인덱스는 테이블에 있는 속성 중 일부라고 할 수 있으며, 보조 인덱스가 속성 정보를 가져오는 테이블을 베이스 테이블 이라 한다.
보조 인덱스는 항상 베이스 테이블에서 가져온 파티션 키 및 소트 키 속성을 지닌다.
- 전역 보조 인덱스
- 테이블 생성 후 언제든 전역 보조 인덱스 생성 가능 하다.
- 전역 보조 인덱스로 읽기 작업을 수행하는 경우 종국적 일관성의 읽기 작업이 이뤄진다 . - 지역 보조 인덱스
- 베이스 테이블과 함꼐 생성해야한다. 생성 후에는 지역 보조 인덱스만 삭제할 수 없다.
- 지역 보조 인덱스에서의 읽기는 우리의 설정에 따라 강한 일관성 또는 종국적 일관성 모두 가능하다.
전역 테이블
가용성을 높이기 위해, 전역 테이블 기법으로 다수의 리전에서 해당 테이블을 복제 해서 사용할 수 있다.
