(6) 데이터베이스 서비스

안녕하세요 levin입니다.
AWS study 여섯번째 시간 , 데이터베이스 서비스 입니다.

관계형 데이터베이스

관계형 데이터베이스는 최소 하나 이상의 테이블을 지닌다. 테이블은 마이크로소프트 엑셀 등 스프레시드의 칼럼과 로우로 생각해도 되고, 칼럼은 속성으로 로우는 레코드 또는 튜플로도 불린다.

• 칼럼 및 속성 : 관계형 데이터베이스 테이블에 데이터를 넣기 전, 칼럼 이름과 데이터 타입을 미리 정의해야 한다. 칼럼은 순서에 따라 조직화되므로 테이블 생성 후에는 순서를 바꿀 수 없다. 그리고 속성 간에 존재하는 이와 같은 순서가 관계형 데이터베이스의 특징이자 이름이 붙여진 이유라 할 수 있다. 데이터는 각 칼럼 별로 미리 정의된 타입과 일치해야 한다. 이에 따른 장점으로 데이터 조회, 즉 쿼리 작업을 유연하게 할 수 있다는 것이다.
  데이터가 일관된 방식으로 저장되기만 하면, 사용가아 원하는 데이터를 원하는 방법으로 조회해볼 수 있다. 임의의 칼럼에 존재하는 데이터를 조회하거나 표시 방법을 필요에 따라 수정해야 하는 경우, 관계형 데이터 베이스의 유용성은 더욱 높아진다. 또한 테이블 생성 후 필요에 따라 칼럼을 추가할 수 있다. 삭제하는 것도 가능하지만 칼럼 삭제시 그에 속한 모든 데이터도 삭제된다.
• 여러 개의 테이블 활용 : 하나의 테이블에 모든 데이터를 저장하면, 불필요한 복제가 발생하고 데이터베이스의 크기가 불필요하게 커지며, 쿼리 속도도 느려지므로 보통의 애플리케이션은 여러개의 연관 테이블을 사용한다.
• 구조화 질의어 : 사용자는 관계형 데이터베이스의 저장, 쿼리 작업, 각종 데이터베이스 유지 보수 업무에 구조화 질의어를 사용하며, 이 때문에 관계형 데이터베이스를 종종 SQL 데이터베이스로도 부른다.
  RDBMS 마다 SQL 명령어가 조금씩 다르지만 주요 명령을 중심으로한 핵심 개념에 대한 이해는 필요하다. SELECT명령은 데이터를 조회할때 사용하며, 특정 칼럼의 값을 기준으로 조회하거나, 특정 칼럼의 값을 반환하도록 할 수 있다. 이해하기 쉬운 테이블 구조 및 외래 키가 지닌 제약 사항 덕분에 SELECT 명령에 JOIN 구문을 추가해 다른 테이블의 데이터를 결합할 수 있다. INSERT 명령을 이용해 테이블에 데이터를 직접 삽입할 수 있다. 대량의 레코드를 입력해야 하는 경우, COPY 명령을 이용해 사용자가 지정한 테이블에 적절한 포맷으로 파일을 복사할 수 있다.
• OLTP : 데이터의 빈번한 읽기 및 쓰기 작업이 요구되는 애플리케이션에 적합하며, 신속한 쿼리 작업에 최적화돼 있고, 비교적 정형화된 쿼리를 주로 사용하게 된다. 기본적으로 OLTP 데이터베이스는 데이터에 대한 신속한 접근을 위해 높은 수준의 메모리 용량을 지니며 보통 충분한 수준의 메모리 및 컴퓨트 용량을 지닌 단일 서버를 통해 모든 쓰기 및 읽기 작업을 처리한다.
• OLAP : 대규모 데이터에 대한 복잡한 쿼리 작업에 적합하며, 높은 수준의 컴퓨트 및 스토리지 성능이 요구된다. 데이터 웨어하우스 애플리케이션의 경우 단일 OLAP 데이터베이스에 다수의 OLTP 데이터베이스를 결합해 사용한다. 체계적인 SQL 쿼리 작업이 가능하며, 고성능의 OLAP에 복잡한 쿼리 작업을 분산함으로써 데이터 처리 및 분석에 소요되는 시간을 단축시킬 수 있다. 대규모 OLAP 데이터베이스의 경우 여러 개의 서버를 두고 복잡한 쿼리 작업의 처리를 나눠서 처리한다. 이러한 파티셔닝 또는 샤딩작업을 통해 각 서버가 처리해야 할 부분만 맡아서 처리하도록 할 수 있다.

