HighLoad++、Andrey Gushchin (Zabbix): 高パフォーマンスとネイティブ パーティショニング

Zabbix が TimescaleDB データベースをバックエンドとしてどのように動作するかを見ていきます。 ゼロから始める方法とPostgreSQLから移行する方法を紹介します。 XNUMX つの構成の比較パフォーマンス テストも提供します。

HighLoad++ シベリア 2019。トムスク ホール。 24月16日、00時。 論文や プレゼンテーション。 次回の HighLoad++ カンファレンスは、6 年 7 月 2020 日と XNUMX 日にサンクトペテルブルクで開催されます。 詳細とチケット リンク.

アンドレイ・グシュチン (以下 – AG): – 私はZABBIXテクニカルサポートエンジニア（以下「Zabbix」）のトレーナーです。 私はテクニカル サポートで 6 年以上働いており、パフォーマンスを直接経験してきました。 今日は、通常の PostgreSQL 10 と比較した場合の TimescaleDB が提供できるパフォーマンスについて説明します。また、一般的にどのように動作するかについての導入部分もいくつか説明します。

生産性の最大の課題: データ収集からデータ クレンジングまで

まず、すべての監視システムが直面する特定のパフォーマンスの課題があります。 生産性の最初の課題は、データを迅速に収集して処理することです。

優れた監視システムは、すべてのデータを迅速かつタイムリーに受信し、トリガー式に従って処理、つまり、いくつかの基準 (これはシステムによって異なります) に従って処理し、このデータをデータベースで使用するためにデータベースに保存する必要があります。未来。

XNUMX 番目のパフォーマンス上の課題は、履歴の保存です。 データベースに頻繁に保存すると、一定期間にわたって収集されたこれらのメトリクスにすばやく簡単にアクセスできます。 最も重要なことは、このデータは取得しやすく、レポート、グラフ、トリガー、一部のしきい値、アラートなどに使用できるということです。

5 番目のパフォーマンスの課題は、履歴のクリアです。つまり、XNUMX 年間 (数カ月または XNUMX か月) にわたって収集された詳細なメトリクスを保存する必要がなくなる時点に到達したときです。 一部のネットワーク ノードまたは一部のホストは削除されており、メトリクスはすでに古くなって収集されなくなったため、メトリクスは不要になりました。 データベースが大きくなりすぎないように、これらすべてをクリーンアップする必要があります。 一般に、履歴のクリアはストレージにとって重大なテストであることが多く、パフォーマンスに非常に大きな影響を与えることがよくあります。

キャッシュの問題を解決するにはどうすればよいですか?

ここでは特に Zabbix について説明します。 Zabbix では、最初と XNUMX 番目の呼び出しはキャッシュを使用して解決されます。

データの収集と処理 - すべてのデータを保存するために RAM を使用します。 これらのデータについてさらに詳しく説明します。

また、データベース側では、グラフやその他の主要な選択に対してキャッシュが行われます。

Zabbix サーバー自体の側でのキャッシュ: ConfigurationCache、ValueCache、HistoryCache、TrendsCache があります。 それは何ですか？

ConfigurationCache は、メトリクス、ホスト、データ項目、トリガーを保存するメインのキャッシュです。 前処理の処理、データの収集、どのホストからどのような頻度で収集するかなど、必要なすべての情報が含まれます。 データベースにアクセスして不要なクエリを作成しないように、これらはすべて ConfigurationCache に保存されます。 サーバーの起動後、このキャッシュを更新 (作成) し、(構成設定に応じて) 定期的に更新します。

Zabbix でのキャッシュ。 データ収集

ここでの図は非常に大きくなります。

このスキームの主なものは次のコレクターです。

これらはアセンブリ プロセスそのものであり、さまざまなタイプのアセンブリを担当するさまざまな「ポーラー」です。 icmp、ipmi、およびさまざまなプロトコルを介してデータを収集し、それをすべて前処理に転送します。

前処理履歴キャッシュ

また、計算されたデータ要素 (Zabbix に詳しい人は知っているでしょう)、つまり計算された集計データ要素がある場合は、それらを ValueCache から直接取得します。 埋め方は後ほど説明します。 これらすべてのコレクターは、ConfigurationCache を使用してジョブを受信し、前処理に渡します。

前処理では、ConfigurationCache を使用して前処理ステップを取得し、このデータをさまざまな方法で処理します。 バージョン 4.2 からは、プロキシに移動しました。 前処理自体がなかなか難しい操作なので、これは非常に便利です。 また、非常に大規模な Zabbix があり、多数のデータ要素があり、収集頻度が高い場合、作業が大幅に簡素化されます。

