複数の時系列データベースをテストした方法

ここ数年で、時系列データベースは突飛なもの (オープン監視システム (および特定のソリューションに関連付けられている) またはビッグデータ プロジェクトで使用される高度に特殊化されたもの) から「消費者向け製品」に変わりました。 ロシア連邦の領土において、これについては Yandex と ClickHouse に特別な感謝を捧げなければなりません。 この時点まで、大量の時系列データを保存する必要がある場合は、巨大な Hadoop スタックを構築して維持する必要性を受け入れるか、システムごとに個別のプロトコルで通信する必要がありました。

2019 年には、どの TSDB を使用する価値があるかに関する記事は、「ClickHouse を使用してください」という XNUMX つの文だけで構成されているように思われるかもしれません。 しかし...ニュアンスがあります。

確かに、ClickHouse は積極的に開発されており、ユーザー ベースは拡大しており、サポートも非常に活発ですが、私たちは ClickHouse の公的成功の人質になってしまい、おそらくより効果的で信頼性の高い他のソリューションに影を落としてしまったのでしょうか?

昨年の初めに、私たちは独自の監視システムの再構築を開始しました。その際、データを保存するための適切なデータベースを選択するという問題が生じました。 ここではこの選択の歴史についてお話したいと思います。

問題の定式化

まず、必要な前置き。 そもそもなぜ独自の監視システムが必要なのでしょうか?また、それはどのように設計されたのでしょうか?

当社は 2008 年にサポート サービスの提供を開始しましたが、2010 年までに、当時存在していたソリューション (ごめんなさい、Cacti、Zabbix について話しています) ではクライアント インフラストラクチャで発生しているプロセスに関するデータを集約することが困難になっていることが明らかになりました。そして新興のグラファイト）。

私たちの主な要件は次のとおりです。

• XNUMX つのシステム内で多数のクライアント (当時は数十、将来的には数百) をサポートし、同時に集中アラート管理システムの存在。
• 警報システム管理の柔軟性（当直職員間の警報のエスカレーション、スケジュール設定、知識ベース）。
• グラフを詳細に表示する機能 (当時の Zabbix はグラフを画像の形でレンダリングしていました)。
• 大量のデータを長期保存 (XNUMX 年以上) し、それを迅速に取得する機能。

この記事では最後の点に注目します。

ストレージに関して言えば、要件は次のとおりです。

