TSDB の例として Influxdb を考えてみましょう。概要では、Influxdb は時間ごとに並べ替えられた追加専用ファイルにデータを格納するように見えます。しかし、単に追加するだけでなく、ランダムなタイムスタンプでデータを挿入できるとも主張しています。また、IoT の世界では、過去のデータを時折見つけて (たとえば、一部のデバイスがしばらくオフラインだった後に再びオンラインになった場合など)、このデータを時系列データベースに配置していくつかのグラフをプロットすることは非常に一般的なシナリオです。influxdb はそのようなシナリオにどのように対処できますか? 追加専用ファイルを完全に書き換えますか?
1 に答える
1
これが私がそれを理解する方法です。InfluxDB は、データを持つ時間ブロックごとに論理データベース ( shard )を作成します。デフォルトでは、シャード グループの期間は 1 週間です。したがって、たとえば 4 週間前のタイムスタンプを使用して測定値を挿入しても、その後の週のシャードには影響しません。
各シャード内で、着信書き込みは最初に WAL (先行書き込みログ) に追加され、メモリにもキャッシュされます。WAL とキャッシュが十分にいっぱいになると、スナップショットがディスクに作成され、レベル 0 の TSM (時間構造マージ ツリー) ファイルに変換されます。これらのファイルは読み取り専用で、測定値は最初に系列順、次に時間順に並べられます。
TSM ファイルが大きくなるにつれて、圧縮されてレベルが上がります。複数のレベル 0 スナップショットが圧縮されて、レベル 1 ファイルが生成されます。あまり頻繁ではありませんが、複数のレベル 1 ファイルが圧縮されてレベル 2 ファイルが生成され、最大レベル 4 まで続きます。圧縮により、TSM ファイルは (理想的には) 最小セットのシリーズを含むように最適化され、他の TSM とのオーバーラップが最小限に抑えられます。ファイル。これは、特定のシリーズ/タイム ルックアップで検索する必要がある TSM ファイルが少なくなることを意味します。
これを知っていると、ランダムなタイムスタンプを持つ書き込みのワークロードの下で、InfluxDB はどのように苦しむのでしょうか? タイムスタンプがまばらに分散され、シャード グループの期間が短い場合、つまり、ほとんどの書き込みが異なるシャードにヒットする場合、多くのシャードが発生します。これは、ほとんど空のデータ ファイルが多く、非効率的であることを意味します (この問題は、FAQで対処されています)。一方、ランダムなタイムスタンプが 1 つまたは 2 つのシャードに集中している場合、それらの下位レベルの TSM ファイルは時間的に大幅に重複する可能性が高く、狭い時間範囲のクエリでもすべてを検索する必要があります。これは、これらの種類のクエリでの読み取りパフォーマンスに影響します。
詳細については、次のリソースを参照してください。
于 2017-11-23T01:51:17.230 に答える