したがって、前処理を使用してこのデータを何らかの方法で処理した後、さらに処理するために HistoryCache に保存します。 これでデータ収集は終了です。 メインの工程に移ります。

ヒストリーシンサーの作品

Zabbix の主なプロセス (モノリシック アーキテクチャであるため) は履歴同期です。 これは、各データ要素、つまり各値のアトミックな処理を特に扱うメイン プロセスです。

• 値が来ます (HistoryCache から取得します)。
• Configuration syncer でチェックします。計算のトリガーがあるかどうか - それらを計算します。
  存在する場合 - 構成に従って必要に応じて、イベントを作成し、アラートを作成するためにエスカレーションを作成します。
• 後続の処理や集計のためのレコードのトリガー。 過去 XNUMX 時間などに集計した場合、この値は履歴テーブルに保存されないように ValueCache によって記憶されます。 したがって、ValueCache には、トリガーや計算要素などの計算に必要なデータが書き込まれます。
• 次に、履歴同期機能がすべてのデータをデータベースに書き込みます。
• データベースはそれらをディスクに書き込みます。これで処理プロセスが終了します。

データベース。 キャッシング

データベース側では、イベントに関するグラフやレポートを表示したい場合、さまざまなキャッシュがあります。 しかし、このレポートではそれらについては触れません。

MySQL の場合は、Innodb_buffer_pool と、同様に構成できるさまざまなキャッシュがあります。
しかし、主なものは次のとおりです。

• 共有バッファ;
• 効果的なキャッシュサイズ;
• 共有プール。

すべてのデータベースには、クエリによく必要となるデータを RAM に保存できる特定のキャッシュがあると述べました。 彼らはこのための独自の技術を持っています。

データベースのパフォーマンスについて

したがって、Zabbix サーバーがデータを収集して記録するという競争環境が存在します。 再起動すると、履歴から読み取り、ValueCache などに書き込みます。 ここでは、Web インターフェイス上に構築された Zabbix API を使用するスクリプトとレポートを作成できます。 Zabbix API はデータベースに入り、グラフ、レポート、またはある種のイベントや最近の問題のリストを取得するために必要なデータを受け取ります。

また、非常に人気のある視覚化ソリューションとして、ユーザーが使用している Grafana があります。 Zabbix API とデータベースの両方を介して直接ログインできます。 また、データを取得するために一定の競争が発生します。結果とテストの迅速な提供に準拠するには、データベースをより細かく、より適切に調整する必要があります。

履歴をクリアします。 Zabbix にはハウスキーパーがいます

Zabbix で使用される XNUMX 番目の呼び出しは、Housekeeper を使用した履歴のクリアです。 Housekeeper はすべての設定に従います。つまり、データ要素は、保存する期間 (日単位)、傾向を保存する期間、および変更のダイナミクスを示します。

TrendCache については触れませんでした。TrendCache はその場で計算します。データが到着し、それを XNUMX 時間集計し (ほとんどの場合、過去 XNUMX 時間の数値です)、量は平均/最小で、XNUMX 時間に XNUMX 回記録します。変化のダイナミクスの表 (「トレンド」) 。 「ハウスキーパー」は通常の選択を使用してデータベースを起動し、データベースからデータを削除しますが、これは常に効果的であるとは限りません。

効果がないことをどのように理解すればよいでしょうか？ 内部プロセスのパフォーマンス グラフで次の図を確認できます。

履歴同期機能は常にビジー状態です (赤いグラフ)。 そして一番上にある「赤い」グラフ。 これは、データベースが指定したすべての行を削除するのを開始して待機する「ハウスキーパー」です。

アイテム ID を取得しましょう。最後の 5 を削除する必要があります。 もちろんインデックスによる。 しかし、通常、データセットは非常に大きく、データベースは依然としてデータセットをディスクから読み取ってキャッシュに置きますが、これはデータベースにとって非常にコストのかかる操作です。 サイズによっては、特定のパフォーマンス上の問題が発生する可能性があります。

Housekeeper は簡単な方法で無効にできます。使い慣れた Web インターフェイスが用意されています。 管理全般の設定 (「ハウスキーパー」の設定) では、内部履歴と傾向のための内部ハウスキーピングを無効にします。 したがって、Housekeeper はこれを制御しなくなりました。

