DynamoDB를 사용해야 하는 경우와 사용하지 않는 경우

DynamoDB는 워크로드를 위한 환상적인 데이터베이스이지만 실망스럽습니다. 나머지 하나. 결정적인 질문은 "나는 알고 있는가? 내 액세스 패턴이 미리 표시되어 있고 키 기반인가요?" 올바르게 파악하고 DynamoDB를 사용하세요. 어떤 규모에서도 한 자릿수 밀리초의 판독값을 제공합니다. 잘못하면 싸울 거야 조인 및 임시 쿼리가 영원히 부족합니다.

DynamoDB는 언제 사용해야 합니까?

액세스 패턴이 알려져 있고 키 기반이며 대용량인 경우 DynamoDB를 사용하십시오. 서버 없이 모든 규모에서 예측 가능한 한 자릿수 밀리초의 대기 시간을 원합니다. 관리하다. 임시 쿼리, 풍부한 조인 또는 전체 데이터 세트 분석의 경우에는 피하세요. 쿼리 모양이 계속 변경되어 데이터가 작습니다.

액세스 패턴이 알려져 있고 키 기반이며 대용량인 경우 DynamoDB를 사용하십시오. — 관리할 서버 없이 규모에 관계없이 예측 가능한 대기 시간을 원합니다.
임시 쿼리, 리치 조인 또는 전체 분석이 필요한 경우에는 피하세요 또는 데이터가 작고 쿼리 형태가 계속 변하는 경우입니다.
핵심 거래: DynamoDB를 사용하면 쿼리를 미리 설계할 수 있습니다. 그 대가로 성장함에 따라 결코 속도가 느려지지 않습니다.
그것은 다른 구문을 가진 관계형 데이터베이스가 아닙니다. 마치 데이터베이스처럼 모델링하는 것입니다. 고통의 근원 1위.

DynamoDB를 선호하는 신호

DynamoDB는 다음 중 대부분이 유지될 때 빛을 발합니다.

접속 패턴을 미리 알 수 있습니다. 앱에서 정확한 검색어를 나열할 수 있습니다. ("ID로 사용자 가져오기", "사용자의 주문을 최신순으로 나열")을 수행하고 변경되지 않습니다. 변덕스럽게. DynamoDB는 이러한 쿼리를 _주변_으로 모델링됩니다.
액세스는 키 기반입니다. 스캔이 아닌 알려진 파티션 키로 항목을 찾습니다. 임의의 속성 조합의 경우.
규모 및 예측 가능한 지연 시간이 중요합니다. DynamoDB는 다음을 제공합니다. consistent single-digit-millisecond 테이블에 항목이 1,000개가 있든, 10억 개가 있든 관계없이 성능이 향상됩니다.
운영 오버헤드가 전혀 필요하지 않습니다. 인스턴스 없음, 장애 조치 없음, 진공 제거 없음 — 완벽하게 관리되며 주문형으로 확장됩니다.
쓰기 처리량이 높고 급증합니다. 이벤트 로그, IoT 원격 측정, 세션/카트 상태, 순위표 — 명확한 키가 있는 추가 작업이 많은 워크로드입니다.

이에 대한 신호

다음과 같은 경우에는 관계형 데이터베이스(또는 검색/분석 엔진)를 활용하세요.