[Amazon RDS]

RDS 는 관리형 데이터베이스로서 클라우드 기반 관계형 데인터베이스다. RDS 는 데이터베이스 실행을 위한 모든 작업을 수행하며, 데이터베이스 복원, 데이터 복구, 확장 등의 업무도 자동으로 수행한다.
RDS를 배포하려면 가장먼저 격리된 데이터베이스 환경에서 인스턴스를 구성한다. 이 인스턴스는 사용자가 지정한 vpc에 생성되며, EC2와 달리 AWS가 데이터베이스 인스턴스 생성과 관련된 전과정을 관리한다. SSH 접속이 불가능하고, EC2에서 바로 접속할 수 없다.

[데이터베이스 엔진의 종류]

데이터베이스 엔진이란. 데이터베이스에 데이터를 저장, 조직화, 인출하는 소프트웨어이며, 각 데이터베이스 인스턴스는 오직 하나의 데이터베이스 엔진만 실행한다.

• MySQL : 블로그, 커머스 등 OLTP 애플리케이션에 적합하며, RDS는 최신의 MySQL Community Edition 버전을 제공한다. MySQL은 MyISAM과 InnoDB, 두개의 스토리지 엔진을 지원하지만 RDS의 자동 백업 기능과 호환성이 있는 InnoDB를 사용한다.
• MariaDB : MySQL이 Oracle에 인수되면서 개방성 및 사용성에 제약이 생길 것을 우려해서 만든 MySQL의 대체품이라 할 수 있으며, 스토리지 엔진으로 XtraDB 및 InnoDB를 지원하지만 RDS와의 호환성을 위해서 InnoDB를 사용하는 것을 권장한다.
• Oracle : 가장 널리 사용되는 DBMS로서, 일부 애플리케이션은 오직 Oracle데이터베이스 기반으로만 실행되기도 한다. RDS가 제공하는 Oracle Database 에디션에는 Standard Edition One(SE1), Stadard Edition Two(SE2), Stadard Edition (SE), Enterprise Edition(EE)가 있다.
• PostreSQL : Oracle 호환 오픈소스 데이터베이스이며, Oracle용으로 개발된 내부용 애플리케이션을 좀 더 저렴하게 실행할 수 있는 방법이라 할 수 있다.
• Amazon Aurora : Amazon 이 제공하는 MySQL 및 PostgreSQL의 대체품이라 할 수 있으며, 스토리지의 쓰기 횟수를 감소시키는 가상화 스토리지 레이어를 이용해 좀 더 높은 수준의 쓰기 성능을 제공한다. MySQL 호환형과 PostgreSQL 호환성 두개의 에디션을 제공하며, 이 에디션을 선택하면 각 두가지의 import/export 도구와 스냅샷과도 호환되는 데이터베이스를 구성할 수 있으며, 마이그레이션 작업 역시 빈 틈없이 처리할 수 있다.
• MS SQL Server : RDS는 2012년 부터 현재까지의 MS SQL Server 버전을 지원하며, 사용자는 Express , Web Standard 또는 Enterprise 에디션 중 선택할 수 있다. 이 다양한 버전과 에디션을 이용해서 기존 온프레미스 데이터베이스를 별도의 작업 없이 RDS로 이전할 수 있다.

[데이터베이스 옵션 그룹]
각 데이터베이스 엔진들은 관리 및 보안을 위해 다양한 기능과 옵셥을 제공하며, 사용자는 옵셥 그룹을 이용해 하나 이상의 인스턴스에 이들 기능과 옵셥을 쉽게 적용할 수 있다. 옵션 제공을 위해선 상당한 양의 메모리가 필요하므로 사용자의 인스턴스 리소스에 여유가 있는지 확인해야 한다. 옵션은 엔진마다 다르며, Oracle은 Amazon S3 통합 기능을 제공하고, MS SQL과 Oracle은 스토리지 저장전 데이터를 암호화 하는 TDE 암호화 옵션을 제공하며, MySQL 과 Maria DB는 사용자가 데이터베이스 쿼리 작업을 하기 전에 로그인을 요구하는 감사 플러그인을 제공한다.

