How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. 속도는 중요합니다 for Coralogix는 실시간 스트리밍 분석 파이프라인을 사용하여 모니터링, 시각화 및 경고 기능을 제공하며 인덱싱을 필요로하지 않고도 경고 기능을 제공합니다. 컬러리스트 Coralogix의 주요 차이점 중 하나는 원격 저장소에 있는 고객의 아카이브에서 매핑된 데이터에 대한 빠른 쿼리를 위한 분산된 쿼리 엔진입니다.This engine queries semi-structured data stored in object storage (e.g., GCS, S3) using a specialized 그것은 원래 기본 객체 저장소 위에 상태가없는 쿼리 엔진으로 설계되었지만 쿼리 실행 중에 Parquet 메타데이터를 읽는 것은 용납할 수없는 지연 타격을 도입했습니다.To overcome this, they developed a metadata store (simply called "metastore") to enable faster retrieval and processing of the Parquet metadata needed to execute large queries. 주차장 PostgreSQL을 기반으로 한 원래 메타스토어 구현은 그들의 요구에 충분히 빠르지 않았습니다. 그래서 팀은 이번에 PostgreSQL 대신 ScyllaDB를 사용하여 새로운 구현을 시도했습니다. 스포일러 : 효과가있었습니다. 그들은 인상적인 성능 향상을 달성했습니다. 쿼리 처리 시간을 30초에서 86 밀리초로 줄였습니다. 그들의 엔지니어들 인 Dan Harris (최고 소프트웨어 엔지니어)와 Sebastian Vercruysse (최고 소프트웨어 엔지니어)는 ScyllaDB Summit에서 그들이 어떻게 했는지 설명했습니다. ScyllaDB Summit 24에서 팀이 가장 어려운 데이터베이스 도전에 어떻게 대처하고 있는지에 대한 더 많은 직접적인 보고서를 들으십시오.Disney, Discord, Expedia, Supercell, Paramount 등 모두 의제에 있습니다. ScyllaDB Summit 2024는 이제 포장되었습니다! Update: Metastore 동기 및 요구 사항 메타스토어 구현 세부 사항에 들어가기 전에 한 걸음 뒤로 가서 메타스토어를 구축하는 이유를 먼저 살펴보자. "우리는 처음에 이 플랫폼을 기본 객체 저장소 위에 상태가없는 쿼리 엔진으로 설계했지만, 쿼리 실행 중에 Parquet 메타데이터를 읽는 비용이 쿼리 시간의 큰 비율임을 깨달았습니다."라고 Dan Harris는 설명했습니다. 그들은 다음을 할 수있는 해결책을 생각했습니다 : Parquet 메타데이터를 분해된 형식으로 저장하여 높은 확장성과 전달량을 위해 bloom 필터를 사용하여 각 쿼리를 스캔하기 위해 파일을 효율적으로 식별하십시오. 트랜잭션 커미트 로그를 사용하여 기본 객체 저장소의 기존 데이터를 트랜잭션적으로 추가, 업데이트 및 대체합니다.Use transactional commit logs to transactionally add, update, and replace existing data in the underlying object storage. 주요 요구 사항은 낮은 지연 시간, 읽기 / 쓰기 용량의 측면에서 확장성 및 기본 저장소의 확장성을 포함했습니다.And to understand the extreme scalability required, consider this: 시간당 2,000개의 Parquet 파일(일당 50,000개)을 생성하며, 하루에 총 15TB를 생성하여 Parquet 메타데이터만 20GB를 생성합니다. . 단일 고객 단 하루만을 위한 단일 고객 단 하루만을 위한 초기 PostgreSQL 구현 "우리는 Postgres에서 초기 구현을 시작했으며, 그 당시에는 분산되지 않은 엔진이 장기적으로 충분하지 않을 것이라는 것을 이해했습니다."Dan는 인정했습니다.이 원래 구현은 "블록"과 같은 핵심 정보를 저장했으며, 하나의 행 그룹과 하나의 파케이트 파일을 나타냅니다.이 파일의 URL, 행 그룹 인덱스 및 파일에 대한 최소한의 세부 사항과 같은 메타데이터를 포함합니다. Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … 읽기를 최적화하기 위해, 그들은 효율적인 데이터 절단을 위해 bloom 필터를 사용했습니다. Dan은 자세히 설명했습니다. “최종적으로, 우리는 전체 텍스트 검색과 같은 것을 지원하고 싶습니다. 기본적으로, 우리가 시스템에 이러한 파일을 흡수 할 때, 우리는 파일에서 발견하는 모든 독특한 토큰에 대한 bloom 필터를 구축 할 수 있습니다. 그런 다음 특정 쿼리를 기반으로, 우리는 스캔해야 할 데이터를 절단하기 위해 그 bloom 필터를 사용할 수 있습니다.”그들은 bloom 필터를 블록 분할 설정에 저장하여 효율적인 검색을 위해 32 바이트 블록으로 분해했습니다. 또한, 그들은 각 Parquet 파일에 대한 열 메타데이터를 저장했습니다.For example: Block URL Row Group Column Name Column metadata (blob) 댄은 “우리가 쓰고 있는 파일은 꽤 넓고, 때로는 20,000개의 열까지 많습니다. 그래서 필요한 메타데이터만 읽으면 어떤 쿼리에 필요한 IO를 줄일 수 있습니다.”라고 설명했다. ScyllaDB 구현 다음으로, Dan의 팀 동료 인 Sebastian Vercruysse가 설명한 ScyllaDB 구현을 살펴보자. 블록 데이터 모델링 새로운 구현을 위해 블록 모델링을 재검토해야 했습니다.Here is an example of a block URL: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet 대담한 부분은 고객의 상위 수준의 상자입니다; 상자 내부에서 항목은 시간에 따라 분할됩니다.이 경우, 무엇을 기본 키로 사용해야합니까? 그러나 일부 고객은 다른 고객보다 많은 Parquet 파일을 보유하고 있었고, 균형을 유지하고 싶었습니다. ((블록 url, 행 그룹))?이 특정 블록을 고유하게 식별하지만 타임스탬프가 키에 있지 않기 때문에 특정 날짜에 대한 모든 블록을 나열하는 것은 어렵습니다. (( 테이블 url, 시간))?그것은 당신이 쿼리를 할 24 시간이 있기 때문에 작동합니다, 당신은 꽤 쉽게 쿼리를 할 수 있습니다. (( 테이블 url, 시간), 블록 url, 행 그룹)?그것이 그들이 선택한 것입니다.블록 url 및 행 그룹을 클러스터링 키로 추가함으로써, 그들은 한 시간 이내에 특정 블록을 쉽게 검색 할 수 있으며, 이는 블록과 행 그룹을 업데이트하거나 삭제하는 과정을 단순화합니다. Bloom Filter Chunking 및 데이터 모델링 다음 도전: 특정 비트가 설정되었는지 확인하는 방법, ScyllaDB가 그 기능을 제공하지 않기 때문에. 팀은 bloom 필터를 읽고 응용 프로그램에서 처리하기로 결정했습니다. 그러나 고객 당 하루에 최대 50,000 블록을 다루고 있으며, 각 블록에는 bloom 필터 부분을위한 262KB가 포함되어 있습니다. 이는 총 12GB입니다. - 하나의 쿼리에 대한 응용 프로그램에 다시 끌어 올리기에는 너무 많습니다. 그러나 그들은 매번 전체 bloom 필터를 읽을 필요가 없었습니다. 그들은 쿼리를 실행하는 동안 관련된 토큰에 따라 그것의 일부만 필요했습니다. 데이터 모델링을 위해, 하나의 옵션은 사용하는 것이었다. 그것은 꽃 필터 당 32 바이트의 8192 조각을 생성하여 파티션 당 약 262 KB의 균일한 배포를 생성합니다. 같은 파티션의 각 꽃 필터를 사용하면 단일 배치 쿼리로 데이터를 삽입하고 삭제하는 것이 쉽습니다. 그러나 읽기 효율성에 영향을 미치는 잡기가 있습니다 : 꽃 필터를 읽을 수 있기 전에 블록의 ID를 알아야합니다. 또한 접근 방식은 상당한 수의 파티션에 액세스하는 것을 포함합니다. 50K 블록은 50K 파티션을 의미합니다. 세바스티안이 지적했듯이 "ScyllaDB와 같은 빠른 무언가와 함께도 50K 파티션에 대한 서브초 프로세스를 달성하는 것은 여전히 어렵습니다." (block_url, row_group, chunk index 등) 또 다른 옵션 (마침내 그들이 결정한 옵션): 이것은 블록과 동일한 파티션 키이며, 쿼리 엔진이 요구하는 nth 토큰을 나타내는 파티션 키에 인덱스를 추가합니다.This approach, scanning 5 tokens spanning a 24 hour window results in 120 partitions – an impressive improvement compared to the previous data modeling option. ((table url, hour, chunk index), 블록 url, 행 그룹) 또한,이 접근 방식은 더 이상 bloom 필터를 읽기 전에 블록 ID를 필요로하지 않습니다 - 더 빠른 읽기를 허용합니다. 물론, 항상 거래가 있습니다. 여기서, 차단 된 bloom 필터 접근 방식으로 인해, 그들은 단일 bloom 필터를 8192 개의 고유 파티션으로 나누어야합니다. 이것은 이전 파티션 접근 방식에 비해 섭취 속도를 영향을 미치므로 모든 bloom 필터 조각을 한 번에 섭취 할 수 있습니다.그러나 한 시간 이내에 주어진 블록을 신속하게 읽을 수있는 능력은 빠른 쓰기보다 그들에게 더 중요합니다. 데이터 모델링 Woes 예를 들어, 세바스티안은 "어느 날, 나는 우리가 min 및 max 타임스탬프를 혼란스럽게했다는 것을 알았고, 나는 그것을 어떻게 고칠 것인지 궁금해했다.나는 아마도 열을 다시 이름을 바꾸고 어떻게든 다시 작동 할 수 있다고 생각했지만, 여기서 클러스터 키의 일부라면 열을 다시 이름을 바꿀 수는 없습니다.나는 확실히 새로운 열을 추가하고 모든 행을 업데이트하기 위해 UPDATE 쿼리를 실행할 수 있다고 생각했습니다. 궁극적으로, 그들은 테이블을 절단하고 다시 시작 vs 마이그레이션 코드를 작성하기로 결정했다. 성능 이득 필요한 데이터 모델링 작업에도 불구하고, 마이그레이션은 좋은 비용을 지불.For the metastore block listing: 각 노드는 현재 4-5TB를 처리합니다. 그들은 현재 초당 약 10K 글자를 처리하고 있으며 P99 지연 시간은 일관되게 1 밀리초 이하입니다. 블록 목록은 1 시간에 약 2000 개의 파켓 파일을 생성합니다; 그들의 꽃 필터로, 그들은 20 밀리 초 미만에 처리됩니다. 50K 파일의 경우, 그것은 500 밀리 초 미만입니다. 그러나 50K Parquet 파일의 경우 500 밀리 초가 그들의 요구에 맞는 것이 좋습니다. 열 메타데이터 처리에서 P50은 꽤 좋지만, 높은 꼬리 지연률이 있습니다. 세바스티안은 설명했다: “문제는 우리가 50K 파케트 파일을 가지고 있다면, 우리의 실행자는 이들 모두를 동시에 수집하고 있다는 것입니다.그것은 우리가 동시에 많은 쿼리를 가지고 있고 우리는 최고의 디스크를 사용하지 않는다는 것을 의미합니다. ScyllaDB 설치 특히, Coralogix는 ScyllaDB를 처음 발견한 것에서 2개월 만에 테라바이트의 데이터를 생산하는 데로 갔습니다 (그리고 이것은 데이터 모델링 작업을 필요로하는 SQL에서 NoSQL로의 마이그레이션이었으며, 훨씬 더 간단한 Cassandra 또는 DynamoDB 마이그레이션이 아닙니다). 이 실행은 Rust 위에서 작성되었습니다. 그리고 그들은 발견 , 그리고 Coralogix에게 저렴한 관찰성 대안을 제공하는 것이 중요하기 때문에 Coralogix 팀은 ScyllaDB 인프라의 유리한 가격 성능에 만족했습니다. ScyllaDB Rust 드라이버 Kubernetes를 위한 ScyllaDB 운영자 ScyllaDB 모니터링 ScyllaDB 관리자 8 VCPU 32 GB 메모리 무기/그라비톤 EBS 볼륨 (gp3) 500 MBps 대역폭 및 12k IOPS ARM을 사용하면 비용이 절감되며, EBS(gp3) 볼륨을 사용하는 결정은 궁극적으로 가용성, 유연성 및 가격 성능으로 이어졌습니다.그들은 "이것은 논란의 여지가 있지만 우리는 그것을 작동시키려고 노력하고 있으며 우리가 얼마나 오래 관리 할 수 있는지 볼 수 있습니다."라고 인정했습니다. 배운 교훈 여기서 배운 중요한 교훈은... ScyllaDB와 Postgres와 함께 작업하는 가장 큰 차이점은 파티션 및 파티션 크기에 대해 상당히 신중하게 생각해야한다는 것입니다. Keep an eye on partition sizes: 또한 읽기/쓰기 패턴에 대해 신중하게 생각해야 합니다. 귀하의 워크로드가 읽기/쓰기 무거운가요? 읽기/쓰기 좋은 조합이 있나요? 또는 대부분 쓰기 무거운가요? Coralogix의 워크로드는 데이터를 끊임없이 섭취하기 때문에 꽤 쓰기 무거운가요, 그러나 읽기 지연이 비즈니스에 가장 중요하기 때문에 읽기를 우선시해야 합니다. Think about read/write patterns: 팀은 EBS를 사용하지 말라는 경고를 받았다고 인정합니다 : "우리는 듣지 않았지만 아마도 해야 할 것입니다.ScyllaDB를 사용하는 것을 고려하고 있다면 EBS 볼륨을 사용하는 대신 로컬 SSD가있는 인스턴스를 살펴 보는 것이 좋을 것입니다. " Avoid EBS: 미래 계획: WebAssembly UDFs with Rust 미래에, 그들은 충분히 큰 조각을 작성하고 불필요한 데이터를 읽는 사이의 중간 지점을 찾고 싶어 ~8,000 행으로 조각을 분할하고 있으며, 삽입을 가속화 할 수있는 1,000 행으로 더 분할 할 수 있다고 생각합니다. 그들의 궁극적 인 목표는 ScyllaDB에 더 많은 작업을 전송하여 ScyllaDB를 활용하는 것입니다. 기존 Rust 코드를 사용하면 UDF를 통합하면 데이터를 응용 프로그램으로 돌려보낼 필요가 없어 조정 및 잠재적 향상에 대한 유연성을 제공합니다. WebAssembly를 사용하여 사용자 정의 함수(User Defined Functions, UDFs) 세바스티안은 "우리는 이미 모든 것을 Rust로 썼다.우리가 UDF를 사용하기 시작할 수 있다면 정말 좋을 것이므로 응용 프로그램에 아무것도 보내지 않아도됩니다. Tech Talk 전체 보기 당신은 우리의 기술 토크 라이브러리에서 데크를 통해 전체 기술 토크를 볼 수 있습니다. Cynthia Dunlop에 대한 리뷰 보기 Cynthia는 ScyllaDB의 컨텐츠 전략 고위 이사이며 20 년 이상 소프트웨어 개발 및 품질 엔지니어링에 대해 글을 쓰고 있습니다.
