VictoriaMetrics で Go を最適化します。 アレクサンダー・ヴァリャルキン

Alexander Valyalkin による 2019 年後半のレポート「VictoriaMetrics における Go の最適化」の書き起こしを読むことをお勧めします。

ビクトリアメトリクス — 時系列の形式でデータを保存および処理するための高速でスケーラブルな DBMS (レコードは、たとえば、センサーのステータスの定期的なポーリングやデータの収集を通じて取得される、時間とこの時間に対応する一連の値を形成します)メトリクス）。

このレポートのビデオへのリンクは次のとおりです - https://youtu.be/MZ5P21j_HLE

スライド

あなた自身について教えてください。 私はアレクサンダー・ヴァリャルキンです。 ここ 私のGitHubアカウント。 私は Go とパフォーマンスの最適化に情熱を持っています。 私は役に立つライブラリとあまり役に立たないライブラリをたくさん書きました。 どちらかで始まります fast、または quick 接頭辞。

私は現在 VictoriaMetrics に取り組んでいます。 それは何ですか、そして私はそこで何をしているのでしょうか？ このプレゼンテーションではこれについて説明します。

報告書の概要は以下のとおりです。

• まず、VictoriaMetrics とは何かについて説明します。
• それでは時系列を説明していきます。
• 次に、時系列データベースがどのように機能するかを説明します。
• 次に、データベースのアーキテクチャ、つまり構成要素について説明します。
• 次に、VictoriaMetrics の最適化に移りましょう。 これは、逆インデックスの最適化と、Go のビットセット実装の最適化です。

聴衆の中で VictoriaMetrics が何であるかを知っている人はいますか? いや、もう知っている人も多いでしょう。 良いニュースです。 知らない人のために説明すると、これは時系列データベースです。 これは、ClickHouse アーキテクチャと、ClickHouse 実装の詳細に基づいています。 たとえば、MergeTree では、利用可能なすべてのプロセッサ コアでの並列計算と、プロセッサ キャッシュに配置されたデータ ブロックの処理によるパフォーマンスの最適化が可能です。

VictoriaMetrics は、他の時系列データベースよりも優れたデータ圧縮を提供します。

垂直方向に拡張できます。つまり、XNUMX 台のコンピューターにプロセッサーや RAM を追加できます。 VictoriaMetrics は、これらの利用可能なリソースをうまく活用し、直線的な生産性を向上させます。

VictoriaMetrics は水平方向にも拡張できます。つまり、VictoriaMetrics クラスターにノードを追加すると、パフォーマンスがほぼ直線的に向上します。

ご想像のとおり、VictoriaMetrics は高速なデータベースです。他のデータベースを作成できないからです。 それは Go で書かれているので、このミートアップでそれについて話します。

時系列とは何かを誰が知っていますか? 彼はまた多くの人を知っています。 時系列とは一連のペアです (timestamp, значение)ここでは、これらのペアが時間順に並べ替えられています。 値は浮動小数点数 - float64 です。

各時系列はキーによって一意に識別されます。 この鍵は何で構成されていますか? これは、空ではないキーと値のペアのセットで構成されます。

以下は時系列の例です。 このシリーズのキーはペアのリストです。 __name__="cpu_usage" はメトリクスの名前です。 instance="my-server" - これは、このメトリクスが収集されるコンピュータです。 datacenter="us-east" - これは、このコンピュータが置かれているデータ センターです。

最終的に、XNUMX つのキーと値のペアで構成される時系列名が得られました。 このキーはペアのリストに対応します (timestamp, value). t1, t3, t3, ..., tN - これらはタイムスタンプです。 10, 20, 12, ..., 15 — 対応する値。 これは、特定のシリーズの特定の時点での CPU 使用率です。

時系列はどこで使用できますか? 誰か何かアイデアはありますか？

• DevOpsでは、CPU、RAM、ネットワーク、RPS、エラー数などを測定できます。
• IoT - 温度、圧力、地理座標などを測定できます。
• 金融も可能です。あらゆる種類の株や通貨の​​価格を監視できます。
• さらに、時系列は工場の生産プロセスの監視にも使用できます。 VictoriaMetrics を使用して風力タービンやロボットを監視するユーザーもいます。
• 時系列は、さまざまなデバイスのセンサーから情報を収集するのにも役立ちます。 たとえば、エンジンの場合。 タイヤの空気圧を測定するため。 速度、距離の測定用。 ガソリン消費量の計測などに。
• 時系列は航空機の監視にも使用できます。 各航空機には、航空機の状態に関するさまざまなパラメータの時系列を収集するブラック ボックスがあります。 時系列は航空宇宙産業でも使用されます。
• ヘルスケアとは血圧や脈拍などです。

忘れている応用例は他にもあるかもしれませんが、現代社会では時系列が積極的に使われているということをご理解いただければ幸いです。 そしてその使用量は年々増加しています。

なぜ時系列データベースが必要なのでしょうか? 時系列の保存に通常のリレーショナル データベースを使用できないのはなぜですか?