[데이터베이스 인스턴스 클래스 종류]

EC2 처럼 사용하고자 하는 용도나 요구 성능에 따라 선택할 수 있다.
스탠다드, 메모리 최적화, 성능 가속 등 세가지 타입으로 제공한다.

• 스탠다드 : 384GB 메모리 / 96vCPU / 25Gbps 네트워크 / 19000Mbps 디스크 처리용량
• 메모리 최적화 : 3904GB 메모리 / 128vCPU / 25Gbps 네트워크 / 14000Mbps 디스크 처리용량
• 성능 가속 : 32GB 메모리 / 8vCPU / 5Gbps 네트워크 / 2048Mbps 디스크 처리용량

[스토리지]

데이터베이스 인스턴스에 적합한 스토리지를 선택하는 일은 중요하다. 사용자의 애플리케이션이 원활하게 작동할 수 있는 스토리지의 처리 속도도 중요한 요소이다.

• 초당 입출력 작업량 : AWS 는 스토리지의 성능을 초당 입출력 작업량(IOPS) 으로 측정한다. IOPS 수치가 높을수록 데이터베이스가 더욱 빨리 데이터를 저장하고 인출할 수 있다. RDS 는 사용자가 선택한 스토리지 타입에 따라 IOPS를 할당하며, 사용자는 이 한계치를 넘어서 사용할 수 없다.
• 범용 SSD 스토리지 : 대부분의 데이터베이스에서 범용 SDD 스토리지는 충분한 성능 및 밀리초 수준의 저지연성을 제공한다. 최대 64TB의 볼륨을 할당할 수 있으며, 볼륨의 기가바이트 당 3IOPS의 기본 성능을 제공하고, 볼륨당 최대 16000IOPS의 처리 성능을 활용할 수 있다.
  볼륨 크기가 클수록 성능이 좋아지고 최소 스토리지 볼륨 크기는 20GB이다.
• 프로비전 IOPS SSD 스토리지 : 직관적인 RDS 옵션을 선택할 수 있다. 인스턴스 생성 시 사용자가 원하는 수준의 IOPS를 직접 할당할 수 있다. io1 스토리지에는 성능 가속의 개념이 없으며, 사용자가 필요한 만큼의 IOPS를 할당하고 그에 따른 비용을 지불하면 되므로, 일관되게 높은 수준의 성능이 필요한 경우 유용한 옵션이라 볼 수 있다.
  Oracle, PostgreSQL, MariaDB, MySQL, MSSQL Server, Aurora는 4GB에서 16TB까지의 스토리지를 선택할 수 있고, 64000 프로비전 IOPS를 할당할 수 있다. 기가바이트당 IOPS 비율은 최소 50:1이며, 이는 사용자가 32000IOPS의 성능이 필요할 경우 최소 640GB의 스토리지를 프로비전해야 함을 의미한다.
• 처리용량 최적화 HDD(st1) 스토리지 : 마그네틱 스토리지로 볼륨 크기는 500MB에서 16TB다. 기본 처리용량은 볼륨 크기에 따라 다르겠지만 테라바이트당 40MBps의 처리용량을 제공한다. 16TB 볼륨의 최대 처리용량은 500MBps이다.
• 콜드 HDD(sc1) 스토리지 : 마그네틱 스토리지로 볼륨 크기는 500MB에서 16TB이지만 처리 용량에서 st1과 차이가 있다. 테라바이트당 1MBps의 처리용량을 제공한다. 16TB에서 최대 처리용량은 192MBps이며, st1보다 sc1의 비용이 좀 더 낮다는 장점이 있다.
• 마그네틱 스토리지(스탠다드) : RDS 는 역호환성 유지를 위해 구형 인스턴스를 위한 마그네틱 스토리지를 제공하며, 1TB의 저장용량에 100IOPS의 처리 성능을 제공한다. AWS는 이 타입의 스토리지 지원을 줄이고 있으며, 사용을 권장하지 않는다.