次に何ができるでしょうか？ それをオフにしたので、グラフは横ばいになりました...この場合、さらにどのような問題が発生する可能性がありますか? 何が役立つでしょうか？

パーティショニング（セクション化）

通常、これは、リストした各リレーショナル データベースで異なる方法で構成されます。 MySQL には独自のテクノロジーがあります。 ただし、PostgreSQL 10 と MySQL に関しては、全体的には非常に似ています。 もちろん、その実装方法やパフォーマンスへの影響については、内部的には多くの違いがあります。 ただし、一般に、新しいパーティションを作成すると、特定の問題が発生することもよくあります。

設定 (1 日に作成するデータの量) に応じて、通常は最小値が設定されます。これは 1 日/バッチで、「トレンド」、つまり変更のダイナミクスの場合は、XNUMX か月/新しいバッチです。 非常に大規模なセットアップがある場合は、これが変わる可能性があります。

セットアップのサイズについてすぐに言ってみましょう。5 秒あたり最大 5 の新しい値 (いわゆる nvps) - これは小規模な「セットアップ」とみなされます。 平均 – 25 秒あたり XNUMX ～ XNUMX の値。 上記はすでに大規模なインストールであり、データベースの非常に慎重な構成を必要とする非常に大規模なインストールです。

非常に大規模なインストールでは、1 日が最適ではない可能性があります。 私は個人的に、MySQL 上で 40 日あたり XNUMX ギガバイトのパーティションを見たことがあります (さらに多くのパーティションがあるかもしれません)。 これは非常に大量のデータであるため、いくつかの問題が発生する可能性があります。 それを減らす必要があります。

なぜパーティション分割が必要なのでしょうか?

Partitioning が提供するものは、誰もが知っていると思いますが、テーブルのパーティショニングです。 多くの場合、これらはディスク上の別個のファイルであり、スパン要求です。 通常のパーティション分割の一部である場合、XNUMX つのパーティションがより最適に選択されます。

特に、Zabbix の場合、範囲ごとに使用されます。つまり、タイムスタンプ (通常の数値、エポックの開始からの時間) が使用されます。 一日の始まりと終わりを指定します。これがパーティションです。 したがって、XNUMX 日前のデータを要求している場合、(大きなテーブルではなく) XNUMX つのファイルをキャッシュにロードして返すだけで済むため、データベースからすべてがより速く取得されます。

多くのデータベースでは、挿入 (XNUMX つの子テーブルへの挿入) も高速化されます。 今は抽象的に話していますが、こういうこともあり得ます。 多くの場合、パーティショニングが役立ちます。

NoSQL用のElasticsearch

最近、3.4 で NoSQL ソリューションを実装しました。 Elasticsearchに書き込む機能を追加しました。 特定の種類を書くことができます。数字または記号のいずれかを選択します。 文字列テキストがあるので、Elasticsearch にログを書き込むことができます... したがって、Web インターフェイスも Elasticsearch にアクセスします。 これは場合によってはうまく機能しますが、現時点では使用できます。

タイムスケールDB。 ハイパーテーブル

4.4.2 では、TimescaleDB のような XNUMX つのことに注意を払いました。 それは何ですか？ これは PostgreSQL の拡張機能です。つまり、ネイティブの PostgreSQL インターフェイスを備えています。 さらに、この拡張機能を使用すると、時系列データをより効率的に操作し、自動パーティショニングを行うことができます。 それはどのようなものか：

これはハイパーテーブルです。Timescale にはそのような概念があります。 これは作成したハイパーテーブルであり、チャンクが含まれています。 私の記憶が間違っていなければ、チャンクはパーティションであり、子テーブルです。 本当に効果的です。

TimescaleDB と PostgreSQL

TimescaleDB メーカーが保証しているように、クエリ、特に挿入の処理にはより正確なアルゴリズムが使用されており、データセット挿入のサイズが増加してもほぼ一定のパフォーマンスを維持できます。 つまり、Postgres が 200 億行を超えると、通常の Postgres は大幅に低下し始め、パフォーマンスが文字通りゼロになります。一方、Timescale を使用すると、どんな量のデータでもできるだけ効率的に挿入を行うことができます。

TimescaleDBをインストールするにはどうすればよいですか? それは簡単です！

それはドキュメントに記載されており、あらゆるパッケージからインストールできます...公式の Postgres パッケージに依存します。 手動でコンパイルできます。 たまたまデータベース用にコンパイルする必要がありました。