通常、時系列には大量の情報が含まれており、従来のデータベースに保存して処理することが困難であるためです。 そこで、時系列に特化したデータベースが登場しました。 ポイントを効率よく貯められる拠点です (timestamp, value) 指定されたキーを使用して。 これらは、キー、単一のキーと値のペア、複数のキーと値のペア、または正規表現によって保存されたデータを読み取るための API を提供します。 たとえば、アメリカのデータセンターにあるすべてのサービスの CPU 負荷を調べたい場合は、この疑似クエリを使用する必要があります。

通常、時系列データベースは、時系列 SQL があまり適していないため、特殊なクエリ言語を提供します。 SQL をサポートするデータベースもありますが、あまり適していません。 などのクエリ言語 PromQL, 流入QL, Flux, Q。 誰かがこれらの言語の少なくとも XNUMX つを聞いたことがあることを願っています。 PromQL について聞いたことがある人は多いでしょう。 これは Prometheus クエリ言語です。

VictoriaMetrics を例として使用した最新の時系列データベース アーキテクチャは次のとおりです。

XNUMX つの部分から構成されます。 これは、転置インデックスのストレージと時系列値のストレージです。 これらのリポジトリは分離されています。

新しいレコードがデータベースに到着すると、まず転置インデックスにアクセスして、指定されたセットの時系列識別子を見つけます。 label=value 特定のメトリクスに対して。 この識別子を見つけて、その値をデータ ストアに保存します。

TSDB からデータを取得するリクエストが来ると、まず転置インデックスに移動します。 全てを手に入れましょう timeseries_ids このセットに一致するレコード label=value。 次に、データ ウェアハウスから必要なデータをすべて取得し、次のようにインデックス付けします。 timeseries_ids.

時系列データベースが受信した選択クエリを処理する方法の例を見てみましょう。

• まず第一に、彼女はすべてを手に入れます timeseries_ids 指定されたペアを含む転置インデックスから label=value、または指定された正規表現を満たす。
• 次に、見つかったデータ ポイントについて、指定された時間間隔でデータ ストレージからすべてのデータ ポイントを取得します。 timeseries_ids.
• この後、データベースはユーザーの要求に応じて、これらのデータ ポイントに対していくつかの計算を実行します。 そしてその後、答えを返します。

このプレゼンテーションでは、最初の部分について説明します。 これは検索です timeseries_ids 転置インデックスによって。 第二部、第三部については後ほどご覧いただけます VictoriaMetrics ソースまたは、他のレポートを準備するまでお待ちください:)

転置インデックスに移りましょう。 多くの人はこれは簡単だと思うかもしれません。 転置インデックスとは何か、そしてそれがどのように機能するのかを誰が知っているでしょうか? ああ、もう人はそれほど多くありません。 それが何であるかを理解してみましょう。

実は簡単なんです。 これは、キーを値にマッピングする単なる辞書です。 鍵とは何ですか? このカップル label=valueどこ label и value - これらは線です。 そして値はセットです timeseries_ids、指定されたペアが含まれます label=value.

逆索引により、すべてをすばやく見つけることができます timeseries_idsを与えた label=value.

すぐに見つけることもできます timeseries_ids 複数のペアの時系列 label=value、またはカップル向け label=regexp。 これはどうして起こるのでしょうか? 集合の交点を見つけることによって timeseries_ids 各ペアごとに label=value.

転置インデックスのさまざまな実装を見てみましょう。 最も単純な単純な実装から始めましょう。 彼女はこんな感じです。

機能 getMetricIDs 文字列のリストを取得します。 各行には次の内容が含まれます label=value。 この関数はリストを返します metricIDs.

使い方？ ここにはグローバル変数という名前があります。 invertedIndex。 これは普通の辞書です(map)、文字列をスライス整数にマップします。 行には以下が含まれます label=value.

関数実装: get metricIDs 初めて label=value、その後、他のすべてを実行します label=value、分かりました metricIDs 彼らのために。 そして関数を呼び出します intersectInts、これについては後述します。 そして、この関数はこれらのリストの共通部分を返します。

ご覧のとおり、転置インデックスの実装はそれほど複雑ではありません。 しかし、これは単純な実装です。 どのような欠点がありますか? 単純な実装の主な欠点は、そのような逆インデックスが RAM に格納されることです。 アプリケーションを再起動すると、このインデックスは失われます。 このインデックスはディスクに保存されません。 このような転置インデックスはデータベースには適さない可能性があります。

XNUMX 番目の欠点もメモリに関連しています。 転置インデックスは RAM に収まる必要があります。 RAM のサイズを超えると、明らかにメモリ不足エラーが発生します。 そしてプログラムは動作しません。

この問題は、次のような既製のソリューションを使用して解決できます。 レベルDBまたは ロックスDB.

つまり、XNUMX つの操作を迅速に実行できるデータベースが必要です。

• 最初の操作は録音です ключ-значение このデータベースに。 彼女はこれを非常に素早く行います。 ключ-значение は任意の文字列です。
• XNUMX 番目の操作は、指定されたキーを使用した値のクイック検索です。
• XNUMX 番目の操作は、指定されたプレフィックスによるすべての値の迅速な検索です。