[읽기 전용 복제본]

데이터베이스 인스턴스가 요구 성능 수준에 미치지 못할 경우 수직적 확장 또는 수평적 확장 옵션으로 성능 수준을 높일 수 있다.

• 수직적 확장 : 데이터베이스 운영에 있어 메모리 양, 컴퓨트 성능, 네트워크 속도, 디스크 처리용량 등이 문제가 되면 애플리케이션 또는 데이터베이스는 그대로 둔 채 인스턴스와 관련된 리소스만 추가하는 방법으로 문제를 해결할 수 있다. 인스턴스의 클래스를 업그레이드하는 이와 같은 방식을 수직적 확장 또는 스케일 업이라 부른다.
• 수평적 확장 : 스케일 아웃이라 불리며, 데이터베이스 인스턴스를 추가하는 방법으로 구현 가능하다. MS SQL Sever 를 제외한 모든 데이터베이스 엔진이 읽기 전용 복제본을 지원하며, Aurora의 경우 독자적인 읽기 전용 복제본인 Aurora Replica를 제공한다.

읽기 전용 복제본은 읽기 작업이 많은 애플리케이션에 유용하고, RDS는 5개의 읽기 전용 복제본을 지원하고 Aurora의 경우 15개를 생성할 수 있다. 마스터 데이터는 비동기적으로 읽기 전용 복제본에 저장되므로 마스터에 데이터가 기록된 시점과 읽기 전용 복제본에서 해당 데이터를 읽을 수있는 시점에는 약간의 차이가 발생한다. 데이터 유실의 문제가 중요한 이슈인 경우, 읽기 전용 복제본은 재난 복구용으로 적합하지 않다.
읽기 전용 복제본과 마스터는 서로 다른 AZ, 서로 다른 리전에 있어도 무방하며, 마스터 읽기 실패 시 읽기 전용 복제본이 마스터로 승격된다.

[고가용성 구현(멀티AZ)]

장애에 대비해서 데이터베이스 인스턴스는 다수의 AZ에 배포하는 것이 좋으며, 이를 멀티 AZ배포 라고 부른다. 프라이버리, 스탠바이로 두고 프라이머리 인스턴스가 중단도면 2분 내에 스탠바이 인스턴스로 데이터베이스를 복구하는 방식이다.
멀티 AZ를 배포하려면 기본적으로 모든 인스턴스가 동일한 리전에 있어야 한다. RDS 는 동기적으로 프라이머리 인스턴스에서 스탠바이 인스턴스로 데이터를 복제하며, 이 때 성능 저하가 발생할 수 있으므로, 가급적 EBS 최적화 인스턴스 및 프로 비전 IOPS SSD 스토리지 사용을 권장한다. 인스턴스 중단 사태 발생 시에 RDS 프라이머리 엔드포인트에 연결된 DNS를 스탠바이 엔드포인트로 변경하며, 애플리케이션을 이 엔드포인트에 다시 연결하기만 하면된다.
MySQL과 MariaDB 만 예외로 다른 리전에서 멀티 AZ를 배포할 수 있다.

[Amazon Aurora 멀티 AZ 구성]

• 싱글 마스터 : 프라이머리 인스턴스를 구성하며, Aurora는 프라이머리 인스턴스를 가리키는 클러스터 엔드포인트를 제공한다. Aurora 클러스터에는 Aurora 레플리카 또는 읽기 복제본이 포함될 수 있다. 프라이머리 인스터스와 레플리카는 3개의 AZ에서 동기적으로 복제되는 클러스터 볼륨을 공유하고, 이 때의 클러스터 볼륨은 필요에 따라 자동으로 64TB 까지 확장할 수 있다. 프라이머리 인스턴스 실패시에 레플리카가 없는 경우 Aurora 는 자동으로 새 프라이머리 인스턴스를 생성하고
  레플리카가 있는 경우엔 이 레플리카를 프라이머리로 승격시킨다. 이 모든 작업은 2분 이내로 완료된다.