• システムは迅速に動作する必要があります。
• システムには SQL インターフェースがあることが望ましいです。
• システムは安定しており、アクティブなユーザー ベースとサポートが必要です (かつて開発されなくなった MemcacheDB や、バグ トラッカーが中国語で保存されていた MooseFS 分散ストレージなどのシステムをサポートする必要に直面しました。私たちのプロジェクトが望まなかったため、この話を繰り返します）。
• CAP 定理への準拠: 整合性 (必須) - データは最新である必要があります。アラート管理システムが新しいデータを受信せず、すべてのプロジェクトのデータ未到着に関するアラートを吐き出すことは望ましくありません。 パーティション トレランス (必須) - スプリット ブレイン システムを取得したくありません。 可用性 (アクティブなレプリカがある場合は重要ではありません) - 事故が発生した場合は、コードを使用して自分でバックアップ システムに切り替えることができます。

奇妙なことに、当時、MySQL が私たちにとって理想的なソリューションであることが判明しました。 データ構造は非常にシンプルで、サーバー ID、カウンター ID、タイムスタンプ、値です。 ホット データの高速サンプリングは大規模なバッファ プールによって確保され、履歴データのサンプリングは SSD によって確保されます。

このようにして、データが完全にレンダリングされる前の 200 ミリ秒までの詳細を含む、新鮮な XNUMX 週間のデータのサンプルを取得し、このシステムでかなり長期間存続しました。

その間にも時間が経ち、データ量は増大していきました。 2016 年までに、データ量は数十テラバイトに達し、SSD ストレージをレンタルする場合、これはかなりの費用になりました。

この時点までに、カラム型データベースは積極的に普及しており、私たちはそれについて積極的に考え始めました。カラム型データベースでは、ご存知のとおり、データは列に格納されており、データを見ると、大きなデータが簡単に確認できます。列指向データベースを使用する場合は、圧縮を使用して圧縮できる重複の数。

しかし、会社の基幹システムは引き続き安定して動作しており、他のものに切り替える実験はしたくありませんでした。

2017 年、サンノゼで開催された Percona Live カンファレンスで、Clickhouse 開発者はおそらく初めて自らの存在を発表しました。 一見したところ、このシステムは運用準備が整っており (Yandex.Metrica は過酷な運用システムです)、サポートは迅速かつシンプルで、最も重要なことに、操作は簡単でした。 2018 年から移行プロセスを開始しました。 しかし、その頃には「アダルト」で実績のある TSDB システムが多数存在していたため、私たちは、要件に従って Clickhouse に代わるソリューションが存在しないことを確認するために、かなりの時間を費やして代替案を比較することにしました。

すでに指定されているストレージ要件に加えて、新しいストレージ要件も登場しました。

• 新しいシステムは、同じ量のハードウェアで少なくとも MySQL と同じパフォーマンスを提供する必要があります。
• 新しいシステムのストレージに占めるスペースは大幅に少なくなるはずです。
• DBMS は依然として管理しやすいものでなければなりません。
• DBMSを変更する際、アプリケーションの変更は最小限に抑えたかった。

どのようなシステムを検討し始めたのでしょうか?

Apache Hive/Apache Impala
古く、実戦テストされた Hadoop スタック。 基本的に、これは HDFS にネイティブ形式でデータを保存する上に構築された SQL インターフェイスです。

長所

• 安定した動作により、データの拡張が非常に簡単になります。
• データストレージにはカラムソリューションがあります（スペースが少ない）。
• リソースが利用可能な場合、並列タスクを非常に高速に実行します。

短所

• Hadoop ですが、使い方が難しいです。 クラウドで既製のソリューションを導入する準備ができていない場合 (コストの面でも準備ができていない場合)、スタック全体を管理者の手で組み立ててサポートする必要がありますが、それは本当に望んでいません。これ。
• データが集約される 本当に速い.

しかし：

速度は、コンピューティング サーバーの数を拡張することによって実現されます。 簡単に言うと、当社が分析に携わる大企業で、(大量のコンピューティング リソースを使用するという犠牲を払ってでも) 情報をできるだけ早く集約することがビジネスにとって重要である場合、これを選択する可能性があります。 しかし、タスクを高速化するためにハードウェア フリートを増やす準備ができていませんでした。

ドルイド/ピノ

TSDB についてはさらに詳しく説明されていますが、やはり Hadoop スタックについても説明します。

あり ドルイドとピノとクリックハウスの長所と短所を比較した素晴らしい記事 .

一言で言えば、次のような場合には、ドルイド/ピノはクリックハウスよりも優れています。

• データには異質な性質があります (私たちの場合、サーバー メトリックの時系列のみを記録しており、実際にはこれは XNUMX つのテーブルです。ただし、他のケースも考えられます: 機器の時系列、経済の時系列など)。独自の構造があり、集約して処理する必要があります)。
• さらに、このデータはたくさんあります。
• 時系列のテーブルとデータが現れたり消えたりします (つまり、何らかのデータ セットが到着し、分析され、削除されました)。
• データを分割できる明確な基準はありません。

逆のケースでは、ClickHouse のパフォーマンスが向上します。これが私たちのケースです。

クリックハウス

• SQL に似た
• 管理が簡単です。
• 人々はそれが効果があると言います。

テストの最終候補者リストに選ばれます。

流入DB

ClickHouse の外国の代替品。 マイナス点としては、高可用性は商用バージョンにのみ存在しますが、比較する必要があります。

テストの最終候補者リストに選ばれます。

カサンドラ

一方で、これは、たとえば次のような監視システムによってメトリクス時系列を保存するために使用されることがわかっています。 シグナルFX またはOKMeter。 ただし、詳細はあります。

Cassandra は、従来の意味での列型データベースではありません。 見た目は行ビューに似ていますが、各行に異なる数の列を含めることができるため、列形式のビューを整理しやすくなります。 この意味で、2 億列の制限があれば、一部のデータを列 (および同じ時系列) に格納できることは明らかです。 たとえば、MySQL では列数が 4096 に制限されており、同じことを行おうとするとコード 1117 のエラーが発生しやすくなります。