LevelDB と RocksDB - これらのデータベースは Google と Facebook によって開発されました。 最初に登場したのは LevelDB です。 その後 Facebook の人たちが LevelDB を採用して改良を始め、RocksDB を作りました。 現在、RocksDB や MySQL に転送されたものも含め、ほぼすべての内部データベースが Facebook 内の RocksDB 上で動作します。 彼らは彼に名前を付けました マイロックス.

転置インデックスは、LevelDB を使用して実装できます。 どうやってするの？ キーとして保存 label=value。 そして、値はペアが存在する時系列の識別子です label=value.

特定のペアに関する時系列が多数ある場合 label=valueの場合、このデータベースには同じキーと異なるキーを持つ行が多数存在します。 timeseries_ids。 すべてのリストを取得するには timeseries_ids、これで始まります label=prefix、このデータベースが最適化された範囲スキャンを実行します。 つまり、次で始まるすべての行を選択します。 label=prefix そして必要なものを手に入れる timeseries_ids.

Go でどのようになるかを示すサンプル実装を次に示します。 転置インデックスがあります。 これがLevelDBです。

関数は単純な実装の場合と同じです。 単純な実装をほぼ XNUMX 行ずつ繰り返します。 唯一のポイントは、次のことに目を向けるのではなく、 map 転置インデックスにアクセスします。 最初のすべての値を取得します label=value。 次に、残りのすべてのペアを調べます label=value そして、それらに対応する metricID のセットを取得します。 それから交差点を見つけます。

すべてがうまくいっているように見えますが、この解決策には欠点があります。 VictoriaMetrics は当初、LevelDB に基づいて転置インデックスを実装しました。 しかし、結局は諦めざるを得ませんでした。

なぜ？ LevelDB は単純な実装よりも遅いためです。 単純な実装では、指定されたキーを指定すると、スライス全体がすぐに取得されます。 metricIDs。 これは非常に高速な操作です。スライス全体が使用できる状態になります。

LevelDB では、関数が呼び出されるたびに GetValues で始まるすべての行を確認する必要があります label=value。 そして各行の値を取得します timeseries_ids。 そのような timeseries_ids これらのスライスを集めます timeseries_ids。 明らかに、これは単にキーによって通常のマップにアクセスするよりもはるかに遅くなります。

1 番目の欠点は、LevelDB が C で書かれていることです。Go からの C 関数の呼び出しはそれほど高速ではありません。 数百ナノ秒かかります。 これはそれほど高速ではありません。go で記述された通常の関数呼び出しと比較すると 5 ～ XNUMX ナノ秒かかり、パフォーマンスの差は数十倍になります。 VictoriaMetrics にとって、これは致命的な欠陥でした :)

そこで私は独自の転置インデックスの実装を作成しました。 そして彼は彼女に電話した マージセット.

Mergeset は MergeTree データ構造に基づいています。 このデータ構造は ClickHouse から借用したものです。 明らかに、高速検索のためにマージセットを最適化する必要があります。 timeseries_ids 指定されたキーに従って。 Mergeset はすべて Go で書かれています。 ご覧いただけます GitHub 上の VictoriaMetrics ソース。 マージセットの実装はフォルダー内にあります /lib/マージセット。 そこで何が起こっているのかを理解してみることができます。

マージセット API は、LevelDB および RocksDB に非常に似ています。 つまり、新しいレコードをそこにすばやく保存し、指定されたプレフィックスによってレコードをすばやく選択できるようになります。

マージセットの欠点については後ほど説明します。 次に、運用環境で転置インデックスを実装するときに VictoriaMetrics でどのような問題が発生したかについて説明します。

なぜ彼らは生じたのでしょうか？

一つ目の理由は、解約率の高さです。 ロシア語に翻訳すると、これは時系列の頻繁な変更です。 これは、時系列が終了して新しい時系列が始まるとき、または多くの新しい時系列が始まるときです。 そして、これは頻繁に起こります。

4 番目の理由は、時系列の数が多いことです。 モニタリングが普及し始めた当初、時系列の数は少なかった。 たとえば、コンピュータごとに、CPU、メモリ、ネットワーク、ディスクの負荷を監視する必要があります。 コンピューターごとに 100 つの時系列。 400 台のコンピューターと XNUMX の時系列があるとします。 これはごくわずかです。

時間が経つにつれて、人々はより詳細な情報を測定できることに気づきました。 たとえば、プロセッサ全体の負荷ではなく、各プロセッサ コアの負荷を個別に測定します。 40 個のプロセッサ コアがある場合、プロセッサ負荷を測定するための時系列は 40 倍になります。

しかし、それだけではありません。 各プロセッサ コアは、アイドル時にアイドルなどの複数の状態を持つことができます。 また、ユーザー空間、カーネル空間、その他の状態でも動作します。 そして、そのような各状態は、個別の時系列として測定することもできます。 これにより、行数がさらに 7 ～ 8 倍増加します。

40 つのメトリックから、8 台のコンピューターに対して 320 x 100 = 32 のメトリックが得られました。 000 を掛けると、400 ではなく XNUMX になります。

