InfluxDB を使用する際の怒り、駆け引き、憂鬱

時系列データベース（timeseries db、 ウィキ) を統計情報を含むサイトのメイン ストレージとして使用すると、問題が解決される代わりに、多くの頭の痛い問題が発生する可能性があります。 私はそのようなデータベースを使用するプロジェクトに取り組んでいますが、これから説明する InfluxDB はまったく予想外の驚きをもたらすことがありました。

免責事項: リストされている問題は、InfluxDB バージョン 1.7.4 に適用されます。

なぜ時系列なのか？

このプロジェクトは、さまざまなブロックチェーン上のトランザクションを追跡し、統計を表示することです。 具体的には、ステーブルコインの発行と燃焼を調べます（ウィキ）。 これらのトランザクションに基づいて、グラフを作成し、集計表を表示する必要があります。

トランザクションを分析しているときに、InfluxDB 時系列データベースをメイン ストレージとして使用するというアイデアが浮かびました。 トランザクションは時点であり、時系列モデルによく適合します。

集計関数も非常に便利で、長期間のチャートを処理するのに最適です。 ユーザーは 365 年間のチャートを必要とし、データベースには XNUMX 分間の時間枠のデータ セットが含まれています。 XNUMX 万個のドットをすべて送信しても意味がありません。長い処理を除けば、画面に収まりきらないからです。 タイムフレームを増やす独自の実装を作成することも、Influx に組み込まれている集計関数を使用することもできます。 彼らの助けを借りて、データを日ごとにグループ化し、必要な XNUMX ポイントを送信できます。

このようなデータベースは通常、メトリクスを収集する目的で使用されるということに少し混乱しました。 サーバー、IoT デバイスなど、何百万ものポイントが「フロー」するすべてのものを監視します: [<時間> - <メトリック値>]。 しかし、データベースが大規模なデータ フローで適切に動作するのであれば、なぜボリュームが小さいと問題が発生するのでしょうか? これを念頭に置いて、私たちは InfluxDB を採用しました。

InfluxDB のその他の便利な機能

