Elasticsearch と Clickhouse のデータストレージの比較 | JD Cloud テクニカルチーム

背景1枚

Jingxingda Technology 部門は、コミュニティグループ購入シナリオで JDQ+Flink+Elasticsearch アーキテクチャを採用し、リアルタイムデータレポートを作成します。ビジネスの発展に伴い、Elasticsearch には大規模なデータクエリには適しておらず、高頻度のページングエクスポートによりダウンタイムと高いストレージコストが発生するなど、いくつかの欠点が明らかになり始めました。

Elasticsearch クエリステートメントはメンテナンスコストが高く、集約コンピューティングシナリオではデータの不正確さが発生します。Clickhouse は列指向データベースであり、当然 OLAP シナリオに適しています。SQL 構文と同様に、開発コストと学習コストを削減し、高速圧縮アルゴリズムを使用してストレージコストを節約し、ベクトル実行エンジンテクノロジを使用して計算時間を大幅に短縮します。したがって、この比較では、Elasticsearch から Clickhouse に切り替えます。

2 OLAP

OLAP とは On-Line Analytical Processing の意味で、Clickhouse は代表的な OLAP オンライン分析データベース管理システム (DBMS) です。OLAP は主に、データの複雑な分析と集計操作を実行します。たとえば、当社の業務システムでは、その日のすべての輸送グループ注文の集計統計を作成し、各州の配送率を計算します。この操作は OLAP データ処理に属します。OLAP と同様に、オンライントランザクション処理を意味する OLTP タイプのデータ処理もあります。OLTP シナリオでは、同時ユーザー操作の量が多くなり、システムはデータ操作にリアルタイムで応答する必要があり、 Mysql、Oracle、SQLServer などはすべて OLTP データベースです。

2.1 OLTPシナリオの特徴

幅の広いテーブル、つまり各テーブルに多数の列が含まれている
読み取りの場合、かなりの数の行がデータベースからフェッチされますが、列の小さなサブセットのみがフェッチされます。
クエリが比較的少ない (通常、サーバーごとに 1 秒あたり数百クエリ以下)
クエリ結果はソースデータよりも大幅に小さくなります。言い換えれば、結果が単一サーバーの RAM に収まるようにデータがフィルタリングまたは集約されます。
主に読み取りリクエスト
データは 1 行ではなくかなりのバッチ (1000 行以上) で更新されるか、まったく更新されません。
単純なクエリの場合、約 50 ミリ秒の遅延が許容されます。
列内のデータは比較的小さく、数値と短い文字列 (例: URL あたり 60 バイト)
単一のクエリを処理する場合は、高いスループット (サーバーごとに 1 秒あたり数十億行) が必要です
ビジネスは必要ありません
データの一貫性に対する要件が低い

3つの特徴

3.1 エラスティックサーチ

検索:転置インデックスに適用可能、各フィールドにインデックスを付けて検索に使用可能、大量のデータの下でほぼリアルタイムで第 2 レベルの応答を実現、Lucene ベースのオープンソース検索エンジン、全文検索の検索を提供、ハイライト、検索の推奨などの能力。百度検索、タオバオ商品検索、ログ検索など。
データ分析: Elasticsearch は、多数のデータ分析 API と豊富な集計機能を提供し、大量のデータに基づいたデータ分析と処理をサポートします。統計的な注文量、さまざまな電子商取引企業の特定の商品データを巡回するクローラー、およびElasticsearchによるデータ分析（各プラットフォームの過去の価格、購買力など）

3.2 クリックハウス