その後、Kubernetes が登場しました。 そして、Kubernetes はさまざまなサービスをホストできるため、事態はさらに悪化しました。 Kubernetes の各サービスは多数のポッドで構成されます。 そして、これらすべてを監視する必要があります。 さらに、サービスの新しいバージョンを継続的に展開しています。 新しいバージョンごとに、新しい時系列を作成する必要があります。 その結果、時系列の数が指数関数的に増加し、高カーディナリティと呼ばれる時系列の数が多くなるという問題に直面します。 VictoriaMetrics は、他の時系列データベースと比較して、これにうまく対処します。

高い解約率について詳しく見てみましょう。 本番環境での高いチャーンレートの原因は何ですか? ラベルやタグの意味の一部は常に変化するためです。

たとえば、Kubernetes には次のような概念があります。 deploymentつまり、アプリケーションの新しいバージョンがロールアウトされたときです。 何らかの理由で、Kubernetes 開発者はラベルにデプロイメント ID を追加することにしました。

これは何につながりましたか? さらに、新しい展開が行われるたびに、古い時系列はすべて中断され、代わりに新しい時系列が新しいラベル値で始まります。 deployment_id。 このような行は数十万、さらには数百万も存在する可能性があります。

これらすべてについて重要なことは、時系列の総数は増加しますが、現在アクティブでデータを受信して​​いる時系列の数は一定のままであるということです。 この状態を高解約率といいます。

高いチャーン レートの主な問題は、特定の時間間隔にわたる特定のラベル セットのすべての時系列で一定の検索速度を確保することです。 通常、これは過去 XNUMX 時間または最後の日の時間間隔です。

この問題を解決するにはどうすればよいでしょうか? これが最初のオプションです。 これは、転置インデックスを時間の経過とともに独立した部分に分割するためです。 つまり、ある程度の時間が経過すると、現在の逆インデックスの処理が終了します。 そして、新しい転置インデックスを作成します。 別の時間間隔が経過し、次から次へと作成されます。

そして、これらの反転インデックスからサンプリングすると、指定された間隔内に収まる一連の反転インデックスが見つかります。 そして、それに応じて、そこから時系列の ID を選択します。

これにより、指定された間隔内に収まらない部分を確認する必要がなくなるため、リソースが節約されます。 つまり、通常、過去 XNUMX 時間のデータを選択した場合、それ以前の時間間隔についてはクエリをスキップします。

この問題を解決するには別のオプションがあります。 これは、その日に発生した時系列の ID の個別のリストを毎日保存するためです。

前のソリューションに対するこのソリューションの利点は、時間が経っても消えない時系列情報を複製しないことです。 それらは常に存在し、変化しません。

欠点は、このようなソリューションは実装がより難しく、デバッグがより困難であることです。 そして、VictoriaMetrics はこのソリューションを選択しました。 これが歴史的に起こったことです。 このソリューションも、以前のソリューションと比較して優れたパフォーマンスを発揮します。 このソリューションは、変化しない、つまり時間の経過とともに消失しない時系列のデータを各パーティションで複製する必要があるという事実により実装されませんでした。 VictoriaMetrics は主にディスク領域の消費に対して最適化されており、以前の実装ではディスク領域の消費が悪化していました。 ただし、この実装はディスク領域の消費を最小限に抑えるのに適しているため、選択されました。

私は彼女と戦わなければならなかった。 苦労したのは、この実装でもさらに大きな数値を選択する必要があることです。 timeseries_ids 転置インデックスが時間パーティション化されている場合よりも、データの場合は異なります。

この問題をどのように解決したのでしょうか? 私たちは、各転置インデックス エントリに XNUMX つの識別子の代わりに複数の時系列識別子を格納するという独自の方法でこの問題を解決しました。 つまり、鍵を持っています label=value、すべての時系列で発生します。 そして今、私たちはいくつかを保存しています timeseries_ids XNUMXつのエントリで。

ここに例を示します。 以前は N 個のエントリがありましたが、現在は他のすべてと同じプレフィックスを持つエントリが XNUMX つあります。 前のエントリの場合、値にはすべての時系列 ID が含まれています。

これにより、転置インデックスの走査速度を最大10倍まで高速化することができました。 また、文字列を保存するようになったので、キャッシュのメモリ消費量を減らすことができました。 label=value N 回一緒にキャッシュに入れるのは XNUMX 回だけです。 また、タグやラベルに長い行を格納すると、この行が大きくなる可能性があり、Kubernetes はそこに押し込むことを好みます。

転置インデックスでの検索を高速化するためのもう XNUMX つのオプションはシャーディングです。 XNUMX つではなく複数の逆インデックスを作成し、それらの間でキーによってデータをシャーディングします。 これはセットです key=value 蒸気。 つまり、複数の独立した逆インデックスを取得し、複数のプロセッサ上で並行してクエリを実行できます。 以前の実装では、シングルプロセッサ モードでの動作のみが許可されていました。つまり、XNUMX つのコアのみでデータをスキャンできました。 このソリューションを使用すると、ClickHouse が好んで行うように、複数のコアのデータを一度にスキャンできます。 これが私たちが実装する予定のものです。

さて、羊の話、交差点関数に戻りましょう。 timeseries_ids。 どのような実装があるかを考えてみましょう。 この機能を使用すると、 timeseries_ids 特定のセットに対して label=value.