• 멀티 마스터 : 모든 인스턴스가 데이터베이스를 기록할 수 있으며, 하나의 인스턴스가 실패하더라도 별도의 페일 오버 작업이 실행되지 않고, 다른 모든 인스턴스가 공유 클러스터 볼륨에 데이터를 기록한다. Amazon은 이것을 고가용성보다는 지속적 가용성으로 부르는데, 최소 하나 이상의 데이터베이스 인스턴스만 실행되더라도 데이터베이스 읽기 및 쓰기 작업을 차질 없이 계속 수행할 수 있기 때문이다.

[백업과 복원]

RDS를 사용하면 데이터베이스 인스턴스의 EBS 볼륨 스냅샷을 기록할 수 있다. 스냅샷에는 인스턴스에 있는 모든 데이터베이스와 S3에 저장된 데이터까지 기록되며, 중복구현을 위해 동일 리전, 다수의 AZ에 저장된다. 멀티 AZ 기반의 데이터베이스 엔진을 사용하지 않는 한 , 스냅샷 생성시 몇 초간 모든 I/O 작업이 중단된다.
그리고 RDS는 자동으로 매일 30분간의 백업 윈도우 기간 동안 인스턴스의 스냅샷을 생성할 수 있다. 이 백업 윈도우는 사용자가 직접 설정하거나 RDS가 선택하도록 설정해서 랜덤으로 생성 할 수 있도록 할 수 있다. 스냅샷 보관 기간은 1일 ~ 35일 까지 가능하고 기본으로 7일이다.

[유지보수 항목]

RDS 는 관리형 서비스이므로 패치 및 업그레이드 등 데이터베이스 관리와 관련된 모든 작업을 AWS가 처리한다. 주기적으로 인스턴스에 대한 유지보수 업무를 수행하며 OS 보안패치, 신뢰성 요소 추가 등이 포함된다. 데이터베이스 엔진 업그레이드도 수행하는데 사용자는 업그레이드 실행 여부를 선택할 수 있다. 이 유지보수 윈도우도 작업 시간대를 정할 수 있는데 당연히 백업 윈도우와 시간이 겹치지 않도록 해야 한다.

[Amazon Redshift]

관리형 데이터 웨어하우스 서비스이며, PostreSQL을 기반으로 하지만 RDS와는 별개로 존재한다. Rdeshift는 칼럼 단위로 데이터를 저장하는 칼럼형 스토리지로서 저장속도가 빠르고 효율적이며, 개별 칼럼에서 신속하게 쿼리 작업을 수행한다. ODBC 및 JDBC 데이터베이스 커넥터를 지원한다.
스토리지에서 소요되는 칼럼의 수를 줄이기 위해 압축 인코딩 기법을 사용하며, 사용자가 수동으로 칼럼 단위로 압축할 수도 있다. 파일에서 COPY명령을 이용해 Redshift 데이터베이스에 데이터를 임포트하는 경우 Redshift는 어떤 칼럼을 압축할지 결정한다.

• 컴퓨트 노드 : Redshift는 하나 이상의 컴퓨트 노드를 지니며, 컴퓨트 노드는 덴스 및 리더 두가지 종류가 있다. 덴스 컴퓨트 노드는 마그네틱 스토리지에 최대 326TB의 데이터를 저장할 수 있으며, SSD에는 최대 8192TB의 데이터를 저장할 수 있다.
• 데이터 분산 유형 : Redshift 데이터베이스의 행은 다수의 컴퓨트 노드에 분산 저장되며, 데이터 분산 방식으로는 EVEN, KEY, ALL 등의 유형이 있다. EVEN은 기본 분산 유형으로 리더 노드가 모든 컴퓨트 노드에 균일하게 분산된다. KEY 분산의 경우 단일 칼럼 내 값에 따라 데이터가 분산되며, 동일한 값의 칼럼은 동일한 노드에 저장된다. ALL 분산의 경우 각각의 테이블이 모든 컴퓨트 노드에 분산 저장된다.
• Redshift Spectrum : S3에 저장된 파일에서 데이터를 쿼리할 수 있는 서비스로서 클러스터로 데이터를 임포트할 필요가 없다는 장점이 있다. 사용자는 간단하게 데이터의 구조를 정의하고 원하는 내용으로 쿼리 명령을 실행하면 된다. 쿼리를 실행하려는 버킷은 클러스터와 동일한 리전에 있어야 한다.