前述の集計関数とは別に、もう XNUMX つの優れた点があります。 継続的なクエリ (DOC）。 これは、スケジュールに従ってデータを処理できるデータベースに組み込まれたスケジューラーです。 たとえば、24 時間ごとに、その日のすべてのレコードをグループ化し、平均を計算し、独自の自転車を作成することなく、別のテーブルに XNUMX つの新しいポイントを記録できます。

あります 保存ポリシー (DOC) - 一定期間後のデータ削除を設定します。 たとえば、XNUMX 週間に XNUMX 秒ごとの測定で CPU 負荷を保存する必要があるが、数か月の距離ではそのような精度は必要ない場合に便利です。 このような状況では、次のようにすることができます。

1. 連続クエリを作成してデータを別のテーブルに集約します。
2. 最初のテーブルでは、同じ週よりも古いメトリクスを削除するためのポリシーを定義します。

そしてInfluxは独自にデータのサイズを削減し、不要なものを削除します。

保存データについて

保存されるデータはそれほど多くありません。約 70 万件の取引と、さらに 3000 万点の市場情報が保存されます。 新しいエントリの追加 - XNUMX 日あたり XNUMX ポイント以下。 サイトのメトリックもありますが、そこにはデータがほとんどなく、保持ポリシーに従って、データは XNUMX か月以内に保存されます。

問題

サービスの開発とその後のテスト中に、InfluxDB の運用においてますます重大な問題が発生しました。

1. データの削除

トランザクションに関する一連のデータがあります。

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

結果：

データを削除するコマンドを送信しています。

DELETE FROM transactions WHERE symbol=’USDT’

次に、既に削除されたデータの受信をリクエストします。 そして、Influx は空の応答の代わりに、削除する必要があるデータの一部を返します。

テーブル全体を削除しようとしています。

DROP MEASUREMENT transactions

テーブルの削除を確認します。

SHOW MEASUREMENTS

リストにはテーブルが表示されませんが、新しいデータ クエリは同じトランザクションのセットを返します。

削除のケースは個別のケースだったので、この問題が私に発生したのは XNUMX 回だけでした。 しかし、データベースのこの動作は明らかに「正しい」操作の枠組みに当てはまりません。 後でgithubで公開されているのを見つけました チケット この話題についてはほぼXNUMX年前。

結果として、データベース全体を削除して復元することで解決しました。

2. 浮動小数点数

InfluxDB の組み込み関数を使用する場合の数学計算には精度エラーが発生します。 これは特別なことではありませんが、不快です。

私の場合、データには財務的な要素が含まれているため、高精度に処理したいと考えています。 このため、継続的なクエリは廃止する予定です。

3. 継続的なクエリを異なるタイムゾーンに適応させることはできません

このサービスには、毎日のトランザクション統計を示すテーブルがあります。 日ごとに、その日のすべてのトランザクションをグループ化する必要があります。 ただし、各ユーザーの XNUMX 日は異なる時間に始まるため、一連のトランザクションも異なります。 UTCまでにはい 37オプション データを集計する必要があるシフト。

InfluxDB では、時間でグループ化するときに、たとえばモスクワ時間 (UTC+3) などのシフトを追加で指定できます。

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

ただし、クエリ結果は正しくありません。 何らかの理由で、日ごとにグループ化されたデータは 1677 年まで遡って開始されます (InfluxDB は今年から期間を正式にサポートしています)。

この問題を回避するために、サービスを一時的に UTC+0 に切り替えました。

4.パフォーマンス

インターネット上には、InfluxDB と他のデータベースを比較するベンチマークが多数あります。 一見するとマーケティング資料のように見えましたが、今ではその中に真実が含まれていると思います。

私の場合をお話します。

このサービスは、過去 XNUMX 日の統計を返す API メソッドを提供します。 計算を実行するとき、メソッドは次のクエリを使用してデータベースに XNUMX 回クエリを実行します。

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

説明：

1. 最初のリクエストでは、市場データを使用して各コインの最後のポイントを取得します。 私の場合はXNUMXコインでXNUMXポイントです。
2. XNUMX 番目のリクエストは、最新のポイントの XNUMX つを取得します。
3. XNUMX つ目は、過去 XNUMX 時間のトランザクションのリストを要求します (トランザクションは数百件ある可能性があります)。

InfluxDB はタグと時間に基づいてインデックスを自動的に構築するため、クエリが高速化されることを明確にしておきます。 最初のリクエストでは シンボル タグです。

この API メソッドでストレス テストを実行しました。 25 RPS の場合、サーバーは XNUMX つの CPU の全負荷を実証しました。

同時に、NodeJs プロセスはまったく負荷を提供しませんでした。

実行速度はすでに 7 ～ 10 RPS 低下しています。200 つのクライアントが 10 ミリ秒で応答を受信できた場合、25 のクライアントは 500 秒待つ必要があります。 XNUMX RPS は安定性が損なわれる限界であり、XNUMX エラーがクライアントに返されました。

このようなパフォーマンスでは、私たちのプロジェクトで Influx を使用することは不可能です。 さらに、多くのクライアントに対してモニタリングをデモンストレーションする必要があるプロジェクトでは、同様の問題が発生し、メトリクス サーバーが過負荷になる可能性があります。

出力

得られた経験から得た最も重要な結論は、十分な分析なしに未知のテクノロジーをプロジェクトに導入することはできないということです。 github で未解決の問題を簡単にスクリーニングすることで、InfluxDB をメイン データ ストアとして選択することを避けるための情報が得られる可能性があります。

InfluxDB は私のプロジェクトのタスクに適しているはずですが、実践で示されているように、このデータベースはニーズを満たしておらず、多くのバグがあります。

プロジェクト リポジトリにはすでにバージョン 2.0.0-beta が含まれていますが、XNUMX 番目のバージョンで大幅な改善が加えられることを祈るばかりです。 それまでの間、TimescaleDB のドキュメントを勉強してみます。

出所： habr.com