円柱型ストレージ
圧縮アルゴリズム: lz4 および zstd アルゴリズムのデータ圧縮、高い圧縮率を使用して、データサイズを削減し、ディスク IO を削減し、CPU 使用率を削減します。
インデックス: 主キーに従ってデータを並べ替えます。クリックハウスは、大量のデータの中から特定のデータまたはデータ範囲の検索を数十ミリ秒以内に完了できます。
マルチコア並列処理: ClickHouse はサーバー上の利用可能なリソースをすべて使用して、全力でクエリを完了します。
SQL のサポート: SQL に基づく宣言型クエリ言語。多くの場合、ANSI SQL 標準と同じです。group by、order by、from、join、in および非相関サブクエリなどをサポートします。
ベクトルエンジン: CPU を効率的に使用するために、データは列に格納されるだけでなく、ベクトル (列の一部) としても処理され、CPU をより効率的に使用できます。
リアルタイムのデータ更新: データは常に、秩序ある方法で MergeTree に増分的に保存されます。ロックなどの操作を行わずに、継続的かつ効率的にデータをテーブルに書き込むことができます。50M～200M/秒の書き込みトラフィック
オンラインクエリに最適: 高速応答と極めて低い遅延
豊富な集計機能

4 当社のビジネスシナリオ

大きく幅の広いテーブルの場合、インデックス集計計算クエリで多数の行と少数の列を読み取るため、結果セットは比較的小さくなります。データテーブルはすべて Flink によって処理される幅の広いテーブルであり、多くの列があります。データのクエリや分析を行う場合、多くの場合、いくつかの列がディメンション列として選択され、他のいくつかの列がインデックス列として使用され、テーブル全体または特定の範囲内のデータに対して集計計算が実行されます。このプロセスでは、多数のデータ行がスキャンされますが、使用される列はわずか数列のみです。
多数のリストのページネーションのクエリとエクスポート
Flink内のデータは更新されずに大量に追加および書き込まれます
インジケーターの計算では、集計計算のためにテーブル全体のスキャンが必要になる場合があります。
全文検索はほとんど行われません

結論: データレポートとデータ分析のシナリオは典型的な OLAP シナリオです。ビジネスシナリオでは、列指向ストレージデータベース Clickhouse の方が Elasticsearch よりも多くの利点があります。全文検索では Elasticsearch の方が多くの利点がありますが、私たちの全文検索シナリオではそれが劣ります。

5コスト

学習コスト: Clickhouse の SQL 構文は Elasticsearch の DSL よりも単純で、ほとんどすべてのバックエンドの研究開発者には Mysql 開発の経験があり、学習コストは低くなります。
開発、テスト、およびメンテナンスのコスト: Clickhouse は Mysql 開発モデルに似た SQL 構文を使用しており、単体テストの作成が容易です。Elasticsearch は Java API を使用してクエリステートメントを連結しますが、これは複雑で読み取りと保守が困難です。
O&M コスト: 不明。インターネット上のログシナリオでは、Clickhouse のコストは Elasticsearch よりも低くなります。
サーバーコスト:
Clickhouse は Elasticsearch よりもデータ圧縮率が高く、同じ業務データに対して ES が占有するディスク容量は Clickhouse の 3 ～ 10 倍、平均で 6 倍になります。写真1を参照してください
Clickhouse は ES よりも CPU とメモリの使用量が少ない

結論: 同じ量のデータの場合、Elasticsearch が使用するストレージ容量は Clickhouse の 3 ～ 10 倍で、平均は 6 倍です。総合的な学習、開発、テスト、メンテナンスという点では、Clickhouse は Elasticsearch よりもフレンドリーです

6つのテスト

6.1 サーバー構成

以下はすべて、下図の構成に基づいてテストされています。

6.2 筆圧テスト

以下は、wms_order_sku テーブルと、ビジネスの安定性を条件に Elasticsearch と Clickhouse 1000W+ のデータを Flink 経由で二重書き込みして得られたテスト結果に基づいています

CPU 使用率: Elasticsearch の CPU 使用率は高くなりますが、Clickhouse の CPU 使用率はほとんどありません。図2を参照

メモリ使用量: Elasticsearch のメモリは増加し、GC が頻繁に発生しますが、Clickhouse のメモリ使用量は比較的低く、比較的安定しています。図3を参照