[AWS DMS, 데이터베이스 마이그레이션 서비스]

AWS DMS 는 기존 데이터베이스와 스키마를 자동으로 복사해서 다른 데이터베이스에 저장할 수 있다. DMS의 가장 큰 장점이자 주요 기능은 서로 다른 데이터베이스 엔진 간의 마이그레이션, 관계형 및 비관계형 데이터베이스 간의 마이그레이션을 지원한다는 점이다. DMS 가 지원하는 데이터베이스 엔진으로는 Aurora, DynamoDB, IBM DB2, MariaDB, MongoDB, MySQL, Oracle, PostreSQL, Redshift, S3, SAP 이 있다.

비관계형 데이터베이스

초당 수만 회 이상의 데이터 트랜잭션을 일관되게 처리할 수 있도로 설계됐으며, 관계형 데이터베이스에 저장할 수 있는 데이터도 저장할 수 있지만, 무엇보다 비구조화 데이터를 저장하는 데 최적화된 데이터베이스 모델이다. 데이터베이스에 저장되는 모든 데이터는 나름 다양한 구조를 지니며, 시간 경과에 따라 이들 구조가 바뀔 수 있다는 것이 특징이다.
관계형 DB 와의 공통점으로 콜렉션이라는 요소로 구성되며 테이블이라고도 불리는 것을 이용해 아이템을 저장하며 관계형 DB의 로우 또는 튜플과 비슷하다. 각 아이템은 하나 이상의 속성으로 구성되며, 이는 SQL 데이터베이스의 칼럼과 비슷하다. 속성은 유일한 이름인 키, 데이터 타입, 값으로 구성되므로 속성을 간단한 키/밸류 쌍으로도 부른다.

[데이터 정렬하기]

관계형 과 비관계형의 가장 큰 차이점은 스키마가 없다는 것과 테이블 내 모든 아이템이 동일한 속성을 지닐 필요도 없다는 것이다. 각 아이템은 테이블 내에서 유일한 값을 지닌 기본 키 속성을 지닌다. 기본 키는 아이템을 식별하고 아이템 정렬 시 값을 부여하는 데 사용된다.
비관계형은 저장할 수 있는 데이터 타입이 다양하다. 기본 키 속성을 제외하고는 테이블 생성 시 별도의 속성을 정의할 필요가 없으며, 아이템 생성 또는 변경 시 속성을 추가하면 된다. 이들 속성은 무순위이며, 서로 별도의 관계성을 지니지 않으므로 비관계형으로 부른다. 그리고 테이블에서 쿼리 작업을 위한 데이터 분할, 병합 기능을 제공하지 않으므로 애플리케이션 테이블 내에서 데이터의 변경 내용을 지속적으로 추적해야 한다.

[데이터 조회하기]

비관계형 DB는 비구조화 데이터를 저장할 수 있는 유연성을 제공하지만 이 부분이 바로 사용자의 쿼리 가능 영역을 제한하는 원인이 되기도 한다. 비관계형 DB는 기본 키를 기준으로 한 쿼리 작업에 최적화됐으며, 다른 속성으로 쿼리 작업을 수행하면 속도가 느려지게 된다. 이런 이유로 비관계형 DB는 복잡한 쿼리 작업 또는 임의의 쿼리 작업에는 적합하지 안핟. 사용자는 테이블 생성 전, 데이터에서 어떤 속성을 쿼리할 것인지 미리 파악하고 있어야 한다.

[비관계형 데이터베이스의 종류]

키/밸류 스토어 타입과 도큐먼트 지향 스토어 타입, 두가지가 존재한다고 하지만, 엄밀히 말하면 기본적으로 키/밸류 스토어 데이터베이스 라고한다.

[DynamoDB]

각종 관리 업무를 지원하는 비관계형 데이터베이스 서비스로서 다수의 파티션에 분산된 데이터 구조를 이용해서 초당 수천 회의 읽기 및 쓰기 작업을 처리한다. 여기서 파티션이란 테이블을 위한 스토리지 할당 영역이며, 다수의 AZ 에 존재하는 SSD 장치를 이용한다.

