InfluxdbをTSDBの例として考えてみましょう。概要では、Influxdbは時間追加だけのファイルでソートされたデータを格納しています。しかし、追加するだけでなく、ランダムなタイムスタンプでデータを挿入することも可能であると主張しています。また、IoTの世界では、過去のデータを時折見つけて（たとえば、一部のデバイスがしばらくオフラインになってから再びオンラインになるなど）、このデータを時系列DBに配置してグラフをプロットしています。このようなシナリオには、どのようにすればよいでしょうか？追加専用ファイルを完全に書き換えますか？過去から時系列のDBのタイムスタンプ付きデータを挿入
これは私がそれを理解する方法です。 InfluxDBは、データがある時間ブロックごとに論理データベース（シャード）を作成します。既定では、シャードグループ期間は1週間です。したがって、タイムスタンプ付きの測定値をたとえば4週間前、彼らはその後の週からシャードに影響を与えません。
各シャード内で、着信書き込みは最初にWAL（write ahead log）に追加され、メモリにもキャッシュされます。 WALとキャッシュが十分にいっぱいになると、ディスクにスナップショットされ、レベル0のTSM（時間構造化マージツリー）ファイルに変換されます。これらのファイルは読み取り専用で、測定は最初にシリーズ順に、次に時間順に行われます。
TSMファイルが大きくなるにつれて、圧縮されてレベルが上がります。複数のレベル0のスナップショットが圧縮され、レベル1のファイルが生成されます。コンパイルによって、TSMファイルが最小限の一連のセットを含むように（理想的には）最適化され、他のTSMと重複しないように最適化されますファイル。これは、特定のシリーズ/時間ルックアップを検索する必要があるTSMファイルの数が減ることを意味します。
これを知っていると、ランダムタイムスタンプの書き込み作業負荷の下でInfluxDBがどのように苦しんでいますか？タイムスタンプがまばらに散らばっていて、シャードグループの持続時間が短い、すなわちほとんどの書き込みが異なるシャードに当たった場合、私たちは多くのシャードで終わるでしょう。これは、非効率的な多くのほぼ空のデータファイルを意味します（この問題はFAQで解決されています）。一方、ランダム・タイムスタンプが1つまたは2つのシャードに集中している場合、それらの下位レベルのTSMファイルは時間的に重複している可能性が高く、狭い時間範囲での照会の場合でもすべてを検索する必要があります。これは、これらの種類のクエリでの読み取りパフォーマンスに影響します。
詳しい情報は、これらのリソースで見つけることができます：