고객의 기대와 그에 따른 애플리케이션 요구가 그 어느 때보다 높아졌습니다. 사용자는 애플리케이션이 빠르고 안정적이며 사용 가능하기를 기대합니다. 또한 데이터가 왕이므로 사용자는 통찰력을 찾기 위해 필요에 따라 집계된 데이터를 쪼개고 쪼갤 수 있기를 원합니다. 사용자는 데이터 엔지니어가 새 인덱스를 프로비저닝하거나 새 ETL 체인을 구축할 때까지 기다리기를 원하지 않습니다. 그들은 이용 가능한 최신 데이터에 제한 없이 액세스하기를 원합니다. 그러나 모든 애플리케이션 요구 사항을 처리하는 것은 단일 데이터베이스에 있어서 어려운 작업입니다. 데이터베이스의 경우 개별 레코드에 대해 빈번하고 지연 시간이 짧은 작업을 최적화하는 것은 빈도가 낮은 집계 또는 여러 레코드에 대한 과도한 필터링을 최적화하는 것과 다릅니다. 여러 번 우리는 동일한 데이터베이스로 두 패턴을 모두 처리하고 애플리케이션이 확장됨에 따라 일관되지 않은 성능을 처리하려고 노력합니다. 우리는 최소한의 노력이나 비용으로 최적화하고 있다고 생각하지만 실제로는 그 반대입니다. OLTP 데이터베이스에서 분석을 실행하려면 일반적으로 트래픽 최고치를 고려하여 데이터베이스를 과도하게 프로비저닝해야 합니다. 이는 결국 많은 비용을 초래하고 일반적으로 만족스러운 최종 사용자 경험을 제공하지 못합니다. 이 연습에서는 이러한 두 가지 액세스 패턴을 모두 사용하여 사용자의 높은 요구 사항을 처리하는 방법을 살펴보겠습니다. 우리는 사용자가 거래를 기록하고 최근 거래를 보는 동시에 과거 거래에 대한 복잡한 필터링이나 집계를 원하는 금융 애플리케이션을 구축할 것입니다. 하이브리드 접근 방식 애플리케이션 요구 사항을 처리하기 위해 과 함께 사용하겠습니다. DynamoDB는 트랜잭션을 기록하고 사용자가 찾아볼 수 있도록 최근 트랜잭션 피드를 제공하는 핵심 트랜잭션 액세스 패턴을 처리합니다. Rockset은 DynamoDB를 보완하여 데이터 집약적인 "유쾌한" 액세스 패턴을 처리할 것입니다. 사용자는 시간, 판매자, 카테고리 또는 기타 필드별로 필터링하여 관련 거래를 찾거나 강력한 집계를 수행하여 시간 경과에 따른 지출 추세를 볼 수 있습니다. Rockset Amazon DynamoDB를 이러한 패턴을 살펴보면서 각 시스템이 현재 작업에 어떻게 적합한지 살펴보겠습니다. DynamoDB는 핵심 OLTP 작업(개별 항목 읽기 또는 쓰기, 알려진 필터를 기반으로 다양한 순차 항목 가져오기)에 탁월합니다. 기본 키를 기반으로 데이터를 분할하는 방식으로 인해 DynamoDB는 규모에 관계없이 이러한 유형의 쿼리에 대해 일관된 성능을 제공할 수 있습니다. 반대로 Rockset은 대량의 데이터를 지속적으로 수집하고 해당 데이터에 대한 여러 인덱싱 전략을 사용하여 매우 선택적인 필터링, 실시간 또는 쿼리 시간 집계 및 DynamoDB가 쉽게 처리할 수 없는 기타 패턴을 제공하는 데 탁월합니다. 이 예를 통해 작업하면서 두 시스템의 기본 개념과 목표를 달성하기 위한 실제 단계를 모두 배우게 됩니다. 사용하여 애플리케이션을 따라갈 수 있습니다. GitHub 저장소를 DynamoDB로 핵심 기능 구현 이 연습은 애플리케이션의 핵심 기능을 구현하는 것부터 시작하겠습니다. 개별 레코드를 조작하고 관련 레코드 집합을 나열하는 기능을 제공하는 표준 "CRUDL" 작업을 구축하므로 이는 모든 애플리케이션의 일반적인 시작점입니다. 전자 상거래 애플리케이션의 경우 이는 주문을 하고 이전 주문을 보는 기능입니다. 소셜 미디어 애플리케이션의 경우 게시물 작성, 친구 추가, 팔로우하는 사람들 보기 등이 이에 해당합니다. 이 기능은 일반적으로 소수의 행에 대해 많은 동시 작업을 강조하는 워크플로를 전문으로 하는 데이터베이스에 의해 구현됩니다. OLTP(온라인 트랜잭션 처리) 이 예에서는 사용자가 결제를 하고 받을 수 있을 뿐만 아니라 거래 내역을 볼 수 있는 비즈니스 금융 애플리케이션을 구축하고 있습니다. 이 연습에서는 예제가 의도적으로 단순화되지만 애플리케이션에 대한 세 가지 핵심 액세스 패턴을 생각해 볼 수 있습니다. 기업이 지급했거나 받은 지급 기록을 저장하는 . 기록 거래 . 이를 통해 사용자는 기업에서 가장 최근에 결제하고 받은 결제 내역을 확인할 수 있습니다. 그리고 날짜 범위별로 거래를 확인합니다 사용자가 단일 거래의 세부 사항을 자세히 알아볼 수 있는 . 개별 거래를 봅니다 이러한 각 액세스 패턴은 중요한 대용량 액세스 패턴입니다. 우리는 지속적으로 사용자의 거래를 기록할 것이며 거래 피드는 사용자가 애플리케이션을 열 때 첫 번째 보기가 될 것입니다. 또한 이러한 각 액세스 패턴은 알려진 일관된 매개변수를 사용하여 관련 레코드를 가져옵니다. DynamoDB를 사용하여 이러한 액세스 패턴을 처리하겠습니다. DynamoDB는 AWS에서 제공하는 NoSQL 데이터베이스입니다. 완전 관리형 데이터베이스이며 대규모 애플리케이션과 서버리스 애플리케이션 모두에서 인기가 높아지고 있습니다. DynamoDB의 가장 독특한 기능 중 하나는 어떤 규모에서도 일관된 성능을 제공한다는 점입니다. 테이블이 1MB이든 1페타바이트이든 작업에 대한 응답 시간은 동일해야 합니다. 이는 여기서 구현하는 것과 같은 핵심 OLTP 사용 사례에 바람직한 품질입니다. 이는 위대하고 가치 있는 엔지니어링 성과이지만, 잘 수행될 쿼리 종류를 선택하여 달성했다는 점을 이해하는 것이 중요합니다. DynamoDB는 두 가지 핵심 설계 결정을 통해 일관된 성능을 제공할 수 있습니다. 먼저, DynamoDB 테이블의 각 레코드에는 기본 키가 포함되어야 합니다. 이 기본 키는 파티션 키와 선택적 정렬 키로 구성됩니다. DynamoDB에 대한 두 번째 주요 설계 결정은 API가 기본 키 사용을 강력하게 적용한다는 것입니다. 이에 대해서는 나중에 자세히 설명합니다. 아래 이미지에는 FinTech 애플리케이션에 샘플 거래 데이터가 있습니다. 우리 테이블은 애플리케이션에 있는 조직 이름의 파티션 키와 UUID의 고유성 특성을 제공하는 기반 정렬 키, 그리고 시간 기반 쿼리를 만들 수 있는 생성 시간별 정렬 기능을 사용합니다. ULID 테이블의 레코드에는 판매자 이름, 카테고리, 금액 등 애플리케이션에는 유용하지만 DynamoDB의 기본 아키텍처에는 그다지 중요하지 않은 기타 속성이 포함되어 있습니다. 중요한 부분은 기본 키, 특히 파티션 키에 있습니다. 내부적으로 DynamoDB는 데이터를 여러 스토리지 파티션으로 분할하며, 각 스토리지 파티션에는 테이블의 데이터 하위 집합이 포함되어 있습니다. DynamoDB는 기본 키의 파티션 키 요소를 사용하여 특정 레코드를 특정 스토리지 파티션에 할당합니다. 테이블의 데이터 양이나 테이블에 대한 트래픽이 증가하면 DynamoDB는 데이터베이스를 수평 확장하는 방법으로 파티션을 추가합니다. 위에서 언급한 것처럼 DynamoDB에 대한 두 번째 주요 설계 결정은 API가 기본 키 사용을 강력하게 적용한다는 것입니다. DynamoDB의 거의 모든 API 작업에는 최소한 기본 키의 파티션 키가 필요합니다. 이로 인해 DynamoDB는 파티션 수와 테이블의 전체 크기에 관계없이 모든 요청을 적절한 스토리지 파티션으로 신속하게 라우팅할 수 있습니다. 이러한 두 가지 장단점으로 인해 DynamoDB 사용 방법에는 필연적으로 제한이 따릅니다. 기본 키가 액세스 패턴에 포함되어야 하므로 액세스 패턴을 미리 신중하게 계획하고 설계해야 합니다. 나중에 액세스 패턴을 변경하는 것은 어려울 수 있으며 일부 수동 마이그레이션 단계가 필요할 수 있습니다. 사용 사례가 DynamoDB의 핵심 역량에 속하면 이점을 얻을 수 있습니다. 규모에 관계없이 일관되고 예측 가능한 성능을 얻을 수 있으며 시간이 지남에 따라 애플리케이션의 장기적인 성능 저하가 발생하지 않습니다. 또한 운영 부담이 적은 완전 관리형 환경을 얻을 수 있으므로 비즈니스에 중요한 일에 집중할 수 있습니다. 이 예의 핵심 작업은 이 모델에 완벽하게 들어맞습니다. 조직의 트랜잭션 피드를 검색할 때 애플리케이션에서 사용할 수 있는 조직 ID를 갖게 되며, 이를 통해 DynamoDB 작업을 사용하여 동일한 파티션 키를 가진 연속 레코드 세트를 가져올 수 있습니다. 특정 트랜잭션에 대한 추가 세부 정보를 검색하려면 원하는 항목을 가져오기 위한 DynamoDB 요청을 만드는 데 사용할 수 있는 조직 ID와 트랜잭션 ID가 있어야 합니다. 쿼리 GetItem 통해 이러한 작업이 실제로 실행되는 모습을 볼 수 있습니다. 지침에 따라 애플리케이션을 배포하고 샘플 데이터로 시드합니다. 그런 다음 배포된 서비스에 HTTP 요청을 수행하여 개별 사용자에 대한 트랜잭션 피드를 가져옵니다. 이러한 작업은 동시 요청 수나 DynamoDB 테이블 크기에 관계없이 빠르고 효율적인 작업입니다. 샘플 애플리케이션을 Rockset으로 DynamoDB 보완 지금까지 우리는 DynamoDB를 사용하여 핵심 액세스 패턴을 처리했습니다. DynamoDB는 키 기반 파티셔닝이 어떤 규모에서도 일관된 성능을 제공하므로 이러한 패턴에 적합합니다. 그러나 DynamoDB는 다른 액세스 패턴을 처리하는 데 능숙하지 않습니다. DynamoDB에서는 기본 키 이외의 속성으로 효율적으로 쿼리할 수 없습니다. 사용하여 추가 속성으로 데이터를 다시 인덱싱할 수 있지만 데이터를 인덱싱하는 데 사용할 수 있는 다양한 속성이 있는 경우 여전히 문제가 될 수 있습니다. DynamoDB의 보조 인덱스를 또한 DynamoDB는 기본적으로 집계 기능을 제공하지 않습니다. DynamoDB를 사용하여 자체 집계를 계산할 수 있지만 집계용으로 미리 설계한 솔루션에 비해 유연성이 떨어지거나 읽기 소비가 최적화되지 않을 수 있습니다. 이러한 패턴을 처리하기 위해 할 것입니다. DynamoDB를 Rockset으로 보완 Rockset은 데이터에 대한 보조 인덱스 세트로 생각하는 것이 가장 좋습니다. Rockset은 쿼리 시 이러한 인덱스만 사용하며 읽기 중에 DynamoDB에 로드를 다시 투영하지 않습니다. 애플리케이션 클라이언트의 개별적인 트랜잭션 업데이트 대신 Rockset은 기본 데이터 저장소에서 지속적인 스트리밍 수집을 위해 설계되었습니다. DynamoDB, MongoDB, Kafka 및 많은 관계형 데이터베이스를 포함한 다양한 기본 데이터 저장소에 대한 직접 커넥터가 있습니다. Rockset은 기본 데이터베이스에서 데이터를 수집하면서 , 역 인덱스 및 열 인덱스의 개념을 차용한 수렴형 인덱스로 데이터를 인덱싱합니다. 범위, 유형, 지리정보 등의 추가 인덱스는 수집된 데이터 유형을 기반으로 자동으로 생성됩니다. 아래에서 이러한 인덱스의 구체적인 내용을 논의하겠지만 이 Converged Index를 사용하면 데이터에 대한 보다 유연한 액세스 패턴을 사용할 수 있습니다. 행 인덱스 이것이 Rockset의 핵심 개념입니다. 이는 기본 데이터 저장소에서 완전 관리형, 실시간에 가까운 수집 파이프라인을 사용하여 데이터에 대한 보조 인덱스입니다. 팀에서는 추가 사용 사례를 처리하기 위해 오랫동안 DynamoDB에서 데이터를 추출하여 다른 시스템에 삽입해 왔습니다. Rockset이 테이블에서 데이터를 수집하는 방법에 대해 자세히 설명하기 전에 Rockset이 이 공간의 다른 옵션과 어떻게 다른지 간략하게 논의하겠습니다. Rockset과 다른 접근 방식 사이에는 몇 가지 핵심적인 차이점이 있습니다. 첫째, Rockset은 완전 관리형입니다. 데이터베이스 인프라를 관리할 필요가 없을 뿐만 아니라 Rockset에 데이터를 추출, 변환 및 로드하기 위한 파이프라인을 유지할 필요도 없습니다. 다른 많은 솔루션에서는 시스템 간의 "접착" 코드를 담당합니다. 데이터 구조의 변경 사항에 대해 방어적으로 보호해야 하므로 이러한 시스템은 중요하지만 오류가 발생하기 쉽습니다. 업스트림 변경은 이러한 시스템을 유지 관리하는 사람들에게 다운스트림 문제를 초래할 수 있습니다. 둘째, Rockset은 변경 가능한 방식으로 실시간 데이터를 처리할 수 있습니다. 다른 많은 시스템을 사용하면 둘 중 하나를 얻을 수 있습니다. 정기적으로 데이터 내보내기 및 대량 로드를 수행하도록 선택할 수 있지만 이로 인해 로드 간에 데이터가 부실해지게 됩니다. 또는 추가 전용 방식으로 데이터를 데이터 웨어하우스로 스트리밍할 수 있지만 데이터 변경 시 내부 업데이트를 수행할 수는 없습니다. Rockset은 새 데이터를 삽입하는 것처럼 기존 항목에 대한 업데이트를 빠르고 효율적으로 처리할 수 있으므로 변화하는 데이터를 실시간으로 볼 수 있습니다. 셋째, Rockset은 인덱스를 자동으로 생성합니다. 다른 '완전 관리형' 솔루션에서는 여전히 새 쿼리를 지원하는 데 필요한 인덱스를 구성해야 합니다. Rockset의 쿼리 엔진은 하나의 인덱스 세트를 사용하여 모든 쿼리를 지원하도록 설계되었습니다. 시스템에 점점 더 많은 쿼리를 추가하면 추가 인덱스를 추가할 필요가 없어 점점 더 많은 공간과 계산 리소스를 차지하게 됩니다. 이는 또한 임시 쿼리가 인덱스를 완벽하게 활용하여 관리자가 이를 지원하기 위해 맞춤형 인덱스를 추가할 때까지 기다리지 않고도 인덱스를 빠르게 만들 수 있음을 의미합니다. Rockset이 DynamoDB에서 데이터를 수집하는 방법 이제 Rockset이 무엇인지, 이것이 어떻게 도움이 되는지에 대한 기본 사항을 알았으므로 DynamoDB 테이블을 Rockset에 연결해 보겠습니다. 이를 통해 Rockset 수집 프로세스의 작동 방식과 다른 옵션과의 차이점을 알아봅니다. Rockset에는 다양한 데이터 소스를 위해 특별히 제작된 커넥터가 있으며 특정 커넥터 구현은 업스트림 데이터 소스의 세부 사항에 따라 다릅니다. DynamoDB와 연결하기 위해 Rockset은 사용합니다. DynamoDB 스트림은 DynamoDB 테이블에 대한 각 쓰기 작업의 세부 정보가 스트림에 기록되는 DynamoDB의 변경 데이터 캡처 기능입니다. 스트림 소비자는 다운스트림 시스템을 업데이트하기 위해 테이블에 발생한 것과 동일한 순서로 이러한 변경 사항을 처리할 수 있습니다. DynamoDB Streams를 DynamoDB 스트림은 Rockset이 거의 실시간으로 DynamoDB 테이블을 최신 상태로 유지하는 데 유용하지만 이것이 전부는 아닙니다. DynamoDB 스트림에는 테이블에서 스트림이 활성화된 후에 발생한 쓰기 작업의 기록만 포함됩니다. 또한 . 스트림이 활성화되기 전이나 24시간 이상 전에 발생한 작업은 스트림에 표시되지 않습니다. DynamoDB 스트림은 24시간 동안만 레코드를 유지합니다 그러나 Rockset은 귀하의 쿼리에 올바르게 응답하기 위해 최신 데이터뿐만 아니라 데이터베이스의 모든 데이터가 필요합니다. 이를 처리하기 위해 초기 대량 내보내기(테이블 크기에 따라 DynamoDB 스캔 또는 사용)를 수행하여 테이블의 초기 상태를 가져옵니다. S3로 내보내기 따라서 Rockset의 DynamoDB 연결 프로세스는 두 부분으로 구성됩니다. Rockset으로 수집하기 위해 전체 테이블을 내보내는 초기 프로세스입니다. 부트스트래핑 DynamoDB Stream의 업데이트를 사용하고 Rockset의 데이터를 업데이트하는 후속 프로세스입니다. 적이고 지속적인 이 두 프로세스는 모두 Rockset에 의해 완전히 관리되며 사용자에게 투명합니다. 이러한 파이프라인을 유지 관리하고 오류가 있는 경우 경고에 응답하는 일은 귀하가 담당하지 않습니다. 또한 초기 수집 프로세스에 대해 S3 내보내기 방법을 선택하면 Rockset 수집 프로세스 중 어느 것도 기본 테이블의 읽기 용량 단위를 소비하지 않습니다. 따라서 Rockset은 애플리케이션 사용 사례에서 소비를 취하거나 생산 가용성에 영향을 미치지 않습니다. 애플리케이션: DynamoDB를 Rockset에 연결 애플리케이션에서 Rockset을 사용하기 전에 Rockset을 DynamoDB 테이블에 연결해 보겠습니다. 먼저 Rockset과 테이블 사이에 새로운 통합을 생성해야 합니다. 아래에서 대략적인 단계를 살펴보겠습니다. 필요한 경우 찾을 수 있습니다. 애플리케이션 저장소에서 더 자세한 단계별 지침을 Rockset 콘솔에서 로 이동하여 이 프로세스를 시작하세요. 새로운 통합 마법사 통합 마법사에서 통합 유형으로 선택합니다. 그런 다음 클릭하여 다음 단계로 이동합니다. Amazon DynamoDB를 시작을 DynamoDB 통합 마법사에는 Rockset이 DynamoDB 테이블에 액세스할 수 있도록 권한을 부여하는 단계별 지침이 있습니다. 이를 위해서는 테이블 내보내기를 위한 IAM 정책, IAM 역할 및 S3 버킷을 생성해야 합니다. 원하는 경우 해당 지침에 따라 리소스를 수동으로 생성할 수 있습니다. 서버리스 세계에서 우리는 가능한 한 통해 사물을 생성하는 것을 선호하며 여기에는 이러한 지원 리소스가 포함됩니다. 코드형 인프라를 예제 저장소에는 Rockset 통합 리소스를 생성하는 데 필요한 코드형 인프라가 포함되어 있습니다. 이를 사용하려면 먼저 Rockset 통합 마법사 하단에서 Rockset 계정 ID와 외부 ID 값을 찾으세요. 이러한 값을 복사하여 serverless.yml 파일의 블록 에 붙여넣습니다. 그런 다음 이러한 리소스를 생성합니다. custom 관련 섹션 serverless.yml의 71~122행에서 리소스의 주석 처리를 제거하여 이러한 새 리소스를 생성하려면 애플리케이션을 다시 배포하세요. 배포 출력에서 S3 버킷 이름과 IAM 역할 ARN을 복사하여 Rockset 콘솔의 적절한 위치에 붙여넣습니다. 그런 다음 통합 저장 버튼을 클릭하여 통합을 저장합니다. 통합을 생성한 후에는 통합에서 생성해야 합니다. Rockset 콘솔에서 로 이동하고 통합을 사용하여 컬렉션을 생성하는 단계를 따르십시오. 애플리케이션 저장소에서 찾을 수도 있습니다. Rockset 컬렉션을 컬렉션 생성 마법사 컬렉션을 생성하기 위한 단계별 지침을 이 연결을 완료하면 일반적으로 적절한 크기의 인스턴스 세트에서 DynamoDB의 데이터에 대한 삽입, 업데이트 또는 삭제가 Rockset의 인덱스에 반영되고 2초 이내에 쿼리가 가능해집니다. 복잡한 필터링에 Rockset 사용 이제 Rockset을 DynamoDB 테이블에 연결했으므로 Rockset이 기존 데이터에 대해 어떻게 새로운 액세스 패턴을 활성화할 수 있는지 살펴보겠습니다. DynamoDB는 기본 키에 중점을 두고 있다는 핵심 기능 섹션을 상기해 보세요. 데이터에 효율적으로 액세스하려면 기본 키를 사용해야 합니다. 따라서 우리는 기본 키에 조직 이름과 거래 시간을 사용하도록 테이블을 구성했습니다. 이 구조는 우리의 핵심 액세스 패턴에 적합하지만 사용자가 거래를 탐색할 수 있는 보다 유연한 방법을 제공하고 싶을 수도 있습니다. 필터링에 유용할 수 있는 유용한 속성(카테고리, 판매자 이름, 금액 등)이 많이 있습니다. DynamoDB의 보조 인덱스를 사용하여 더 많은 속성에 대한 필터링을 활성화할 수 있지만 여전히 여기에는 적합하지 않습니다. DynamoDB의 기본 키 구조는 많은 선택적 속성의 조합을 포함하는 유연한 쿼리를 쉽게 허용하지 않습니다. 판매자 이름과 날짜별로 필터링하기 위한 보조 인덱스가 있을 수 있지만 판매자 이름, 날짜 및 금액별로 필터링하려면 다른 보조 인덱스가 필요합니다. 카테고리를 필터링하는 액세스 패턴에는 세 번째 보조 인덱스가 필요합니다. 이러한 복잡성을 처리하는 대신 여기서는 Rockset을 사용하겠습니다. 이전에 Rockset이 Converged Index를 사용하여 여러 방법으로 데이터를 색인화하는 것을 보았습니다. 그 방법 중 하나가 반전된 인덱스입니다. 역인덱스를 사용하면 Rockset은 각 속성을 직접 인덱싱합니다. 이 인덱스가 어떻게 구성되어 있는지 확인하세요. 각 속성 이름과 값은 인덱스의 키로 사용되며, 값은 해당 속성 이름과 값을 포함하는 문서 ID 목록입니다. 키는 자연스러운 정렬 순서가 범위 쿼리를 효율적으로 지원할 수 있도록 구성됩니다. 반전된 인덱스는 선택적 필터 조건이 있는 쿼리에 적합합니다. 사용자가 거래를 필터링하여 특정 기준과 일치하는 거래를 찾을 수 있도록 하고 싶다고 상상해 보세요. Vandelay Industries 조직의 누군가가 최근 Chipotle을 몇 번이나 주문했는지에 관심이 있습니다. 다음과 같은 쿼리를 통해 이를 찾을 수 있습니다. SELECT * FROM transactions WHERE organization = 'Vandelay Industries' AND merchant_name = 'Chipotle' 고객 및 판매자 이름에 대해 선택적 필터를 수행하고 있으므로 반전된 색인을 사용하여 일치하는 문서를 빠르게 찾을 수 있습니다. Rockset은 반전된 인덱스에서 속성 이름과 값 쌍을 모두 조회하여 일치하는 문서 목록을 찾습니다. 이 두 목록이 있으면 이를 병합하여 두 조건 집합 모두와 일치하는 레코드 집합을 찾고 결과를 클라이언트에 다시 반환할 수 있습니다. DynamoDB의 파티션 기반 인덱싱이 파티션 키를 사용하는 작업에 효율적인 것처럼 Rockset의 반전 인덱스는 데이터 세트의 모든 필드, 심지어 내장된 객체의 속성이나 내장된 배열 내부의 값에서도 효율적인 조회를 제공합니다. 애플리케이션: 애플리케이션에서 Rockset API 사용 이제 Rockset이 데이터 세트에 대해 선택적 쿼리를 효율적으로 실행할 수 있는 방법을 알았으므로 Rockset 쿼리를 애플리케이션에 통합하는 실제적인 측면을 살펴보겠습니다. Rockset은 인증 토큰으로 보호되는 RESTful 서비스를 공개합니다. SDK는 널리 사용되는 프로그래밍 언어에도 사용할 수 있습니다. 이는 데이터베이스에 액세스하기 위해 복잡한 개인 네트워킹 구성을 설정할 필요가 없기 때문에 서버리스 애플리케이션과 통합하는 데 매우 적합합니다. 애플리케이션에서 Rockset API와 상호 작용하려면 Rockset API 키가 필요합니다. Rockset 콘솔의 에서 생성할 수 있습니다. 그런 다음 해당 값을 serverless.yml 파일에 복사하고 다시 배포하여 애플리케이션에서 사용할 수 있도록 하세요. API 키 섹션 참고 사항: 단순화를 위해 이 API 키를 환경 변수로 사용하고 있습니다. 실제 애플리케이션에서는 또는 와 같은 것을 사용하여 비밀을 저장하고 환경 변수를 방지해야 합니다. Parameter Store AWS Secrets Manager Rockset API와 상호 작용하는 방법을 보려면 살펴보세요. 클래스 초기화는 Rockset을 호출하는 데 사용되는 Rockset 클라이언트 개체를 사용합니다. TransactionService 클래스를 에는 Rockset과 상호작용하기 위한 다음 쿼리가 있습니다. 서비스 클래스의 filterTransactions 메소드 const response = await this._rocksetClient.queries.query({ sql: { query: ` SELECT * FROM Transactions WHERE organization = :organization AND category = :category AND amount BETWEEN :minAmount AND :maxAmount ORDER BY transactionTime DESC LIMIT 20`, parameters: [ { name: "organization", type: "string", value: organization, }, { name: "category", type: "string", value: category, }, { name: "minAmount", type: "float", value: minAmount, }, { name: "maxAmount", type: "float", value: maxAmount, }, ], }, }); 이 상호 작용에 대해 주목해야 할 두 가지 사항이 있습니다. 첫째, 사용자의 입력을 처리할 때 쿼리에 명명된 매개 변수를 사용합니다. 이는 SQL 삽입 공격을 방지하기 위한 SQL 데이터베이스의 일반적인 관행입니다. 둘째, SQL 코드는 애플리케이션 코드와 혼합되어 시간이 지남에 따라 추적하기 어려울 수 있습니다. 이것이 효과가 있을 수 있지만 더 좋은 방법이 있습니다. 다음 사용 사례를 적용하면서 애플리케이션에서 Rockset 쿼리 Lambda를 사용하는 방법을 살펴보겠습니다. 집계를 위해 Rockset 사용 지금까지 데이터베이스가 특정 필터 조건자와 일치하는 개별 레코드 또는 레코드 집합을 찾는 방법을 논의하면서 DynamoDB 및 Rockset의 인덱싱 전략을 검토했습니다. 예를 들어, DynamoDB는 레코드를 찾기 위해 기본 키를 사용하도록 유도하는 반면 Rockset의 반전 인덱스는 매우 선택적인 필터 조건을 사용하여 효율적으로 레코드를 찾을 수 있다는 것을 확인했습니다. 이 마지막 섹션에서는 직접 인덱싱보다는 데이터 레이아웃에 초점을 맞추기 위해 기어를 약간 전환하겠습니다. 데이터 레이아웃에 대해 생각할 때 행 기반과 열 기반이라는 두 가지 접근 방식을 대조해 보겠습니다. 행 기반 데이터베이스는 이름에서 알 수 있듯이 디스크의 데이터를 행으로 정렬합니다. PostgreSQL 및 MySQL과 같은 대부분의 관계형 데이터베이스는 행 기반 데이터베이스입니다. DynamoDB와 같은 많은 NoSQL 데이터베이스도 마찬가지입니다. 레코드가 관계형 데이터베이스 의미에서 기술적으로 "행"이 아니더라도 마찬가지입니다. 행 기반 데이터베이스는 지금까지 살펴본 액세스 패턴에 적합합니다. ID로 개별 트랜잭션을 가져오거나 일부 필터 조건에 따라 트랜잭션 집합을 가져올 때 일반적으로 각 트랜잭션에 대해 모든 필드가 다시 표시되기를 원합니다. 레코드의 모든 필드가 함께 저장되기 때문에 일반적으로 레코드를 반환하려면 단일 읽기가 필요합니다. (참고: 이에 대한 약간의 뉘앙스가 나옵니다). 집계는 완전히 다른 이야기입니다. 집계 쿼리를 사용하여 모든 거래 수, 거래 총액 합계 또는 일련의 거래에 대한 월별 평균 지출 등 집계를 계산하려고 합니다. Vandelay Industries 조직의 사용자에게 돌아가서, 지난 3개월을 보고 매월 범주별로 총 지출을 찾고 싶다고 가정해 보겠습니다. 해당 쿼리의 단순화된 버전은 다음과 같습니다. SELECT category, EXTRACT(month FROM transactionTime) AS month, sum(amount) AS amount FROM transactions WHERE organization = 'Vandelay Industries' AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month ORDER BY category, month DESC 이 쿼리의 경우 결과를 계산하기 위해 읽어야 하는 레코드 수가 많을 수 있습니다. 그러나 각 레코드에 대해 많은 필드가 필요하지는 않습니다. 이 결과를 결정하려면 카테고리, transactionTime, 조직 및 금액이라는 네 가지만 필요합니다. 따라서 이 쿼리를 충족하려면 더 많은 레코드를 읽어야 할 뿐만 아니라 행 기반 레이아웃도 결과에 불필요한 여러 필드를 읽습니다. 반대로 열 기반 레이아웃은 디스크의 데이터를 열에 저장합니다. Rockset의 Converged Index는 열 기반 레이아웃에 데이터를 저장하기 위해 열 형식 인덱스를 사용합니다. 열 기반 레이아웃에서는 데이터가 열별로 함께 저장됩니다. 개별 레코드는 색인화를 위해 구성 열로 분할됩니다. 내 쿼리가 많은 수의 레코드에 대한 "금액" 속성을 합산하기 위해 집계를 수행해야 하는 경우 Rockset은 열 형식 인덱스의 "금액" 부분을 스캔하여 이를 수행할 수 있습니다. 이는 행 기반 레이아웃에 비해 읽고 처리되는 데이터의 양을 크게 줄입니다. 기본적으로 Rockset의 열 형식 인덱스는 열 내의 속성을 정렬하지 않습니다. 특정 고객의 데이터에 대해 작동하는 사용자 지향 사용 사례가 있기 때문에 열 형식 인덱스를 사용하는 동안 검색할 데이터 양을 줄이기 위해 고객별로 열 형식 인덱스를 구성하는 것을 선호합니다. Rockset은 이를 돕기 위해 제공합니다. 클러스터링을 사용하면 "조직" 속성을 기준으로 열 형식 인덱스를 클러스터링할 수 있음을 나타낼 수 있습니다. 이렇게 하면 열 형식 인덱스 내의 조직별로 모든 열 값이 그룹화됩니다. 따라서 Vandlay Industries가 데이터 집계를 수행할 때 Rockset의 쿼리 프로세서는 다른 고객을 위해 열 형식 인덱스 부분을 건너뛸 수 있습니다. 열형 인덱스에 대한 데이터 클러스터링을 Rockset의 행 기반 인덱스가 처리를 돕는 방법 애플리케이션에서 컬럼형 인덱스를 사용하기 전에 Rockset Converged Index의 또 다른 측면에 대해 이야기하고 싶습니다. 앞서 전체 레코드를 검색할 때 행 기반 레이아웃이 사용되었다고 언급했으며 DynamoDB와 Rockset 반전 인덱스 쿼리 모두 이러한 레이아웃을 사용하고 있음을 표시했습니다. 그것은 부분적으로만 사실입니다. 반전된 인덱스는 모든 속성에 의한 효율적인 조회를 위해 열 이름과 값을 함께 저장한다는 점에서 열 기반 인덱스와 일부 유사합니다. 각 인덱스 항목에는 지정된 열 이름과 값 조합을 포함하는 레코드의 ID에 대한 포인터가 포함되어 있습니다. 역인덱스에서 해당 ID가 발견되면 Rockset은 행 인덱스를 사용하여 전체 레코드를 검색할 수 있습니다. Rockset은 사전 인코딩 및 기타 고급 압축 기술을 사용하여 데이터 저장 크기를 최소화합니다. 따라서 이제 Rockset의 Converged Index가 어떻게 서로 어울리는지 살펴보았습니다. 집계를 위해 특정 열에 있는 많은 수의 값을 빠르게 검색하는 데 사용됩니다. 열 기반 인덱스는 모든 열 이름 및 값에 대한 선택적 필터에 사용됩니다. 반전된 인덱스는 프로젝션 절에서 참조될 수 있는 추가 속성을 가져오는 데 사용됩니다. 행 기반 인덱스는 내부적으로 Rockset의 강력한 인덱싱 및 쿼리 엔진은 데이터에 대한 통계를 추적하고 쿼리를 효율적으로 실행하기 위한 최적의 계획을 생성합니다. 애플리케이션: 애플리케이션에서 Rockset 쿼리 Lambda 사용 열형 인덱스를 사용하는 Rockset 집계 쿼리를 구현해 보겠습니다. 이전 쿼리의 경우 SQL 쿼리를 Rockset API에 직접 작성했습니다. 이는 고도로 사용자 정의 가능한 일부 사용자 인터페이스에서 수행하는 올바른 작업이지만 SQL 코드가 보다 정적인 경우 더 나은 옵션이 있습니다. 우리는 애플리케이션 로직 중간에 지저분한 SQL 코드를 유지하는 것을 피하고 싶습니다. 이를 돕기 위해 Rockset에는 Query Lambdas라는 기능이 있습니다. 쿼리 Lambda는 Rockset 콘솔에 등록된 이름이 지정되고 버전이 지정되며 매개변수화된 쿼리입니다. Rockset에서 Query Lambda를 구성한 후에는 Rockset에서 실행할 매개 변수를 사용하여 호출할 수 있는 Query Lambda에 대해 완전히 관리되고 확장 가능한 엔드포인트를 받게 됩니다. 또한 각 쿼리 Lambda에 대한 모니터링 통계도 얻을 수 있으므로 변경 사항을 적용할 때 쿼리 Lambda가 어떻게 수행되고 있는지 추적할 수 있습니다. 수 있지만, 집계 쿼리를 처리하기 위해 첫 번째 쿼리 Lambda를 설정해 보겠습니다. . 여기에서 쿼리 Lambda에 대해 자세히 알아볼 전체 연습은 애플리케이션 저장소에서 찾을 수 있습니다 Rockset 콘솔의 으로 이동합니다. 다음 쿼리를 편집기에 붙여넣습니다. 쿼리 편집기 섹션 SELECT category, EXTRACT( month FROM transactionTime ) as month, EXTRACT( year FROM transactionTime ) as year, TRUNCATE(sum(amount), 2) AS amount FROM Transactions WHERE organization = :organization AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month, year ORDER BY category, month, year DESC 이 쿼리는 특정 조직의 지난 3개월 동안의 거래를 특정 카테고리와 거래 월을 기준으로 버킷으로 그룹화합니다. 그런 다음 월별로 카테고리 값을 합산하여 매월 지출된 총 금액을 찾습니다. 쿼리의 ":organization" 구문에 표시된 대로 "organization" 속성에 대한 매개변수가 포함되어 있습니다. 이는 쿼리를 실행하려면 조직 값을 전달해야 함을 나타냅니다. Rockset 콘솔에 쿼리를 Query Lambda로 저장합니다. 그런 다음 살펴보세요. 이름으로 Query Lambda를 호출하고 사용자가 제공한 "조직" 속성을 전달합니다. TransactionService 클래스의 fetchTransactionsByCategoryAndMonth 코드를 이는 우리 애플리케이션에서 처리하기에는 훨씬 간단한 코드입니다. 또한 Rockset은 각 쿼리 Lambda에 대한 버전 제어 및 쿼리별 모니터링을 제공합니다. 이렇게 하면 시간이 지남에 따라 쿼리를 더 쉽게 유지 관리하고 쿼리 구문 변경이 성능에 어떤 영향을 미치는지 이해할 수 있습니다. 결론 이 게시물에서는 DynamoDB와 Rockset을 함께 사용하여 사용자를 위한 빠르고 즐거운 애플리케이션 환경을 구축하는 방법을 살펴보았습니다. 이를 통해 우리는 애플리케이션을 구현하기 위한 개념적 기초와 실제 단계를 모두 배웠습니다. 먼저, DynamoDB를 사용하여 애플리케이션의 핵심 기능을 처리했습니다. 여기에는 특정 고객에 대한 거래 피드 검색 또는 개별 거래 보기와 같은 액세스 패턴이 포함됩니다. DynamoDB의 기본 키 기반 분할 전략 덕분에 어떤 규모에서도 일관된 성능을 제공할 수 있습니다. 그러나 DynamoDB의 설계로 인해 유연성도 제한됩니다. 다수의 레코드에 걸쳐 임의 필드 또는 집계에 대한 선택적 쿼리를 처리할 수 없습니다. 이러한 패턴을 처리하기 위해 Rockset을 사용했습니다. Rockset은 데이터 집약적인 애플리케이션을 지원하기 위해 완벽하게 관리되는 보조 인덱스를 제공합니다. 우리는 Rockset이 역방향, 열형 및 행 인덱싱을 결합한 Converged Index에서 데이터를 인덱싱하는 기본 데이터 저장소에서 지속적인 수집 파이프라인을 유지하는 방법을 살펴보았습니다. 패턴을 살펴보면서 Rockset의 각 인덱싱 기술이 어떻게 함께 작동하여 즐거운 사용자 경험을 처리하는지 확인했습니다. 마지막으로 Rockset을 DynamoDB 테이블에 연결하고 애플리케이션에서 Rockset과 상호 작용하는 실제 단계를 거쳤습니다. 나타납니다. 여기에도