귀하의 쿼리는 임시적입니다. 분석가는 임의의 열로 데이터를 분할합니다. 요구 사항은 매주 변경됩니다. SQL의 유연성이 승리합니다. DynamoDB에는 새 인덱스가 필요합니다 패턴당.
전체 데이터 세트에 대한 실제 조인 및 집계가 필요합니다. 보고, 비즈니스 인텔리전스, "월별 지역별 수익 합계" — OLAP/관계형 직업. (라이브 테이블에 대한 일회성 질문은 다른 경우입니다. DynoTable's SQL Workbench은 JOIN, GROUP BY, DynamoDB 클라이언트 측을 통해 집계합니다. 이는 상시 BI 워크로드입니다. 다른 곳에 속합니다.)
데이터 세트가 작고 트래픽이 적습니다. 조용한 관리 앱의 수천 행 DynamoDB의 규모로 인한 이점을 얻지 못하고 SQL의 편의성을 잃습니다.
액세스 패턴은 아직 예측할 수 없습니다. 초기 단계 제품은 아직 탐색 중입니다. 모양? 자유롭게 다시 쿼리할 수 있는 관계형 스키마는 패턴이 정착됩니다.

DynamoDB를 다른 데이터베이스와 비교하는 방법

"DynamoDB를 사용해야 할까요, 아니면 X를 사용해야 할까요?" 일반적으로 다른 옷을 입고도 같은 질문입니다: do X 액세스 패턴 결정을 연기하겠습니다. 이에 대한 비용은 얼마입니까? DynamoDB는 당신이 그것을 연기하는 것을 거부하는 옵션. 아래의 모든 비교는 그 비교를 활성화합니다 기능 체크리스트가 아닌 거래.

관계형: PostgreSQL, RDS 및 Aurora

이것은 실제 포크이며 대부분의 팀이 잘못하는 것입니다. 관계형 데이터베이스를 사용하면 데이터를 얻은 후에 쿼리를 작성하세요. DynamoDB는 그렇지 않습니다. 테이블은 단일 항목이 기록되기 전에 쿼리합니다.

쿼리 형태가 여전히 이동 중일 때, 조인이 필요할 때 관계형을 선택하거나 전체 데이터 세트에 걸쳐 집계하거나 데이터 규모가 충분하지 않을 정도로 작은 경우 당신이 가지고 있는 문제. 패턴이 확정되고 키 기반이 되면 DynamoDB를 선택하세요. 10억 개 품목의 가격이 1000개 품목의 가격과 같기를 원합니다.

RDS와 Aurora는 해당 미적분학을 변경하지 않습니다. 관리되는 관계형 엔진이므로 SQL의 유연성과 확장 모델을 상속합니다. 그들이 바꾸는 것은 운영이다 비교: Aurora Serverless를 사용하면 DynamoDB에 대한 "관리할 서버가 없음" 인수가 발생합니다. 훨씬 약하고 결정은 액세스 패턴에 따라 완전히 돌아갑니다. 오로라 비늘 계산하다; DynamoDB는 이러한 개념을 제거합니다.

문서: MongoDB 및 DocumentDB

둘 다 JSON 형식의 문서를 저장하므로 멀리서 보면 DynamoDB와 상호 교환 가능한 것처럼 보입니다. 그렇지 않습니다. MongoDB는 모든 필드를 인덱싱하고 이에 대해 임시 쿼리를 실행합니다. DynamoDB는 다음을 제공합니다. 미리 선언한 파티션 키, 정렬 키 및 인덱스입니다.

따라서 MongoDB는 진화하는 쿼리 형태에 더 적합하고 DynamoDB는 더 적합합니다. 알려진 볼륨의 경우. DocumentDB는 같은 줄의 AWS 측에 있습니다. MongoDB API를 말하므로 "MongoDB의 유연성, AWS의 운영 모델"로 취급하십시오. 위의 유연성 대 예측 가능성 축에서 DynamoDB와 정확하게 비교해 보세요.

와이드 컬럼: Cassandra

Cassandra는 DynamoDB의 가장 가까운 아키텍처 관련 제품인 파티션 키, 클러스터링입니다. 잘못된 파티션 키는 색인을 생성할 수 없는 설계 버그라는 것과 동일한 엄연한 사실입니다. 나가는 길. 둘 중 하나를 선택하는 경우 결정 요인이 되는 경우는 거의 없습니다. 데이터 모델 - 이를 실행하는 사람과 비용을 지불하는 방법입니다. Cassandra는 귀하가 운영(또는 관리 구매)합니다. 귀하가 소비하는 DynamoDB. Amazon Keyspaces는 관리형 Cassandra의 중간 지점입니다.

모델이 너무 가깝기 때문에 이 사이트의 모델링 지침은 대부분 다음과 같이 전달됩니다. single-table design 파티션 키에 대한 추론 액세스 패턴은 거의 한 줄씩 Cassandra에 적용됩니다.

인메모리: Redis

Redis와 DynamoDB는 서로 다른 문제를 해결합니다. Redis는 메모리 우선이며 밀리초 미만의 액세스에 최적화되어 있습니다. 손실하거나 재구축할 수 있는 데이터 DynamoDB는 기본적으로 내구성이 있습니다. 일반적인 프로덕션 답변은 둘 다입니다. 기록 시스템으로서의 DynamoDB, Redis(또는 DAX) DynamoDB의 자체 읽기 캐시)가 바로 가기 키 앞에 있습니다.

데이터가 실제로 일시적인 경우에만 Redis를 사용하세요. 속도 제한 카운터, 단기 세션, 다시 계산할 수 있는 순위표.

검색: Elasticsearch 및 OpenSearch

검색과 DynamoDB는 서로 다른 문제도 해결합니다. Redis보다 더 분명한 이유는 다음과 같습니다. DynamoDB에는 전체 텍스트가 없습니다. 전혀 검색하지 마세요. Query는 키 동일성과 좁은 정렬 키 조건 집합과 일치합니다. Scan과 FilterExpression는 모든 항목을 읽은 다음 대부분을 버립니다. 검색이 아닌 필터를 켠 채 테이블을 산책하고, 읽은 항목에 대해 비용을 지불합니다. 반환된 품목. 관련성 순위 없음, 분석기 없음, 퍼지 일치 없음, 없음 패싯.