Cassandra エンジンは、マスターなしで分散システムに大量のデータを保存することに重点を置いており、前述の Cassandra CAP 定理は、どちらかというと AP、つまりデータの可用性とパーティショニングに対する耐性に重点を置いています。 したがって、このツールは、このデータベースに書き込むだけでデータベースから読み取ることはほとんどない場合に最適です。 そしてここでは、Cassandra を「コールド」ストレージとして使用するのが論理的です。 つまり、めったに必要とされないが、必要に応じて取得できる大量の履歴データを長期的に保存する信頼できる場所として機能します。 ただし、完全を期すために、これもテストします。 ただし、前に述べたように、選択したデータベース ソリューションのコードを積極的に書き直す必要はないため、データベース構造を Cassandra の仕様に適合させることなく、ある程度限定的にテストします。

プロメテウス

さて、好奇心から、私たちは Prometheus ストレージのパフォーマンスをテストすることにしました。これは、現在のソリューションよりも速いのか遅いのか、またどのくらい遅いのかを理解するためです。

テスト方法と結果

そこで、ClickHouse (5 ノード)、ClickHouse (6 ノードの分散テーブル)、InfluxDB、Mysql 1、Cassandra (3 ノード)、および Prometheus の 8 つの構成で 3 つのデータベースをテストしました。 テスト計画は次のとおりです。

1. 840 週間の履歴データをアップロードします (208 日あたり XNUMX 億 XNUMX 万の値、XNUMX 万 XNUMX メトリクス)。
2. 記録負荷を生成します (6 つの負荷モードが考慮されました。以下を参照)。
3. 記録と並行して、チャートを操作するユーザーのリクエストをエミュレートして、定期的に選択を行います。 物事があまり複雑にならないように、10 週間の XNUMX 個のメトリクス (CPU グラフ上にあるメトリクスの数が正確に一致します) のデータを選択しました。

15 秒ごとに各メトリクスに値を送信するモニタリング エージェントの動作をエミュレートすることで読み込みを行います。 同時に、私たちは次のことを変えることに興味があります。

• データが書き込まれるメトリクスの総数。
• XNUMX つのメトリクスに値を送信する間隔。
• バッチサイズ。

バッチサイズについて。 ほとんどすべての実験用データベースを単一の挿入でロードすることは推奨されないため、受信メトリクスを収集し、それらをグループにグループ化し、バッチ挿入としてデータベースに書き込むリレーが必要になります。

また、受信したデータをどのように解釈するかをより深く理解するために、単に大量のメトリクスを送信するのではなく、メトリクスがサーバーごとに 125 個のメトリクスとして編成されていると想像してみましょう。 ここで、サーバーは単なる仮想エンティティです。たとえば、10000 のメトリクスが約 80 台のサーバーに対応することを理解してください。

これらすべてを考慮して、6 つのデータベース書き込みロード モードを示します。

ここでポイントは50つあります。 第一に、Cassandra の場合、これらのバッチ サイズが大きすぎることが判明したため、100 または XNUMX の値を使用しました。第二に、Prometheus は厳密にプル モードで動作するため、つまり、 それ自体がメトリクス ソースからデータを収集します (プッシュゲートウェイですら、その名前にもかかわらず、状況は根本的に変わりません)。対応する負荷は静的構成の組み合わせを使用して実装されました。

テスト結果は次のとおりです。

注目すべきこと: Prometheus からの驚異的に速いサンプル、Cassandra からの恐ろしく遅いサンプル、InfluxDB からの許容できないほど遅いサンプル。 記録速度の点では、ClickHouse がすべてを勝ち取りましたが、Prometheus は挿入を自ら作成し、何も測定していないため、競争には参加していません。

結果として、: ClickHouse と InfluxDB は最高であることを示しましたが、Influx のクラスターはエンタープライズ バージョンに基づいてのみ構築でき、費用がかかります。一方、ClickHouse は費用がかからず、ロシアで製造されています。 米国ではおそらく inInfluxDB が選択され、我が国では ClickHouse が選択されるのは論理的です。

出所： habr.com