How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. Tốc độ quan trọng cho , một nền tảng quan sát mà các nhóm phát triển tin tưởng để phát hiện các sự cố trước khi chúng leo thang thành vấn đề. Coralogix sử dụng đường ống phân tích phát trực tuyến thời gian thực, cung cấp khả năng giám sát, trực quan hóa và cảnh báo mà không yêu cầu lập chỉ mục. Coralogix Một trong những phân biệt quan trọng của Coralogix là một công cụ truy vấn phân tán để truy vấn nhanh về dữ liệu được lập bản đồ từ kho lưu trữ từ xa của khách hàng. Nó ban đầu được thiết kế như một công cụ truy vấn không trạng thái trên bộ lưu trữ đối tượng cơ bản, nhưng việc đọc siêu dữ liệu Parquet trong quá trình thực hiện truy vấn đã giới thiệu một hit độ trễ không thể chấp nhận được. Để khắc phục điều này, họ đã phát triển một kho siêu dữ liệu (đơn giản gọi là "metastore") để cho phép truy xuất và xử lý siêu dữ liệu Parquet nhanh hơn cần thiết để thực hiện truy vấn lớn. Công viên Việc triển khai metastore ban đầu, được xây dựng trên nền tảng PostgreSQL, không đủ nhanh để đáp ứng nhu cầu của họ. Vì vậy, nhóm đã thử một triển khai mới – lần này, với ScyllaDB thay vì PostgreSQL. Spoiler: Nó đã hoạt động. Họ đã đạt được lợi ích hiệu suất ấn tượng – cắt giảm thời gian xử lý truy vấn từ 30 giây đến 86 miliseconds. Và các kỹ sư của họ Dan Harris (Kỹ sư phần mềm chính) và Sebastian Vercruysse (Kỹ sư phần mềm cấp cao) đã tham gia Hội nghị thượng đỉnh ScyllaDB để giải thích cách họ làm điều đó. Tham gia với chúng tôi tại ScyllaDB Summit 24 để nghe thêm thông tin trực tiếp về cách các nhóm đang giải quyết những thách thức cơ sở dữ liệu khó khăn nhất của họ. Disney, Discord, Expedia, Supercell, Paramount và nhiều hơn nữa đều nằm trong chương trình nghị sự. ScyllaDB Summit 2024 bây giờ là một wrap! Update: Metastore Động lực và Yêu cầu Trước khi đi vào các chi tiết triển khai metastore, hãy lùi lại một bước và xem xét lý do để xây dựng một metastore ở nơi đầu tiên. "Chúng tôi ban đầu thiết kế nền tảng này như một công cụ truy vấn không trạng thái trên bộ nhớ đối tượng cơ bản - nhưng chúng tôi nhanh chóng nhận ra rằng chi phí đọc siêu dữ liệu Parquet trong quá trình thực hiện truy vấn là một tỷ lệ phần trăm lớn thời gian truy vấn", Dan Harris giải thích. Họ đã hình dung ra một giải pháp sẽ: Lưu trữ các siêu dữ liệu Parquet trong một định dạng phân hủy cho khả năng mở rộng và thông lượng cao Sử dụng các bộ lọc bloom để xác định hiệu quả các tệp để quét cho mỗi truy vấn Sử dụng nhật ký cam kết giao dịch để thêm, cập nhật và thay thế dữ liệu hiện có trong lưu trữ đối tượng cơ bản Các yêu cầu chính bao gồm độ trễ thấp, khả năng mở rộng về cả khả năng đọc / viết và khả năng mở rộng của bộ nhớ cơ bản. tạo 2.000 tập tin Parquet mỗi giờ (50.000 mỗi ngày), tổng cộng 15 TB mỗi ngày, kết quả là 20 GB trong siêu dữ liệu Parquet một mình . a single customer Trong một ngày duy nhất Một khách hàng duy nhất Trong một ngày duy nhất Cài đặt PostgreSQL ban đầu “Chúng tôi bắt đầu triển khai ban đầu trên Postgres, hiểu vào thời điểm đó rằng một công cụ không được phân phối sẽ không đủ trong thời gian dài”, Dan thừa nhận. triển khai ban đầu đó lưu trữ thông tin quan trọng như “blocks”, đại diện cho một nhóm hàng và một tệp Parquet. 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 … Để tối ưu hóa việc đọc, họ đã sử dụng các bộ lọc bloom để cắt dữ liệu hiệu quả. Dan chi tiết, “Cuối cùng, chúng tôi muốn hỗ trợ một cái gì đó như tìm kiếm toàn văn. Về cơ bản, khi chúng tôi nhập các tệp này vào hệ thống của chúng tôi, chúng tôi có thể xây dựng một bộ lọc bloom cho tất cả các token riêng biệt mà chúng tôi tìm thấy trong tệp. Sau đó, dựa trên một truy vấn cụ thể, chúng tôi có thể sử dụng các bộ lọc bloom đó để cắt dữ liệu mà chúng tôi cần để quét.” Ngoài ra, họ lưu trữ siêu dữ liệu cột cho mỗi tệp Parquet. Ví dụ: Block URL Row Group Column Name Column metadata (blob) Dan giải thích: “Các tệp mà chúng tôi đang viết khá rộng, đôi khi lên đến 20.000 cột.Vì vậy, bằng cách chỉ đọc các siêu dữ liệu mà chúng tôi cần, chúng tôi thực sự có thể giảm số lượng IO cần thiết cho bất kỳ truy vấn nào”. ScyllaDB triển khai Tiếp theo, chúng ta hãy nhìn vào việc thực hiện ScyllaDB như được mô tả bởi đồng đội của Dan, Sebastian Vercruysse. Blocks mô hình dữ liệu Mô hình khối phải được xem xét lại cho việc thực hiện mới.Đây là một ví dụ về URL khối: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Phần táo bạo là thùng chứa hàng đầu của khách hàng; bên trong thùng chứa, các mặt hàng được phân chia theo giờ. Nhưng một số khách hàng có nhiều tập tin Parquet hơn những khách hàng khác, và họ muốn giữ sự cân bằng. ((Block url, row group))? Điều này xác định duy nhất một khối nhất định, nhưng sẽ khó để liệt kê tất cả các khối cho một ngày nhất định bởi vì dấu thời gian không nằm trong khóa ((Table url, time))? Điều đó hoạt động bởi vì nếu bạn có 24 giờ để truy vấn, bạn có thể truy vấn khá dễ dàng ((Table url, time), block url, row group)? Đó là những gì họ đã chọn.Bằng cách thêm khối url và nhóm hàng làm phím nhóm, họ có thể dễ dàng truy xuất một khối cụ thể trong vòng một giờ, điều này cũng đơn giản hóa quá trình cập nhật hoặc xóa các khối và nhóm hàng. Bloom Filter Chunking và Data Modeling Thách thức tiếp theo: làm thế nào để xác minh rằng một số bit nhất định được thiết lập, vì ScyllaDB không cung cấp các chức năng ngoài hộp cho điều đó. Nhóm đã quyết định đọc các bộ lọc bloom và xử lý chúng trong ứng dụng. Tuy nhiên, hãy nhớ rằng họ đang xử lý lên đến 50.000 khối mỗi ngày cho mỗi khách hàng, mỗi khối chứa 262 KB cho phần bộ lọc bloom. Đó là tổng cộng 12 GB – quá nhiều để kéo trở lại ứng dụng cho một truy vấn. Nhưng họ không cần phải đọc toàn bộ bộ bộ lọc bloom mỗi lần; họ chỉ cần một phần của nó, tùy thuộc vào các mã thông báo liên quan trong quá trình thực hiện truy vấn. Vì vậy, họ kết thúc bằng cách chia các bộ lọc bloom thành các hàng, làm giảm dữ liệu đọc thành 1.6 megabyte có thể quản lý. Đối với mô hình dữ liệu, một lựa chọn là sử dụng như khóa chính. Điều đó sẽ tạo ra 8192 miếng 32 byte mỗi bộ lọc bloom, kết quả là phân phối bằng nhau với khoảng 262 KB mỗi phân vùng. Với mỗi bộ lọc bloom trong cùng một phân vùng, sẽ dễ dàng để chèn và xóa dữ liệu với một truy vấn lô duy nhất. Nhưng có một nắm bắt ảnh hưởng đến hiệu quả đọc: bạn sẽ cần phải biết ID của khối trước khi bạn có thể đọc bộ lọc bloom. Ngoài ra, phương pháp tiếp cận sẽ liên quan đến việc truy cập một số lượng đáng kể các phân vùng; 50K khối có nghĩa là các phân vùng 50K. Và như Sebastian lưu ý, “ngay cả với một cái gì đó nhanh như ScyllaDB, nó vẫn khó để đạt được quá trình phân vùng phụ cho các phân vùng 50K.” ((block_url, row_group), chỉ số chunk) Một lựa chọn khác (mà cuối cùng họ đã quyết định): Lưu ý rằng đây là cùng một khóa phân vùng như khóa Blocks, với một chỉ số được thêm vào khóa phân vùng đại diện cho token nth được yêu cầu bởi công cụ truy vấn.Với cách tiếp cận này, quét 5 token trải qua một cửa sổ 24 giờ dẫn đến 120 phân vùng – một cải tiến ấn tượng so với tùy chọn mô hình dữ liệu trước đó. ((table url, time, chunk index), block url, row group) Hơn nữa, cách tiếp cận này không còn yêu cầu ID khối trước khi đọc bộ lọc hoa - cho phép đọc nhanh hơn. Tất nhiên, luôn luôn có sự thỏa hiệp. Ở đây, do cách tiếp cận bộ lọc hoa bị chặn, họ phải chia một bộ lọc hoa duy nhất thành 8192 phân vùng duy nhất. Điều này cuối cùng ảnh hưởng đến tốc độ tiêu thụ so với cách tiếp cận phân vùng trước đó cho phép tiêu thụ tất cả các mảnh bộ lọc hoa cùng một lúc. Tuy nhiên, khả năng đọc nhanh một khối nhất định trong một giờ là quan trọng hơn đối với họ so với viết nhanh - vì vậy họ quyết định rằng sự thỏa hiệp này đáng giá. Mô hình dữ liệu Woes Không có gì đáng ngạc nhiên khi chuyển từ SQL sang NoSQL liên quan đến một số lượng công việc mô hình dữ liệu, bao gồm một số thử nghiệm và lỗi. Ví dụ, Sebastian chia sẻ, “Một ngày nọ, tôi phát hiện ra rằng chúng tôi đã phá vỡ các dấu thời gian min và max – và tôi tự hỏi làm thế nào tôi sẽ sửa nó. tôi nghĩ có thể tôi có thể đổi tên các cột và sau đó bằng cách nào đó làm cho nó hoạt động trở lại. nhưng ở đây bạn không thể đổi tên một cột nếu nó là một phần của một phím nhóm. tôi nghĩ tôi chắc chắn có thể thêm các cột mới và chạy một truy vấn UPDATE để cập nhật tất cả các hàng. Cuối cùng, họ quyết định cắt bàn và bắt đầu lại so với viết mã di chuyển. lời khuyên tốt nhất của họ về mặt này là để có được nó đúng lần đầu tiên. 🙂 Hiệu suất gain Mặc dù công việc mô hình dữ liệu được yêu cầu, việc di chuyển đã trả giá tốt. Đối với danh sách khối metastore: Mỗi nút hiện đang xử lý 4-5 TB. Họ hiện đang xử lý khoảng 10K chữ viết mỗi giây với độ trễ P99 liên tục dưới một milisecond. Việc liệt kê khối dẫn đến khoảng 2.000 tệp parquet trong một giờ; với các bộ lọc hoa của họ, chúng được xử lý trong chưa đầy 20 milisecond. Đối với các tập tin 50K, đó là ít hơn 500 miliseconds. Tuy nhiên, đối với các tập tin Parquet 50K, 500 milliseconds là tốt cho nhu cầu của họ. Trong xử lý siêu dữ liệu cột, P50 khá tốt, nhưng có độ trễ đuôi cao. Sebastian giải thích: “Vấn đề là nếu chúng ta có các tệp Parquet 50K, các trình thực thi của chúng tôi đang thu thập tất cả những điều này song song. ScyllaDB Thiết lập Đáng chú ý, Coralogix đã chuyển từ lần đầu tiên khám phá ScyllaDB sang sản xuất với terabytes dữ liệu chỉ trong 2 tháng (và đây là một di chuyển SQL sang NoSQL đòi hỏi công việc mô hình dữ liệu, không phải là một di chuyển Cassandra hoặc DynamoDB đơn giản hơn nhiều). Việc thực hiện đã được viết trong Rust trên Và họ tìm thấy , và Vì việc cung cấp cho khách hàng của họ một sự thay thế khả năng quan sát chi phí thấp là quan trọng đối với Coralogix, nhóm Coralogix rất hài lòng với hiệu suất giá cả thuận lợi của cơ sở hạ tầng ScyllaDB của họ: một cụm 3 nút với: Lái xe ScyllaDB Rust Hệ điều hành ScyllaDB cho Kubernetes Giám sát ScyllaDB Quản lý ScyllaDB 8 VCPU 32 GiB bộ nhớ Bàn tay / Graviton EBS Volumes (gp3) với băng thông 500 MBps và 12k IOPS Sử dụng ARM làm giảm chi phí, và quyết định sử dụng khối lượng EBS (gp3) cuối cùng đã giảm xuống sự sẵn có, linh hoạt và hiệu suất giá. Họ thừa nhận, “Đây là một quyết định gây tranh cãi – nhưng chúng tôi đang cố gắng làm cho nó hoạt động và chúng tôi sẽ xem chúng tôi có thể quản lý trong bao lâu.” Bài học học Những bài học quan trọng của họ được học ở đây... Sự khác biệt lớn nhất khi làm việc với ScyllaDB so với làm việc với Postgres là bạn phải suy nghĩ khá cẩn thận về phân vùng và kích thước phân vùng của bạn. Keep an eye on partition sizes: Bạn cũng phải suy nghĩ cẩn thận về các mô hình đọc/viết. khối lượng công việc của bạn có quá nặng để đọc? Có phải nó liên quan đến một sự pha trộn tốt của đọc và viết? Hoặc, chủ yếu là nặng để viết? khối lượng công việc của Coralogix khá nặng để viết vì chúng liên tục hấp thụ dữ liệu, nhưng họ cần ưu tiên đọc vì độ trễ đọc là quan trọng nhất đối với doanh nghiệp của họ. Think about read/write patterns: Nhóm thừa nhận họ đã được cảnh báo không sử dụng EBS: “Chúng tôi không lắng nghe, nhưng chúng tôi có lẽ nên.Nếu bạn đang xem xét sử dụng ScyllaDB, có lẽ sẽ là một ý tưởng tốt để xem xét các trường hợp có SSD cục bộ thay vì cố gắng sử dụng khối lượng EBS.” Avoid EBS: Kế hoạch tương lai: WebAssembly UDFs với Rust Trong tương lai, họ muốn tìm ra điểm trung gian giữa việc viết các mảnh đủ lớn và đọc dữ liệu không cần thiết.Họ đang chia các mảnh thành ~8.000 hàng và tin rằng họ có thể chia chúng thêm vào 1.000 hàng, điều này có thể tăng tốc độ chèn của họ. Mục tiêu cuối cùng của họ là tải thêm công việc lên ScyllaDB bằng cách tận dụng lợi thế của ScyllaDB. Với mã Rust hiện có của họ, tích hợp UDF sẽ loại bỏ sự cần thiết phải gửi dữ liệu trở lại ứng dụng, cung cấp sự linh hoạt cho việc điều chỉnh và cải tiến tiềm năng. User Defined Functions (UDFs) với WebAssembly Sebastian chia sẻ, “Chúng tôi đã có tất cả mọi thứ được viết bằng Rust. Nó sẽ rất tốt nếu chúng tôi có thể bắt đầu sử dụng UDFs để chúng tôi không phải gửi bất cứ điều gì trở lại ứng dụng. Xem toàn bộ Tech Talk Bạn có thể xem toàn bộ trò chuyện công nghệ và trượt qua boong trong thư viện trò chuyện công nghệ của chúng tôi. Thông tin Cynthia Dunlop Cynthia là giám đốc quản lý chiến lược nội dung tại ScyllaDB. Cô đã viết về phát triển phần mềm và kỹ thuật chất lượng trong hơn 20 năm.