最初のオプションは単純な実装です。 XNUMX つのネストされたループ。 ここで関数の入力を取得します intersectInts XNUMXつのスライス - a и b。 出力では、これらのスライスの交差部分が返されるはずです。

素朴な実装は次のようになります。 スライスからのすべての値を反復処理します a、このループ内でスライスのすべての値を調べます。 b。 そしてそれらを比較します。 それらが一致する場合、交差点が見つかったことになります。 そしてそれを保存します result.

デメリットは何ですか? 二次関数の複雑さが主な欠点です。 たとえば、ディメンションがスライスの場合、 a и b 一度に XNUMX 万件の場合、この関数は決して答えを返しません。 なぜなら、XNUMX兆回の反復を行う必要があるからで、これは現代のコンピューターでもかなりの回数です。

XNUMX 番目の実装はマップに基づいています。 地図を作成します。 スライスからのすべての値をこのマップに入れます a。 次に、別のループでスライスを処理します。 b。 そして、この値がスライスからのものであるかどうかを確認します b 地図で。 存在する場合は、結果に追加します。

メリットは何ですか? 利点は、線形の複雑さだけが存在することです。 つまり、スライスが大きい場合、関数はより高速に実行されます。 2 万サイズのスライスの場合、この関数は XNUMX 万回の反復で実行されます (前の関数の反復回数は XNUMX 兆回)。

欠点は、この関数がこのマップを作成するためにより多くのメモリを必要とすることです。

XNUMX 番目の欠点は、ハッシュ化のオーバーヘッドが大きいことです。 この欠点はあまり明らかではありません。 また、私たちにとってもそれはあまり明らかではなかったので、VictoriaMetrics では当初、交差の実装はマップを介していました。 しかし、プロファイリングの結果、メイン プロセッサの時間がマップへの書き込みと、このマップ内の値の存在の確認に費やされていることがわかりました。

なぜこれらの場所で CPU 時間が無駄になるのでしょうか? Go はこれらの行に対してハッシュ操作を実行するためです。 つまり、HashMap 内の特定のインデックスにあるキーにアクセスするために、キーのハッシュを計算します。 ハッシュ計算操作は数十ナノ秒で完了します。 VictoriaMetrics ではこれが遅いです。

このケース専用に最適化されたビットセットを実装することにしました。 XNUMX つのスライスの交差部分は次のようになります。 ここでビットセットを作成します。 最初のスライスから要素を追加します。 次に、XNUMX 番目のスライスにこれらの要素が存在するかどうかを確認します。 そしてそれらを結果に追加します。 つまり、前の例とほとんど変わりません。 ここで唯一のことは、マップへのアクセスをカスタム関数に置き換えたことです。 add и has.

一見すると、以前に標準マップが使用され、その後他の関数が呼び出された場合、これは動作が遅くなるはずのように見えますが、プロファイリングによると、VictoriaMetrics の場合、これは標準マップよりも 10 倍高速に動作します。

さらに、マップ実装と比較して使用するメモリが大幅に少なくなります。 ここには XNUMX バイトの値ではなくビットを保存しているためです。

この実装の欠点は、それほど明白ではなく、自明ではないことです。

多くの人が気づいていないもう XNUMX つの欠点は、この実装が場合によってはうまく機能しない可能性があることです。 つまり、VictoriaMetrics 時系列 ID の交差という特定のケースに対して最適化されます。 すべてのケースに適しているというわけではありません。 間違って使用すると、パフォーマンスは向上しませんが、メモリ不足エラーが発生し、パフォーマンスが低下します。

この構造の実装を考えてみましょう。 ご覧になりたい場合は、VictoriaMetrics ソースのフォルダーにあります。 lib/uint64set。 これは、VictoriaMetrics のケースに特化して最適化されています。 timeseries_id は 64 ビット値で、最初の 32 ビットは基本的に一定で、最後の 32 ビットのみが変化します。

このデータ構造はディスクには保存されず、メモリ内でのみ動作します。

ここにその API があります。 それほど複雑ではありません。 この API は、VictoriaMetrics の特定の使用例に合わせて特別に調整されています。 つまり、ここには不要な機能はありません。 VictoriaMetrics によって明示的に使用される関数を次に示します。

機能があります add、新しい値を追加します。 機能があります has、新しい値をチェックします。 そして機能があります del、値を削除します。 ヘルパー機能があります len、セットのサイズを返します。 関数 clone クローンがたくさんある。 そして機能 appendto このセットをスライスに変換します timeseries_ids.

このデータ構造の実装は次のようになります。 set には XNUMX つの要素があります。

• ItemsCount は、セット内の要素の数をすばやく返すヘルパー フィールドです。 この補助フィールドなしでも可能ですが、VictoriaMetrics はアルゴリズムでビットセットの長さを頻繁にクエリするため、ここに追加する必要がありました。

• XNUMX 番目のフィールドは buckets。 これは構造の一部です bucket32。 各構造体には hi 分野。 これらは上位 32 ビットです。 そしてXNUMXつのスライス - b16his и buckets の bucket16 構造物。

16 ビット構造の 64 番目の部分の上位 16 ビットがここに格納されます。 ここでは、各バイトの下位 XNUMX ビットのビットセットが保存されます。