따라서 질문은 결코 "DynamoDB 또는 검색 엔진"이 아닙니다. 그것은 "이 워크로드에 필요한가? 검색하고, 그렇다면 인덱스를 제공하는 것은 무엇입니까?" 표준 형태는 다음과 같습니다. 시스템으로서의 DynamoDB 기록, 검색 클러스터, 그리고 모든 변경 사항을 색인. 이는 실제 검색을 구매하고 실행하는 데 두 번째 시스템과 색인 비용이 발생합니다. 결국 테이블과 일치합니다.

OpenSearch와 Elasticsearch는 동일한 결정입니다. OpenSearch는 AWS의 포크입니다. Elasticsearch, Elastic 라이선스 변경으로 2021년 7.10으로 분할, 둘은 표류 그 이후로 따로. 그 드리프트 중 어느 것도 이 질문에 닿지 않습니다. "검색이 외부에서 진행되어야 하는가?" DynamoDB'는 동일하게 동작합니다. 라이센스, 호스팅 및 어느 것 중에서 선택하십시오. DynamoDB와 관련된 것이 아닌 운영하려는 관리형 서비스입니다.

검색이 진정으로 제품일 때만 검색 엔진을 주요 매장으로 활용하세요 — 로그 분석, 주요 액세스 패턴이 자유 텍스트인 카탈로그입니다. 그럼에도 불구하고 대부분의 팀은 계속해서 그 뒤에는 내구성 있는 저장소가 있습니다. 검색 색인은 파생된 뷰이므로 다음을 수행할 수 있어야 합니다. 재건축.

모델 비교에서 숨겨지는 비용 축

위의 모든 비교는 데이터 모델에 관한 것이지만 청구서에서 놀라운 점은 일반적으로 구조적: 관계형 엔진은 프로비저닝한 용량에 대해 요금을 청구하고, DynamoDB는 요금을 청구합니다. 수행하는 작업. 따라서 급증하는 유휴 워크로드에 대해 DynamoDB를 저렴하게 만들 수 있으며 지속적인 검색에는 비용이 많이 듭니다. 동일한 작업 부하가 하나의 엔진에서 승리하고 심하게 패배할 수 있습니다. 다른 한편으로는 그들 사이에 코드 변경이 없습니다.

사람들이 놓치는 승수는 인덱스입니다. 관계형 엔진에서는 추가 인덱스로 인해 스토리지 비용이 발생합니다. 일부 쓰기 대기 시간; DynamoDB에서 모든 보조 인덱스는 전체 추가 쓰기입니다. 투영된 속성. 우리는 3개의 쓰기 볼륨에서 산술을 계산했습니다. the indexes guide — 하나의 GSI는 쓰기 청구서를 두 배로 늘리고, 두 개의 GSI는 세 배로 늘립니다. 그것. 실제 읽기/쓰기 조합을 모델링하세요. pricing calculator 어느 쪽이든 약속하기 전에.

커밋하기 전에 비용 계산하기

DynamoDB 요금은 인스턴스 시간이 아닌 읽기, 쓰기, 스토리지에 따라 책정됩니다. 변동이 심한 서버리스 워크로드에는 저렴하고 지속적으로 많은 양의 스캔을 수행하는 경우에는 비용이 많이 들 수 있습니다. 실제 읽기/쓰기 조합을 모델링하세요. 커밋하기 전 DynamoDB pricing calculator; 기술적으로 적합해 보이는 워크로드는 비용 측면에서도 명확해야 합니다.

적합하다고 판단되면

작업은 모델링으로 전환됩니다. DynamoDB는 쿼리 주변 테이블 설계에 대한 보상을 제공합니다. — how to model data in DynamoDB 및 single-table design — 그리고 명시적으로 when not to reach for single-table.

DynoTable의 항목 그리드에서 데이터가 채워진 DynamoDB 테이블을 탐색하는 모습.

함정과 다음 단계

관계형 데이터베이스처럼 DynamoDB를 모델링하지 마세요 — 조인하는 정규화된 테이블 읽기 시간은 가장 힘들게 처벌하는 안티 패턴입니다.
분석용으로 선택하지 마세요 — 분석 저장소와 연결(또는 내보내기) 스캔 대신 보고용.
액세스 패턴이 확실하지 않습니까? 잠깐만요. 귀하의 상황을 알기 전에 DynamoDB를 채택하려면 쿼리는 해당 데이터베이스를 알아야 하는 하나의 데이터베이스를 선택하는 것입니다.
관련: query vs scan은 "키 기반 액세스"가 무엇인지 보여줍니다. 실제로 당신을 사요.

앱에 투자하기 전에 DynamoDB 테이블을 탐색하고 싶으십니까? Download DynoTable 데이터에 직접 연결하세요. SQL Workbench은 임시 0을 실행하고 집계합니다. DynamoDB 자체는 그렇지 않습니다.