많은 개발 팀이 이벤트 기반 아키텍처와 사용자 친화적이고 성능이 뛰어난 애플리케이션을 대규모로 구축하기 위해 DynamoDB를 사용하고 있습니다. 운영 데이터베이스인 DynamoDB는 여러 지리적 위치에 배포되는 경우에도 실시간 트랜잭션에 최적화되어 있습니다. 그러나 검색 및 분석 액세스 패턴에 대해서는 강력한 성능을 제공하지 않습니다. DynamoDB의 검색 및 분석 DynamoDB와 같은 NoSQL 데이터베이스는 일반적으로 뛰어난 확장성 특성을 갖고 있지만 온라인 트랜잭션 처리에 초점을 맞춘 제한된 작업 세트만 지원합니다. 이로 인해 효율적인 인덱싱 전략에 크게 의존하지 않고는 데이터를 검색, 필터링, 집계 및 결합하기가 어렵습니다. DynamoDB는 각 항목에 있는 사용자 지정 파티션 키 필드를 기반으로 다수의 노드에 걸쳐 데이터를 분할하여 내부적으로 데이터를 저장합니다. 이 선택적으로 정렬 키와 결합되어 기본 키를 나타낼 수 있습니다. 기본 키는 인덱스 역할을 하므로 쿼리 작업 비용이 저렴해집니다. 쿼리 작업은 파티션 키에 대해 같음 비교(=)를 수행하고 지정된 경우 정렬 키에 대해 비교 작업(>, <, =, BETWEEN)을 수행할 수 있습니다. 사용자 지정 파티션 키는 위 구성표에서 다루지 않는 분석 쿼리를 수행하려면 일반적으로 전체 DynamoDB 테이블을 병렬로 스캔하여 실행되는 스캔 작업을 사용해야 합니다. 이러한 스캔은 전체 테이블을 완전히 읽어야 하기 때문에 읽기 처리량 측면에서 느리고 비용이 많이 들 수 있습니다. 또한 결과를 생성하기 위해 스캔할 데이터가 많아지기 때문에 테이블 크기가 커지면 스캔 속도가 느려지는 경향이 있습니다. 엄청난 스캔 비용을 발생시키지 않고 분석 쿼리를 지원하려면 다음에 논의할 보조 인덱스를 활용할 수 있습니다. DynamoDB에서 인덱싱 DynamoDB에서는 자주 쿼리되는 필드를 인덱싱하여 애플리케이션 성능을 향상시키기 위해 보조 인덱스가 자주 사용됩니다. 보조 인덱스에 대한 쿼리 작업은 명확하게 정의된 요구 사항이 있는 분석 쿼리를 통해 특정 기능을 강화하는 데에도 사용할 수 있습니다. 보조 인덱스는 쿼리하려는 필드에 대한 파티션 키와 선택적 정렬 키 생성으로 구성됩니다. 보조 인덱스에는 두 가지 유형이 있습니다. LSI(로컬 보조 인덱스): LSI는 단일 파티션의 해시 및 범위 키 속성을 확장합니다. GSI(글로벌 보조 인덱스): GSI는 단일 파티션이 아닌 전체 테이블에 적용되는 인덱스입니다. 그러나 것처럼 DynamoDB에서 GSI를 과도하게 사용하면 비용이 많이 들 수 있습니다. DynamoDB의 분석은 매우 간단한 포인트 조회나 작은 범위 스캔에만 사용되지 않는 한 보조 인덱스를 과도하게 사용하고 높은 비용을 초래할 수 있습니다. Nike가 발견한 기본 테이블에 대한 모든 업데이트는 해당 GSI에서도 이루어져야 하기 때문에 인덱스를 사용할 때 프로비저닝된 용량에 대한 비용이 빠르게 증가할 수 있습니다. 실제로 AWS는 조언합니다. 프로비저닝된 쓰기 용량의 비용은 구성된 GSI 수에 따라 선형적으로 증가하므로 많은 액세스 패턴을 지원하기 위해 많은 GSI를 사용하는 것은 비용이 너무 많이 듭니다. 기본 테이블에 대한 쓰기 제한 및 애플리케이션 손상을 방지하기 위해 글로벌 보조 인덱스에 대해 프로비저닝된 쓰기 용량이 기본 테이블의 쓰기 용량과 같거나 커야 한다고 또한 DynamoDB는 배열 및 객체를 포함한 중첩 구조의 데이터를 인덱싱하도록 잘 설계되지 않았습니다. 데이터를 인덱싱하기 전에 사용자는 데이터를 비정규화하여 중첩된 개체와 배열을 평면화해야 합니다. 이로 인해 쓰기 횟수와 관련 비용이 크게 늘어날 수 있습니다. 분석을 위한 DynamoDB 보조 인덱스 사용에 대한 자세한 내용은 블로그 참조하세요. DynamoDB 분석을 위한 보조 인덱스를 결론은 분석 사용 사례의 경우 복잡한 분석을 효율적으로 실행하기 위한 외부 보조 인덱스 역할을 하는 다른 도구 또는 서비스와 DynamoDB 테이블을 동기화하여 상당한 성능 및 비용 이점을 얻을 수 있다는 것입니다. DynamoDB + 엘라스틱서치 데이터에 대한 보조 인덱스를 구축하는 한 가지 접근 방식은 Elasticsearch와 함께 DynamoDB를 사용하는 것입니다. Elastic Cloud 또는 Amazon OpenSearch Service와 같은 클라우드 기반 Elasticsearch를 사용하여 인덱스 크기, 복제 및 기타 요구 사항에 따라 노드를 프로비저닝하고 구성할 수 있습니다. 관리형 클러스터는 업그레이드, 보안 및 성능 유지를 위해 몇 가지 작업이 필요하지만 EC2 인스턴스에서 직접 실행하는 것보다는 덜합니다. 사용하는 접근 방식은 지원되지 않고 설정하기가 다소 어렵기 때문에 대신 DynamoDB Streams 및 AWS Lambda 함수를 사용하여 DynamoDB에서 Elasticsearch로 쓰기를 스트리밍할 수 있습니다. 이 접근 방식을 사용하려면 다음 두 가지 개별 단계를 수행해야 합니다. Amazon DynamoDB용 Logstash 플러그인을 먼저 DynamoDB 스트림에서 호출되는 람다 함수를 생성하여 DynamoDB에서 발생하는 각 업데이트를 Elasticsearch에 게시합니다. 그런 다음 람다 함수(또는 람다 실행 제한 시간보다 오래 걸릴 경우 스크립트를 실행하는 EC2 인스턴스)를 생성하여 DynamoDB의 모든 기존 콘텐츠를 Elasticsearch에 게시합니다. 테이블에 대한 쓰기가 누락되지 않도록 하려면 올바른 권한으로 이러한 람다 함수를 모두 작성하고 연결해야 합니다. 필수 모니터링과 함께 설정되면 DynamoDB에서 Elasticsearch로 문서를 수신하고 Elasticsearch를 사용하여 데이터에 대한 분석 쿼리를 실행할 수 있습니다. 이 접근 방식의 장점은 Elasticsearch가 전체 텍스트 인덱싱과 여러 유형의 분석 쿼리를 지원한다는 것입니다. Elasticsearch는 대시보드를 빠르게 구축하는 데 도움이 되는 시각화를 위해 Kibana와 같은 도구와 다양한 언어로 클라이언트를 지원합니다. 클러스터가 올바르게 구성되면 Elasticsearch로 흐르는 데이터에 대한 빠른 분석 쿼리를 위해 쿼리 대기 시간을 조정할 수 있습니다. 단점은 솔루션의 설치 및 유지 관리 비용이 높을 수 있다는 점입니다. 관리형 Elasticsearch라도 기본 인스턴스의 복제, 리샤딩, 인덱스 증가, 성능 조정을 처리해야 합니다. Elasticsearch는 컴퓨팅과 스토리지를 분리하지 않는 긴밀하게 결합된 아키텍처를 갖추고 있습니다. 이는 리소스를 독립적으로 확장할 수 없기 때문에 리소스가 과도하게 프로비저닝되는 경우가 많다는 것을 의미합니다. 또한 읽기 및 쓰기와 같은 여러 워크로드가 동일한 컴퓨팅 리소스를 두고 경합하게 됩니다. Elasticsearch도 업데이트를 효율적으로 처리할 수 없습니다. 필드를 업데이트하면 전체 문서의 색인이 다시 생성됩니다. Elasticsearch 문서는 변경할 수 없으므로 업데이트하려면 새 문서를 인덱싱하고 이전 버전을 삭제된 것으로 표시해야 합니다. 이로 인해 변경되지 않은 필드도 다시 색인화하고 업데이트 시 전체 문서를 작성하기 위해 추가 컴퓨팅 및 I/O가 소비됩니다. DynamoDB 스트림에서 업데이트가 확인되면 람다가 실행되기 때문에 로 인해 지연 시간이 급증할 수 있습니다. 설정에는 DynamoDB 스트림의 이벤트를 올바르게 처리하고 Elasticsearch에 쓸 수 있는지 확인하기 위한 지표와 모니터링이 필요합니다. 콜드 스타트 기능적으로 분석 쿼리 측면에서 . Elasticsearch 사용자는 이러한 제한을 해결하기 위해 데이터를 비정규화하거나, 애플리케이션 측 조인을 수행하거나, 중첩된 개체 또는 상위-하위 관계를 사용해야 하는 경우가 많습니다. Elasticsearch에는 둘 이상의 인덱스가 포함된 복잡한 분석 쿼리에 유용한 조인에 대한 지원이 부족합니다 장점 전체 텍스트 검색 지원 여러 유형의 분석 쿼리 지원 DynamoDB의 최신 데이터로 작업 가능 단점 수집, 인덱싱, 복제, 샤딩을 위한 인프라 관리 및 모니터링 필요 긴밀하게 결합된 아키텍처로 인해 리소스 과잉 프로비저닝 및 컴퓨팅 경합이 발생함 비효율적인 업데이트 DynamoDB와 Elasticsearch 간의 데이터 무결성과 일관성을 보장하려면 별도의 시스템이 필요합니다. 서로 다른 인덱스 간의 조인을 지원하지 않습니다. 이 접근 방식은 Kibana를 사용하여 DynamoDB 및 대시보드의 데이터에 대한 전체 텍스트 검색을 구현할 때 효과적입니다. 그러나 프로덕션 환경에서 Elasticsearch 클러스터를 조정하고 유지 관리하는 데 필요한 작업, 리소스의 비효율적인 사용 및 조인 기능 부족은 어려울 수 있습니다. DynamoDB + 로켓세트 QPS 요구 사항이 높은 실시간 애플리케이션을 지원하기 위해 주로 구축된 완전 관리형 검색 및 분석 데이터베이스입니다. OLTP 데이터베이스의 데이터에 대한 외부 보조 인덱스로 자주 사용됩니다. Rockset은 Rockset에는 DynamoDB와 Rockset 간에 데이터 동기화를 유지하는 데 사용할 수 있는 DynamoDB 커넥터가 내장되어 있습니다. 콘텐츠를 동기화하려는 DynamoDB 테이블과 테이블을 인덱싱하는 Rockset 컬렉션을 지정할 수 있습니다. Rockset은 전체 스냅샷에서 DynamoDB 테이블의 내용을 인덱싱한 다음 새로운 변경 사항이 발생할 때마다 동기화합니다. Rockset 컬렉션의 콘텐츠는 항상 DynamoDB 소스와 동기화됩니다. 정상 상태에서는 몇 초 이상 간격을 두지 않습니다. Rockset은 스트림 상태를 모니터링하고 DynamoDB의 스트리밍 변경 사항에 대한 가시성을 제공하여 DynamoDB 테이블과 Rockset 컬렉션 간의 데이터 무결성과 일관성을 자동으로 관리합니다. 스키마 정의가 없으면 Rockset 컬렉션은 필드가 추가/제거되거나 DynamoDB에서 데이터 자체의 구조/유형이 변경될 때 자동으로 적응할 수 있습니다. 이는 추가 ETL이 필요하지 않은 및 통해 가능합니다. 강력한 동적 유형 지정 스마트 스키마를 DynamoDB에서 가져온 Rockset 컬렉션은 쿼리용 SQL을 지원하며 개발자가 도메인별 언어를 배우지 않고도 쉽게 사용할 수 있습니다. 또한 REST API를 통해 애플리케이션에 쿼리를 제공하거나 여러 프로그래밍 언어로 클라이언트 라이브러리를 사용하는 데 사용할 수도 있습니다. Rockset이 지원하는 ANSI SQL의 상위 집합은 깊게 중첩된 JSON 배열 및 개체에서 기본적으로 작동하고 모든 필드에 대해 자동으로 구축된 인덱스를 활용하여 복잡한 분석 쿼리에서도 밀리초의 지연 시간을 얻을 수 있습니다. Rockset은 동일한 기본 실시간 데이터를 공유하면서 별도의 컴퓨팅 단위로 워크로드를 격리할 수 있는 개척했습니다. 이는 동일한 데이터 세트에 대한 동시 수집 및 쿼리 또는 여러 애플리케이션을 지원할 때 사용자에게 더 큰 리소스 효율성을 제공합니다. 컴퓨팅-컴퓨팅 분리를 또한 Rockset은 보안, 데이터 암호화 및 액세스 관리를 위한 역할 기반 액세스 제어를 관리합니다. Rockset 사용자는 Rockset에서 설정할 수 있는 활용하여 데이터가 컬렉션에 도착할 때 데이터를 수정함으로써 ETL의 필요성을 피할 수 있습니다. 또한 사용자는 오래된 데이터를 자동으로 삭제하는 보존 정책을 설정하여 선택적으로 데이터 수명 주기를 관리할 수도 있습니다. 데이터 수집과 쿼리 제공이 모두 자동으로 관리되므로 인프라 관리 및 운영의 필요성을 제거하면서 라이브 대시보드와 애플리케이션을 구축하고 배포하는 데 집중할 수 있습니다. 수집 변환을 특히 DynamoDB와의 동기화와 관련하여 Rockset은 비용이 많이 드는 재인덱싱을 방지하기 위해 전체 필드 수준 업데이트를 지원합니다. 작업에 적합한 도구를 선택하려면 수집, 쿼리 및 효율성 측면에서 . Rockset과 Elasticsearch를 비교하세요 요약 높은 QPS를 제공하고 실시간 애플리케이션을 제공하도록 제작되었습니다. 완전한 서버리스. 인프라나 데이터베이스의 운영이나 프로비저닝이 필요하지 않습니다. 예측 가능한 성능과 효율적인 리소스 활용을 위한 컴퓨팅-컴퓨팅 분리 DynamoDB와 Rockset 컬렉션 간의 실시간 동기화를 통해 서로 몇 초 이상 간격을 두지 않도록 합니다. DynamoDB와 Rockset 간의 일관성을 보장하기 위한 모니터링 지연 시간이 짧은 쿼리를 가능하게 하는 데이터 위에 구축된 자동 인덱스 비용이 많이 드는 재인덱싱을 방지하고 데이터 대기 시간을 줄이는 내부 업데이트 Amazon Kinesis, Apache Kafka, Amazon S3 등과 같은 다른 소스의 데이터와 조인합니다. Rockset을 사용하면 운영, 확장 또는 유지 관리에 대한 걱정 없이 구현할 수 있습니다. 이를 통해 실시간 애플리케이션 개발 속도를 크게 높일 수 있습니다. Rockset을 사용하여 DynamoDB 데이터에 애플리케이션을 구축하려면 에서 무료로 시작할 수 있습니다. DynamoDB의 데이터에 대한 실시간 분석을 여기