Bucket64 配列で構成されます uint64。 長さはこれらの定数を使用して計算されます。 XNUMXつで bucket16 最大まで保存できる 2^16=65536 少し。 これを 8 で割ると、8 キロバイトになります。 もう一度8で割ると1000です uint64 意味。 あれは Bucket16 – これは 8 キロバイトの構造です。

新しい値を追加するためのこの構造のメソッドの XNUMX つがどのように実装されるかを見てみましょう。

それはすべてから始まります uint64 意味。 上位 32 ビットを計算し、下位 32 ビットを計算します。 すべてを見てみましょう buckets。 各バケットの上位 32 ビットと追加される値を比較します。 そしてそれらが一致する場合、関数を呼び出します add 構造体 b32 内 buckets。 そこに下位 32 ビットを追加します。 そしてそれが戻った場合 true、その場合、これは、そのような値をそこに追加しましたが、そのような値は存在しなかったことを意味します。 戻ってきたら falseであれば、そのような意味はすでに存在していました。 次に、構造内の要素の数を増やします。

必要なものが見つからない場合 bucket 必要なhi-valueを指定して関数を呼び出します。 addAlloc、新しいものが生成されます bucket、バケット構造に追加します。

これが関数の実装です b32.add。 これは以前の実装と似ています。 最上位 16 ビットと最下位 16 ビットを計算します。

次に、上位 16 ビットをすべて調べます。 一致するものを見つけます。 一致するものがあれば、add メソッドを呼び出します。これについては次のページで検討します。 bucket16.

そして、これが最も低いレベルであり、可能な限り最適化する必要があります。 計算します uint64 スライスビットのID値と bitmask。 これは、特定の 64 ビット値のマスクであり、このビットの存在を確認したり、設定したりするために使用できます。 このビットが設定されているかどうかを確認して設定し、存在を返します。 これは私たちの実装であり、時系列の交差する ID の操作を従来のマップと比較して 10 倍高速化することができました。

この最適化に加えて、VictoriaMetrics には他にも多くの最適化があります。 これらの最適化のほとんどは、実稼働環境でコードをプロファイリングした後に理由があって追加されました。

これが最適化の主なルールです。ここにボトルネックがあると仮定して最適化を追加しないでください。ボトルネックが存在しないことが判明する可能性があるためです。 通常、最適化によりコードの品質が低下します。 したがって、これが実際のデータになるように、プロファイリング後、できれば本番環境でのみ最適化する価値があります。 興味のある人は、VictoriaMetrics のソース コードを見て、そこにある他の最適化を探索してください。

ビットセットについて質問があります。 C++ ベクトル ブール実装と非常によく似ており、最適化されたビットセットです。 そこから実装したんですか？

いいえ、そこからではありません。 このビットセットを実装するときは、VictoriaMetrics で使用されるこれらの ID 時系列の構造に関する知識が参考になりました。 そしてその構造は、上位 32 ビットが基本的に一定であるようなものです。 下位 32 ビットは変更される可能性があります。 ビットが低いほど、変更される頻度が高くなります。 したがって、この実装はこのデータ構造に対して特に最適化されています。 私の知る限り、C++ 実装は一般的なケースに最適化されています。 一般的なケースに対して最適化しても、特定のケースに対しては最適ではないことを意味します。

アレクセイ・ミロヴィッド氏のレポートも見ることをお勧めします。 約 32 か月前、彼は ClickHouse における特定の専門分野の最適化について話しました。 彼は、一般的なケースでは、C++ 実装またはその他の実装は、病院で平均的に適切に機能するように調整されているとだけ述べています。 これは、上位 XNUMX ビットがほぼ一定であることがわかっている、私たちのような知識に特化した実装よりもパフォーマンスが低下する可能性があります。

XNUMX番目の質問があります。 InfluxDB との根本的な違いは何ですか?

多くの基本的な違いがあります。 パフォーマンスとメモリ消費量の点で、InfluxDB のテストでは、カーディナリティの高い時系列が多数 (たとえば数百万個) ある場合、その時系列のメモリ消費量が 10 倍になることが示されています。 たとえば、VictoriaMetrics は 1 万のアクティブ行ごとに 10 GB を消費しますが、InfluxDB は XNUMX GB を消費します。 それは大きな違いです。

XNUMX 番目の基本的な違いは、InfluxDB には、Flux と InfluxQL という奇妙なクエリ言語があることです。 これらは、時系列を扱うにはあまり便利ではありません。 PromQL、VictoriaMetrics によってサポートされています。 PromQL は Prometheus のクエリ言語です。

そしてもう XNUMX つの違いは、InfluxDB には少し奇妙なデータ モデルがあり、各行に異なるタグのセットを持つ複数のフィールドを格納できることです。 これらの行はさらにさまざまなテーブルに分割されます。 これらの追加の複雑さにより、このデータベースを使用した後続の作業が複雑になります。 サポートしたり理解したりするのは難しいです。

VictoriaMetrics ではすべてがはるかにシンプルです。 そこでは、各時系列が Key-Value になります。 値は点の集合です - (timestamp, value)、そしてキーはセットです label=value。 フィールドと測定の間に分離はありません。 私の知る限り、異なる行間の計算がまだ実装されていない InfluxDB とは異なり、任意のデータを選択して結合、加算、減算、乗算、除算を行うことができます。 実装できたとしても、コードをたくさん書かないといけないので大変です。

