How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. スピードが大事なのは Coralogix はリアルタイムのストリーミング分析パイプラインを使用し、監視、視覚化、およびアラート機能を提供し、インデックス化を必要としません。 コラロジックス Coralogixの主要な区別子の1つは、リモートストレージにある顧客のアーカイブからのマッピングデータに対する迅速なクエリのための分散クエリエンジンです。 元々は、潜在的なオブジェクトストレージの上にステータスなしのクエリエンジンとして設計されたが、クエリ実行中にパルケットメタデータを読み込むことで、これを克服するために、大きなクエリを実行するために必要なパルケットメタデータのより迅速な取得と処理を可能にするメタデータストア(単に「メタストア」と呼ばれる)を開発した。 駐車場 PostgreSQL に基づいて構築された元のメタストアの実装は、彼らのニーズに適した速度ではなかったので、チームは新しい実装を試みた――今回は PostgreSQL の代わりに ScyllaDB を用いた。 スパイラー:それは効いた。 彼らは印象的なパフォーマンスの向上を達成し、クエリ処理時間を 30 秒から 86 ミリ秒に短縮しました。 そして、彼らのエンジニア Dan Harris (主要ソフトウェアエンジニア) と Sebastian Vercruysse (上級ソフトウェアエンジニア) が ScyllaDB サミットでステージに立ってそれをどのように行ったか説明しました。 ScyllaDB Summit 24 に参加して、チームが最も困難なデータベースの課題に対処する方法についてより多くの最初のレポートを聞くことができます。 ScyllaDB Summit 2024 が開催されました! Update: Metastore 動機と要件 メタストアの実装の詳細に入る前に、一歩後退し、まずメタストアを構築する理由を見ていきましょう。 「当初は、このプラットフォームを、潜在的なオブジェクトストレージの上にステータスなしのクエリエンジンとして設計しましたが、クエリ実行中にパルケットメタデータを読み取る費用が、クエリの時間の大きな割合であることにすぐに気づきました」とダン・ハリスは説明しました。 彼らは、以下のような解決策を想定した。 Parquet メタデータを分解された形式で格納し、高スケーラビリティとスピードアップを実現 bloom フィルターを使用して、各クエリでスキャンするファイルを効率的に識別します。 トランザクション コミット ログを使用して、トランザクション ストレージにある既存のデータを追加、更新、および置き換える 主な要件は、低い遅延、読み書き能力の両方の面でスケーラビリティ、および潜在的なストレージのスケーラビリティでした。 1 時間あたり 2,000 件の Parquet ファイル(1 日あたり 50,000 件)を生成し、合計 15 TB を 1 日あたり生成し、Parquet メタデータだけで 20 GB を生成します。 . 単一顧客 たった一日で 単一顧客 たった一日で PostgreSQLの初期実装 「我々はPostgresで初期の実装を開始し、分散されていないエンジンが長期的に十分ではないことを理解した」とダンは認めた。その初期の実装は「ブロック」のような重要な情報を格納し、1行グループと1パルケートファイルを表しています。 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 … 読書を最適化するために、彼らは効率的なデータ削除のためにブルームフィルターを使用しました。ダンは詳細に述べた、「最終的には、我々はフルテキスト検索のようなものをサポートしたいです。基本的に、我々がこれらのファイルを我々のシステムに注入しているとき、我々は、ファイルで見つけるすべての異なるトークンのためのブルームフィルターを構築することができます。それから、特定のクエリに基づいて、我々はスキャンする必要があるデータを削除するために、これらのブルームフィルターを使用することができます。 さらに、各 Parquet ファイルのコラムメタデータを保存しました。 Block URL Row Group Column Name Column metadata (blob) ダンは「私たちが書いているファイルはかなり広く、時には2万本の列まであるので、必要なメタデータだけを読み取ると、任意のクエリに必要なIO量を本当に減らすことができます」と説明した。 ScyllaDBの実装 次に、ダンのチームメイトであるセバスチャン・ヴェルクライスが述べたように、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 大胆な部分は、顧客のトップレベルのバケットであり、バケットの内部では、アイテムは時間によって分割されます。 (テーブルURL) しかし、一部の顧客は他の顧客よりも多くのParquetファイルを持っており、バランスを保ちたいと考えています。 ((Block url, row group))? これは、特定のブロックをユニークに識別しますが、タイムスタンプがキーにないため、特定の日のすべてのブロックをリストすることは困難になります。 ((Table url, time))? それは、あなたがクエリするのに24時間があるので、簡単にクエリすることができます。 ((Table url, time), block url, row group) )) それが彼らが選択したことです。 ブロック url と row group をクラスタリング キーとして追加することにより、彼らは1時間以内に特定のブロックを簡単に取得することができ、これはまた、ブロックや行グループを更新または削除するプロセスを簡素化します。 Bloom Filter Chunking and Data Modeling(ブルーム・フィルター・チャンキングとデータ・モデリング) 次の課題: 特定のビットが設定されていることを確認する方法は、ScyllaDBがそのためのボックスオフ機能を提供していないためです。チームは、ブロームフィルターを読み込み、アプリケーションでそれらを処理することにしました。しかし、彼らはクライアントごとに1日あたり5万ブロックまで取り扱っていることを覚えておいてください、ブロームフィルター部分の262KBを含む各ブロックです。これは合計12GBです - 1つのクエリのためにアプリケーションに戻すにはあまりにも多いです。しかし、彼らは毎回全体のブロームフィルターを読み取る必要はありませんでした。彼らはクエリ実行中に関連するトークンに依存して、その一部だけが必要でした。 データモデリングの場合、選択肢の1つは使用することでした。 プリミアムキーとして. それは bloom フィルターごとに 32 バイトの 8192 ブロックを生成し、パーティションごとに約 262 KB の均等な配布を生成します. 同じパーティションのすべての bloom フィルターで、単一のバッチ クエリでデータを挿入して削除することは容易になります. しかし、読み取り効率に影響を与えるキャッチがあります:あなたは bloom フィルターを読み取る前にブロックの ID を知る必要があります. さらに、アプローチは、相当数のパーティションにアクセスすることを含むでしょう; 50K ブロックは 50K パーティションを意味します. そして、セバスチャンが指摘したように、「ScyllaDB のように速い何かでさえ、50K パーティ (block_url、row_group、chunk index) もう一つの選択肢(最終的に彼らが決めたもの): 注:これはブロックと同一のパーティションキーであり、パーティションキーに、クエリ エンジンが要求する n 番目のトークンを表すインデックスが追加されています。 ((table url, hour, chunk index), block url, row group) さらに、このアプローチは、ブロックIDをブロックフィルターを読み取る前に必要としなくなり、より速い読み取りを可能にします。もちろん、常に妥協が存在します。ここでは、ブロックされたブロックフィルターアプローチのために、彼らは単一のブロックフィルターを8192個のユニークなパーティションに分割しなければなりません。これは、以前のパーティションアプローチと比較して、すべてのブロックフィルターのブロックを一度に飲み込むことを可能にしたものに比べて、摂取速度に影響を与えるようになります。 データモデリング Woes 驚くべきことに、SQL から NoSQL への移行には、いくつかの試行とエラーを含む、相当な量のデータモデリングの再作業が含まれていました。例えば、セバスチャンは、「ある日、私たちは min と max タイムスタンプを混乱させたことに気付きました - そして、私はそれをどのように修正するつもりだったのかと私は考えました。 最終的に、彼らはテーブルを断ち切って再び始めることを決意し、移行コードを書くことにより、この前線での彼らの最高のアドバイスは、最初にそれを正しく取ることです。 パフォーマンス Gain 必要なデータモデリング作業にもかかわらず、移行はうまく支払われました。 現在、各ノードは4～5TBに対応しています。 彼らは現在、1 ミリ秒未満に P99 の遅延で 1 秒あたり約 10K の書き込みを処理しています。 ブロックリストの結果、1時間で約2000個のパルケートファイルが処理され、花開きフィルターで20ミリ秒未満で処理されます。 50Kファイルの場合、それは500ミリ秒未満です。 彼らはビットのチェックもしますが、50Kパルケートファイルの場合、500ミリ秒は彼らのニーズに適しています。 コラムメタデータ処理では、P50はかなり良いですが、高い尾の遅延性があります。セバスチャンは「問題は、私たちが50Kパルケートファイルを持っている場合、私たちの実行者はこれらをすべて並行して取得しているということです。 ScyllaDB セットアップ 注目すべきことに、Coralogix は ScyllaDB を最初に発見し、わずか 2 か月でテラバイトのデータを生産することに移行しました(これは、より単純な Cassandra または DynamoDB 移行ではなく、データモデリング作業を必要とする SQL から NoSQL への移行でした)。 The implementation was written in Rust on top of the そして、彼らは見つけた で、 そして、 Coralogix が顧客に低コストの観測可能な代替品を提供することが重要であるため、Coralogix チームは ScyllaDB インフラストラクチャの有利な価格性能に満足しました。 ScyllaDB Rust ドライバー Kubernetes 用の ScyllaDB オペレーター ScyllaDBモニタリング ScyllaDB マネージャー 8 VCPU 32GBメモリ ARM/グラビトン EBS ボリューム (gp3) with 500 MBps bandwidth and 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 将来、彼らは十分に大きなブロックを書くことと、不要なデータを読み取ることの間の真ん中を見つけることを望んでいます.彼らはブロックを ~ 8000 行に分割し、彼らはそれらをさらに 1,000 行に分割することができると信じています。 彼らの究極の目標は、ScyllaDBにさらに多くの仕事をオフロードすることです。 既存の Rust コードを使用すると、UDF を統合すると、データをアプリケーションに送信する必要がなくなり、調整や潜在的な改善のための柔軟性を提供します。 User Defined Functions (UDFs) with WebAssembly セバスチャンは、「私たちはすでにRustで書かれたすべてを持っています。UDFを使用し始めることができ、アプリケーションに何も返す必要はありません。 テクノロジーの完全な会話を見る あなたは私たちのテクノロジー チャット ライブラリでデッキを通して完全なテクノロジー チャットを見ることができます。 Cynthia Dunlopについて Cynthia は ScyllaDB のコンテンツ戦略のシニアディレクターであり、20年以上にわたりソフトウェア開発と品質エンジニアリングについて書いています。