• 파티션과 해시 키 : 테이블 생성 시 기본 키와 데이터 타입을 명시해야 하며 기본 키는 테이블 내 유일한 식별자로서 그에 대응하는 값 또는 테이블 내에서 유일해야 한다. 키는 두가지 타입이고 첫 번째로 파티션 키는 해시 키라도 불리며, 하나의 값을 지닌 기본 키다. 2048 바이트를 넘지 않는 선에서 사용자가 이메일 주소, 유일한 유저네임, 임의로 생성한 식별자를 사용하면 된다.

[속성과 아이템]

속성이란 하나의 키/밸류 쌍을 의미하고, 하나 이상의 속성이 모인 것을 아이템이라 부른다. DynamoDB에서 아이템의 최대 용량은 400KB 이며, 약 50,000개의 영어 단어를 저장할 수 있는 수준이다.

[처리 용량 옵션 선택]

테이블 생성 시 DynamoDB를 온디맨드 모드 또는 프로비전 모드로 선택해서 사용할 수 있다. 온디맨드 모드의 경우 DynamoDB는 자동으로 워크로드에 맞춰 확장하므로 사용자가 요구되는 워크로드의 수준을 파악할 수 없을 때, 또는 사용한 용량만큼만 지불하고 싶을 때 유용하다.

[데이터 읽기]

DynamoDB는 스캔과 쿼리, 두 가지의 테이블 읽기 방식을 제공한다. 먼저 스캔은 테이블 내 모든 아이템을 반환한다. 읽기 집약적인 방식이므로 사용자가 읽기 유닛을 모두 소진할 수 있다. 쿼리는 파티션 키 값에 따라 아이템을 반환한다. 쿼리 실행 시 파티션 키와 정확하게 일치하는 아이템만 반환된다. 테이블에 소트 키가 있는 경우 소트 키를 이용해서 쿼리 작업을 할 수 있다. 소트 키는 좀 더 유연한 작업을 할 수 있도록 해주며, 정확한 값으로 찾기, 키보다 크거나 작은 값 비교해서 찾기, 값의 범위로 찾기, 시작값으로 찾기 등 다양하다.

• 보조 인덱스 : Author 테이블에서 파티션 키로 LastName, 소트 키로 FirstName 을 지정한 경우 보조 인덱스를 이용해서 테이블의 기본 키 없이 속성으로 데이터를 조회할 수 있다. 보조 인덱스는 테이블에 있는 속성 중 일부라고 할 수 있으며, 보조 인덱스가 속성 정보를 가져오는 테이블을 베이스 테이블이라 한다.
  전역 보조 인덱스 와 지역 보조 인덱스로 나뉘고 전역 보조 인덱스는 테이블 생성 후에 언제든 생성할 수 있으며, 파티션 키와 해시 키가 베이스 테이블에서와는 다른 기능을 수행한다. 전역 보조 인덱스로 읽기 작업을 수행하는 경우 종국적 일관성의 읽기 작업이 이뤄진다. 따라서 테이블에 아이템을 추가하면 보조 인덱스에 즉시 반영되지 않을 수 있다. 지역보조 인덱스는 베이스 테이블과 함께 생성해야 하며 생성한 후에는 지역 보조 인덱스만 삭제할 수 없다. 파티션 키는 베이스 테이블과 항상 같이 존재해야 하지만, 소트 키는 다르다. 사용자의 설정에 따라 강한 일관성 또는 종국적 일관성 모두가 가능하다.

[전역 테이블]

가용성을 높이기 위해 다수의 리전에 해당 테이블을 복제해서 사용할 수 있다. 전역 테이블을 사용하기 위해선 온디맨드 또는 프로비전 모드를 설정한 뒤 Auto scaling을 활성화 해야한다.

[백업]

백업은 언제든 가능하며, RCU를 소모하지 않고 DynamoDB의 성능에 영향을 주지 않는다. 횟수에도 제한이 없고, 동일한 리전 또는 다른 리전에 있는 테이블의 백업으로 복구도 가능하다. 복구시엔 온디맨드 또는 프로비전 모드를 적용할 수 있고 인덱스 및 암호화 옵션도 설정 가능하다.