明確な質問があります。 あなたが話したある種の問題、つまりこの転置インデックスがメモリに収まらないため、そこでパーティション化が行われているということを正しく理解しましたか?

まず、標準的な Go マップ上での転置インデックスの単純な実装を示しました。 この逆索引はディスクに保存されないため、この実装はデータベースには適していません。データベースは、再起動時にこのデータが利用可能な状態のままであるようにディスクに保存する必要があります。 この実装では、アプリケーションを再起動すると、転置インデックスが消えます。 そして、すべてのデータが見つからなくなるため、アクセスできなくなります。

こんにちは！ ご報告ありがとうございます！ 私の名前はパベルです。 ワイルドベリー出身です。 いくつか質問があります。 質問 2。 アプリケーションのアーキテクチャを構築するときに別の原則を選択し、時間をかけてデータをパーティション分割していたら、おそらく、XNUMX つのパーティションに XNUMX つのパーティションのデータが含まれているという事実のみに基づいて、検索時にデータを交差できただろうと思いますか?期間、つまり XNUMX つの時間間隔内であれば、ピースが異なる方法で分散しているという事実を心配する必要はありません。 質問 XNUMX - ビットセットやその他すべてを使用して同様のアルゴリズムを実装しているため、プロセッサ命令を使用しようとした可能性がありますか? おそらくそのような最適化を試したことがあるでしょうか?

XNUMXつ目はすぐに答えます。 まだその段階には達していません。 しかし、必要であれば、そこに行きます。 そして最初の質問は何でしたか？

XNUMX つのシナリオについて説明しました。 そして、より複雑な実装を備えた XNUMX 番目のものを選択したと述べています。 そして彼らは、データが時間によって分割される最初の方法を好みませんでした。

はい。 最初のケースでは、各パーティションに、これらすべてのパーティションに続く時系列の重複データを保存する必要があるため、インデックスの総量は大きくなります。 また、時系列のチャーン レートが小さい場合、つまり同じ系列が常に使用されている場合、最初のケースでは、XNUMX 番目のケースと比較して、占有されるディスク領域の量が大幅に失われることになります。

したがって、はい、時間分割は良い選択肢です。 プロメテウスはそれを使用します。 しかし、プロメテウスには別の欠点があります。 これらのデータを結合するときは、すべてのラベルと時系列のメタ情報をメモリ内に保持する必要があります。 したがって、VictoriaMetrics とは異なり、マージするデータの断片が大きい場合、マージ中にメモリ消費量が非常に増加します。 マージの際、VictoriaMetrics はメモリをまったく消費せず、マージされたデータのサイズに関係なく、消費されるのは数キロバイトだけです。

使用しているアルゴリズムはメモリを使用します。 値を含む timeseries タグをマークします。 このようにして、あるデータ配列と別のデータ配列にペアの存在があるかどうかを確認します。 そして、交差が発生したかどうかがわかります。 通常、データベースにはカーソルとイテレータが実装されており、これらの操作は単純に複雑であるため、現在のコンテンツを保存し、並べ替えられたデータを実行します。

データをトラバースするためにカーソルを使用しないのはなぜでしょうか?

はい。

ソートされた行は LevelDB またはマージセットに保存されます。 カーソルを移動して交差点を見つけることができます。 使ってみませんか？ 遅いからです。 カーソルを使用すると、行ごとに関数を呼び出す必要があるためです。 関数呼び出しは 5 ナノ秒です。 100 億行ある場合、関数を呼び出すだけで 000 秒かかることがわかります。

そういうことあるんですね、はい。 そして最後の質問です。 この質問は少し奇妙に聞こえるかもしれません。 データが到着した瞬間に必要なすべての集計を読み取り、必要な形式で保存することができないのはなぜですか? VictoriaMetrics、ClickHouse などの一部のシステムに大量のデータを保存し、それに多くの時間を費やすのはなぜでしょうか?

わかりやすくするために例を挙げます。 小さなおもちゃのスピードメーターがどのように機能するか考えてみましょう。 移動した距離を記録し、常にそれを XNUMX つの値に加算し、XNUMX 番目の値を加算します。 そして分けます。 そして平均的な速度が得られます。 ほぼ同じことができます。 必要な事実をすべてその場で合計します。

わかりました、質問はわかりました。 あなたの例にはその場があります。 必要な集計がわかっている場合、これが最良の実装です。 しかし、問題は、ユーザーがこれらのメトリクスや一部のデータを ClickHouse に保存しており、将来的にそれらをどのように集計してフィルタリングするかがまだわかっていないため、すべての生データを保存する必要があることです。 しかし、平均値を計算する必要があることがわかっている場合は、大量の生の値をそこに保存する代わりに、平均値を計算してみてはいかがでしょうか? ただし、これは必要なものを正確に知っている場合に限ります。