Zabbix では、単に拡張機能を有効にするだけです。 PostgresでExtentionを使っていた方は、Extentionを有効化して、使用しているZabbixデータベース用に作成するだけです。

そして最後のステップは…

タイムスケールDB。 履歴テーブルの移行

ハイパーテーブルを作成する必要があります。 これには、ハイパーテーブルの作成という特別な関数があります。 その中で、最初のパラメータは、このデータベースで必要なテーブルです (ハイパーテーブルを作成する必要があります)。

作成するフィールドと chunk_time_interval (これはチャンク (使用する必要があるパーティション) の間隔です。86 は 400 日です。

Migrate_data パラメーター: true に挿入すると、現在のデータがすべて事前に作成されたチャンクに移行されます。

私自身も merge_data を使用しましたが、データベースの規模にもよりますが、かなりの時間がかかります。 XNUMX テラバイト以上ありましたが、作成するのに XNUMX 時間以上かかりました。 場合によっては、テスト中に、テキスト (history_text) と文字列 (history_str) の履歴データを転送しないように削除しました。これらは私にとってあまり興味のないものでした。

そして、db_extention で最後の更新を行います。timescaledb をインストールして、データベース、特に Zabbix が db_extention の存在を認識できるようにします。 彼はそれをアクティブ化し、TimescaleDB に必要な「機能」を使用して、正しい構文とデータベースへのクエリを使用します。

サーバー構成

20台のサーバーを使用しました。 最初のサーバーは、16 プロセッサ、10.8 ギガバイトの RAM を備えたかなり小さな仮想マシンです。 Postgres XNUMXを構成しました。

オペレーティング システムは Debian、ファイル システムは xfs でした。 Zabbix 自体が使用するものを除いて、この特定のデータベースを使用するための最小限の設定を作成しました。 同じマシン上に Zabbix サーバー、PostgreSQL、およびロード エージェントがありました。

LoadableModule を使用してさまざまな結果を迅速に生成する 50 個のアクティブ エージェントを使用しました。 文字列や数値などを生成したのは彼らです。 データベースに大量のデータを詰め込みました。 当初、構成にはホストごとに 5 のデータ要素が含まれており、これを実際のセットアップにするために、ほぼ各データ要素にトリガーが含まれていました。 場合によっては、複数のトリガーを使用する必要があることもあります。

50 個のエージェントを使用する (さらに追加する) だけでなく、動的データ要素を使用して更新間隔を 4 秒に短縮することで、更新間隔と負荷自体を調整しました。

性能テスト。 PostgreSQL: 36 NVP

最初の起動、最初のセットアップは、このハードウェア上の純粋な PostreSQL 10 でした (35 秒あたり 200 の値)。 一般に、画面でわかるように、データの挿入にはほんの数秒かかります。SSD ドライブ (20 ギガバイト) ではすべてが良好で高速です。 ただ、XNUMX GB はすぐにいっぱいになってしまいます。

将来的には、このようなグラフがたくさん登場するでしょう。 これは、標準の Zabbix サーバー パフォーマンス ダッシュボードです。

最初のグラフは 35 秒あたりの値の数 (青、左上)、この場合は XNUMX の値です。 これ (中央上部) はビルド プロセスの読み込みで、これ (右上) は内部プロセス (履歴同期機能とハウスキーパー) の読み込みです。ここ (中央下部) はかなり長い間実行されています。

このグラフ (中央下) は、ValueCache の使用量、つまりトリガーに対する ValueCache のヒット数 (XNUMX 秒あたり数千の値) を示しています。 もう XNUMX つの重要なグラフは XNUMX 番目のグラフ (左下) で、先ほど説明した HistoryCache の使用法を示しています。これはデータベースに挿入する前のバッファです。

性能テスト。 PostgreSQL: 50 NVP

次に、同じハードウェアで負荷を 50 秒あたり 10 の値に増加しました。 Housekeeper がロードすると、計算により 2 ～ 3 秒で XNUMX 個の値が記録されました。 実際、次のスクリーンショットに示されている内容は次のとおりです。

「家政婦」はすでに仕事に支障をきたし始めていますが、一般的に、歴史を刻む罠師の負荷は依然として 60% のレベルにあります (20 番目のグラフ、右上)。 Housekeeper の実行中、HistoryCache はすでにアクティブに埋め始めています (左下)。 約半分ギガバイト、XNUMX% がいっぱいでした。

性能テスト。 PostgreSQL: 80 NVP

次に、80 秒あたり XNUMX の値に増やしました。

データ要素数は約 400 万、トリガー数は 280 万でした。 ご覧のとおり、インサートは歴史的なシンカー（30個ありました）の負荷という点ですでにかなり高かったです。 次に、ヒストリ シンカー、キャッシュなどのさまざまなパラメータを増やしました。このハードウェアでは、ヒストリ シンカーの負荷が最大値まで増加し始め、ほぼ「棚上げ」状態になりました。それに応じて、HistoryCache の負荷が非常に高くなりました。

この間ずっと、すべてのシステム パラメータ (プロセッサの使用状況、RAM) を監視し、ディスク使用率が最大であることを発見しました。このハードウェア、この仮想マシン上のこのディスクの最大容量に達しました。 「Postgres」は、そのような強度で非常に活発にデータをダンプし始め、ディスクには書き込みや読み取りを行う時間がなくなりました...

すでに 48 個のプロセッサと 128 ギガバイトの RAM を備えた別のサーバーを使用しました。

また、それを「調整」しました - 履歴同期器 (60 個) をインストールし、許容可能なパフォーマンスを達成しました。 実際、私たちは「棚上げ」ではありませんが、おそらくこれが生産性の限界であり、すでに何らかの対応が必要になっています。

性能テスト。 TimescaleDB: 80 NVP

私の主なタスクは、TimescaleDB を使用することでした。 各グラフは落ち込みを示しています。

これらの失敗はまさにデータ移行です。 その後、Zabbix サーバーでは、ご覧のとおり、履歴シンカーの読み込みプロファイルが大幅に変更されました。 これにより、ほぼ 3 倍の速さでデータを挿入でき、HistoryCache の使用量が少なくなるため、データは予定通りに配信されます。 繰り返しますが、80 秒あたり XNUMX の値はかなり高いレートです (もちろん、Yandex の場合ではありません)。 全体として、これはサーバーが XNUMX 台あるかなり大規模なセットアップです。

PostgreSQL パフォーマンス テスト: 120 NVP

次に、データ要素数の値を 125 万に増やし、XNUMX 秒あたり XNUMX という計算値を受け取りました。

そして、次のようなグラフが得られました。

原則として、これは動作するセットアップであり、かなり長期間動作する可能性があります。 しかし、1,5 テラバイトのディスクしか持っていなかったので、数日で使い切ってしまいました。 最も重要なことは、同時に新しいパーティションが TimescaleDB 上に作成されたことですが、これはパフォーマンスにはまったく影響されませんでした。これは MySQL については言えません。

通常、パーティションは夜間に作成されます。これは、通常、テーブルの挿入や操作がブロックされ、サービスの低下につながる可能性があるためです。 この場合はそうではありません！ 主なタスクは、TimescaleDB の機能をテストすることでした。 結果は次のような数字になりました: 120 秒あたり XNUMX 万の値。

コミュニティには次のような例もあります。

また、この人物は TimescaleDB をオンにし、io.weight を使用する際のプロセッサの負荷が軽減されました。 また、TimescaleDB の導入により、内部プロセス要素の使用も減少しました。 さらに、これらは通常のパンケーキ ディスク、つまり通常のディスク (SSD ではなく) 上の通常の仮想マシンです。

ディスクのパフォーマンスによって制限される小規模なセットアップの場合、私の意見では、TimescaleDB は非常に優れたソリューションです。 これにより、データベース用に高速なハードウェアに移行する前に作業を続けることができます。

モスクワでのカンファレンス、リガでのサミットなど、私たちのイベントに皆さんをご招待します。 テレグラム、フォーラム、IRC などのチャネルを使用してください。 ご質問がございましたら、私たちのデスクまでお越しください。何でもご相談いただけます。

聴衆の質問

聴衆からの質問 (以下、A): - TimescaleDB の構成が非常に簡単で、これほどパフォーマンスが向上するのであれば、おそらくこれを Postgres で Zabbix を構成するためのベスト プラクティスとして使用する必要がありますか? そして、このソリューションには落とし穴や欠点はありますか、それとも結局のところ、自分で Zabbix を作成することに決めた場合、Postgres を簡単に使用でき、Timescale をすぐにそこにインストールし、問題を考えずに使用できますか?

AG: – はい、これは良い推奨事項だと思います。TimescaleDB 拡張機能を備えた Postgres をすぐに使用してください。 すでに述べたように、この「機能」は実験的なものであるにもかかわらず、多くの良いレビューが寄せられています。 しかし、実際のテストでは、これが (TimescaleDB を使用した) 優れたソリューションであることが示されており、今後進化すると思います。 私たちはこの拡張機能がどのように開発されるかを監視しており、必要に応じて変更を加えます。

開発中であっても、私たちはそのよく知られた「機能」の XNUMX つに依存していました。それは、チャンクを少し異なる方法で操作することが可能でした。 しかし、次のリリースではそれが削除されたため、私たちはこのコードへの依存をやめなければなりませんでした。 多くのセットアップでこのソリューションを使用することをお勧めします。 MySQL を使用している場合... 平均的なセットアップでは、どのソリューションでも問題なく機能します。

A： – コミュニティからの最後のグラフには、「Housekeeper」を含むグラフがありました。

彼は働き続けた。 Housekeeper は TimescaleDB を使って何をしますか?

AG: – 今は確かなことは言えません – コードを見て、さらに詳しくお話します。 TimescaleDB クエリを使用してチャンクを削除するのではなく、何らかの方法でチャンクを集約します。 この技術的な質問にはまだ答える準備ができていません。 今日か明日のスタンドで詳細がわかります。

A： – Timescale での削除操作のパフォーマンスについて、同様の質問があります。
A (聴衆からの回答): – テーブルからデータを削除するとき、削除を介して行う場合は、テーブルを処理する必要があります。削除、クリーンアップ、将来のバキュームのためにすべてをマークする必要があります。 Timescale では、チャンクがあるため、ドロップできます。 ざっくり言うと、ビッグデータにあるファイルに「削除して！」と指示するだけです。

Timescale は、そのようなチャンクがもう存在しないことを単に理解します。 また、クエリ プランナーに統合されているため、フックを使用して選択やその他の操作で条件をキャッチし、このチャンクがもう存在しないことをすぐに理解します。「もうそこには行きません!」 (データは利用できません)。 それだけです！ つまり、テーブル スキャンはバイナリ ファイルの削除に置き換えられるため、高速です。

A： – 非 SQL のトピックについてはすでに触れました。 私の理解する限り、Zabbix は実際にデータを変更する必要はなく、これはすべてログのようなものです。 データを変更できないと同時に、はるかに高速に保存、蓄積、配布できる特殊なデータベースを使用することは可能でしょうか。たとえば、Kafka に似た Clickhouse などでしょうか? Kafka もログです。 何とかそれらを統合することは可能でしょうか？

AG: ●荷降ろしが可能です。 バージョン 3.4 以降、特定の「機能」が追加されました。すべての履歴ファイル、イベント、その他すべてをファイルに書き込むことができます。 そして、何らかのハンドラーを使用して他のデータベースに送信します。 実際、多くの人が再作業してデータベースに直接書き込みます。 実行中に、履歴シンカーはこれらすべてをファイルに書き込み、これらのファイルを回転するなどして、これを Clickhouse に転送できます。 計画については言えませんが、おそらく NoSQL ソリューション (Clickhouse など) のさらなるサポートが継続されるでしょう。

A： – 一般的に、postgres を完全に削除できることがわかりましたか?

AG: – もちろん、Zabbix で最も難しい部分は履歴テーブルであり、最も多くの問題やイベントが発生します。 この場合、イベントを長期間保存せず、傾向を含む履歴を他の高速ストレージに保存すれば、通常は問題ないと思います。

A： – たとえば、Clickhouse に切り替えた場合、すべてがどのくらい速く動作するかを見積もることはできますか?

AG: – テストしていません。 Clickhouse には独自のインターフェースがあるため、少なくとも同じ数字は非常に簡単に達成できると思いますが、確実なことは言えません。 テストした方が良いです。 それはすべて、ホストの数などの構成によって異なります。 挿入することは XNUMX つのことですが、このデータを Grafana などで取得する必要もあります。

A： – つまり、私たちは対等な戦いについて話しているのであって、これらの高速データベースの大きな利点について話しているわけではないということですか？

AG: – 統合すると、より正確なテストが行​​われると思います。

A： – 古き良きRRDはどこへ行ったのでしょうか？ SQL データベースに切り替えた理由は何ですか? 当初、すべてのメトリクスは RRD で収集されました。

AG: – Zabbix には、おそらく非常に古いバージョンで RRD がありました。 SQL データベースは常に存在していました。これは古典的なアプローチです。 古典的なアプローチは MySQL や PostgreSQL です (これらは非常に長い間存在していました)。 SQL データベースと RRD データベースに共通のインターフェイスを使用したことはほとんどありませんでした。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com