書き込みスループット: CH 単体の書き込み速度は約 50 ～ 200MB/s、書き込まれるデータが 1 行あたり 1kb の場合、書き込み速度は 5 ～ 20W/s になります。図 4 (書き込みスループット) は Internet Elasticsearch との比較表ですClickhouse によって書き込まれたデータの CH 書き込みパフォーマンスは、同じデータサンプルの下で Elasticsearch の 5 倍です。現在の Flink タスクは二重に記述されているため、相互影響を考慮して、後で圧力テストの結果を補足します。

結論: データをバッチで書き込む場合、Elasticsearch は Clickhouse よりも多くのメモリと CPU を消費します。Elasticsearch が消費するメモリは Clickhouse の 5.3 倍、CPU は Clickhouse の 27.5 倍です。Elasticsearchの5倍のスループット

6.3 クエリのパフォーマンス (単一同時実行テスト)

次のシナリオは、データレポートとデータ分析に表示される高頻度のシナリオであるため、クエリパフォーマンステストはこれに基づいています。

データの比較

Clickhouse 自体は、クラスター構成を 2 倍にしてもクエリのパフォーマンスにほとんど差はなく、CH2 (48C 182GB) は CH1 (80C 320GB) より平均 14% 遅くなります。図5を参照

クラスター構成が 2 倍悪い場合、Elasticsearch クエリのパフォーマンスは大きな影響を受け、ES2 (46C 320GB) は ES1 (78C 576GB) より平均 40% 遅くなります。図6を参照

CH2 (48C 182GB) と ES2 (46C 320GB) を比較すると、ES2 と CH2 の CPU コア数は同等で、ES2 のメモリは CH2 の 1.75 倍、CH2 の応答速度は ES2 の 12.7 倍です。図 7 を参照

結論: Elasticsearch はデータのクエリ時に Clickhouse よりも遅く、同様の構成の場合、Clickhouse の応答速度は Elasticsearch の 12.7 倍であり、特に時間ベースの複数フィールド集計クエリは Clickhouse より 32 倍高速です。Clickhouse のクエリ応答速度は、クラスター構成のサイズにあまり影響されません。

6.4 クエリプレッシャーテスト (高同時実行性テスト、データはインターネットから取得)

高同時実行テストの準備はより複雑で時間がかかるため、後でビジネスデータとビジネスシナリオに基づいてクエリストレステストを実行します。次のデータは、ユーザーポートレートシナリオ (データボリューム: 262933269) でインターネットによって実施されたテストから取得したもので、これは私たちのシナリオとよく似ています。

結論: Clickhouse は高い同時実行性を十分にサポートしておらず、公式推奨では最大 QPS は 100 です。同時実行性が高い場合、スループットは Elasticsearch ほど良くありません。

7 まとめ

Clickhouse と Elasticsearch を比較した場合の Clickhouse と Elasticsearch の長所と短所。

アドバンテージ：

ハードウェアリソースのコストが低くなり、同じシナリオの下では、Clickhouse の占有リソースが少なくなります。
人件費が安くなり、新規参入者はより友好的になり、学習、単体テスト、テストの開発に介入しやすくなります。
OLAP シナリオでは、Elasticsearch よりも Clickhouse の方が適しており、集計計算は Elasticsearch よりも洗練され高速であり、サーバーのコンピューティングリソースを節約できます。
同じ環境下でElasticsearchと比べて書き込み性能が5倍と高く、書き込み時に消費するサーバーリソースも少ないです。
Elasticsearch は、大量のエクスポートの場合に頻繁に GC を発生し、深刻なダウンタイムを引き起こす可能性があり、Clickhouse ほど安定していません。
平均クエリパフォーマンスは Elasticsearch の 12.7 倍で、Clickhouse のクエリパフォーマンスはサーバー構成の影響を受けにくい
Clickhouse は、同じ月次のサーバー消費量でもより良いパフォーマンスを得ることができます。

欠点:

全文検索では Elasticsearch ほど優れておらず、同時実行性の高いクエリでも Elasticsearch ほど優れていません。

著者: JD Logistics Ma Honyan

コンテンツソース: JD Cloud 開発者コミュニティ