ちなみに、時系列を保存するデータベースは集計のカウントをサポートしています。 たとえば、プロメテウスはサポートしています 録音ルール。 つまり、必要な単位がわかっていれば、これを行うことができます。 VictoriaMetrics にはまだこれがありませんが、通常は Prometheus が先行しており、再コーディング ルールでこれを行うことができます。

たとえば、以前の仕事では、過去 XNUMX 時間のスライディング ウィンドウ内のイベントの数を数える必要がありました。 問題は、Go でカスタム実装、つまり、これをカウントするためのサービスを作成する必要があることです。 このサービスは計算が難しいため、最終的には自明ではありませんでした。 一定の時間間隔でいくつかの集計をカウントする必要がある場合、実装は簡単になります。 スライディング ウィンドウ内のイベントをカウントしたい場合、それは思ったほど単純ではありません。 これは実装が難しいため、ClickHouse や時系列データベースにはまだ実装されていないと思います。

そしてもう一つ質問です。 私たちはちょうど平均化について話していたところ、かつては Carbon バックエンドを備えた Graphite のようなものがあったことを思い出しました。 そして、彼は古いデータを間引く方法、つまり XNUMX 分ごとに XNUMX ポイント、XNUMX 時間ごとに XNUMX ポイントなどを残す方法を知っていました。原理的に、これは、比較的言えば XNUMX か月分の生データが必要な場合に非常に便利で、それ以外のデータは何でも可能です。間引かれます。 ただし、Prometheus と VictoriaMetrics はこの機能をサポートしていません。 それをサポートする予定はありますか? そうでない場合は、なぜそうではないのでしょうか?

ご質問ありがとうございます。 ユーザーは定期的にこの質問をします。 彼らは、ダウンサンプリングのサポートをいつ追加するかを尋ねます。 ここにはいくつかの問題があります。 まず、すべてのユーザーが理解すること downsampling 何かが異なります。特定の間隔で任意の点を取得したい人もいれば、最大値、最小値、平均値を取得したい人もいます。 多くのシステムがデータベースにデータを書き込む場合、すべてをひとまとめにすることはできません。 システムごとに異なる間引きが必要になる可能性があります。 そして、これを実装するのは困難です。

50 つ目は、VictoriaMetrics は、ClickHouse と同様に、大量の生データを処理するために最適化されているため、システムに多数のコアがある場合、000 秒以内に 000 億行を処理できることです。 VictoriaMetrics で時系列ポイントをスキャン – コアあたり 20 秒あたり XNUMX ポイント。 そして、このパフォーマンスは既存のコアに合わせて拡張されます。 つまり、たとえば XNUMX 個のコアがある場合、XNUMX 秒あたり XNUMX 億ポイントをスキャンすることになります。 VictoriaMetrics と ClickHouse のこの特性により、ダウンサンプリングの必要性が減ります。

もう 0,4 つの特徴は、VictoriaMetrics がこのデータを効果的に圧縮することです。 本番環境での平均の圧縮は、ポイントあたり 0,8 ～ XNUMX バイトです。 各ポイントはタイムスタンプ + 値です。 また、平均して XNUMX バイト未満に圧縮されます。

セルゲイ。 質問があります。 最小録音時間はどれくらいですか?

XNUMXミリ秒。 私たちは最近、他の時系列データベース開発者と話をしました。 最小タイム スライスは XNUMX 秒です。 たとえば、Graphite では、これも XNUMX 秒です。 OpenTSDB でも XNUMX 秒です。 InfluxDB の精度はナノ秒です。 Prometheus では XNUMX ミリ秒であるため、VictoriaMetrics では XNUMX ミリ秒です。 VictoriaMetrics はもともと Prometheus のリモート ストレージとして開発されました。 しかし、今では他のシステムからデータを保存できるようになりました。

私が話をした担当者は、精度は 30 秒から XNUMX 秒であると言っています。精度は時系列データベースに保存されているデータの種類に依存するため、彼らにとってはそれで十分です。 これが DevOps データまたはインフラストラクチャからのデータであり、XNUMX 分あたり XNUMX 秒の間隔で収集される場合は、XNUMX 秒の精度で十分であり、それ以下のものは必要ありません。 そして、このデータを高頻度取引システムから収集する場合は、ナノ秒の精度が必要です。

VictoriaMetrics のミリ秒精度は DevOps のケースにも適しており、レポートの冒頭で述べたほとんどのケースに適しています。 唯一適していない可能性があるのは、高頻度取引システムです。

ありがとう！ そしてもう一つの質問。 PromQL の互換性とは何ですか?

完全な下位互換性。 VictoriaMetrics は PromQL を完全にサポートしています。 さらに、PromQL に次の高度な機能が追加されます。 メトリクスQL。 この拡張機能に関するトークが YouTube にあります。 私は春にサンクトペテルブルクで開催されたモニタリングミートアップで講演しました。

テレグラムチャンネル ビクトリアメトリクス.

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

Prometheus の長期ストレージとして VictoriaMetrics に切り替えることを妨げているのは何ですか? (コメントに書いてください。アンケートに追加します))

• 視聴者の３８%がPrometheus5は使用しません

• 視聴者の３８%がVictoriaMetrics2 について知りませんでした

7 人のユーザーが投票しました。 12名のユーザーが棄権した。

出所： habr.com