時系列データベース
名前が示すように、時系列データベースは、時間とともに変化するデータを格納するように設計されています。これは、時間の経過とともに収集されるあらゆるタイプのデータである可能性があります。彼はいくつかのシステムから収集された指標である場合があります。実際、すべての傾向システムは時系列データの例です。
異なるタイプの時系列データベースをどのように選択すればよいですか？
この記事では、主にTimescaleDBとInfluxDB時系列データベースの違いについて説明します。
InfluxDB
InfluxDBはInfluxDataによって作成されます。これは、Go言語で記述されたカスタムのオープンソースのNoSQL時系列データベースです。データストアは、InfluxQLと呼ばれるSQLのようなクエリ言語を提供します。これにより、開発者はそれをアプリケーションに簡単に統合できます。また、特定のタスクの実行を容易にするFluxと呼ばれる新しいカスタムクエリ言語もありますが、カスタムクエリ言語を使用する場合は、常に学習曲線があります。
以下はFluxクエリの例です。
from(db:"testing")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> exponentialMovingAverage()
このデータベースでは、各測定結果にタイムスタンプと、それに関連付けられた一連のタグと一連のフィールドが含まれています。このフィールドは実際の測定値を表し、ラベルは測定値を説明する元のデータを表します。フィールドのデータ型は、float、int、string、およびbooleanに制限されており、データを書き換えずに変更することはできません。タグ値にはインデックスが付けられます。それらは文字列として表され、更新できません。
プロトタイプやインデックスの作成について心配する必要がないため、InfluxDBの開始は非常に簡単です。ただし、これは非常に厳格で制限があり、追加のインデックス、連続フィールドのインデックスを作成したり、後で元のデータを更新したり、データ検証を強制したりすることはできません。
彼にはプロトタイプがないわけではない。入力データをもとに基本モデルを自動作成します。
InfluxDBは、複数のコピー、高可用性、バックアップ/復元など、複数のフォールトトレランスツールを最初から実装し、ディスクの信頼性に責任を負う必要があります。これらのツールの使用は制限されており、これらの機能（HAなど）の多くはEnterprise Editionでのみ使用できます。
InfluxDBバックアップツールは、フルバックアップまたは増分バックアップを実行でき、ポイントインタイムリカバリに使用できます。
InfluxDBは、PostgreSQLやTimescaleDBよりも優れたディスク圧縮も提供します。
TimescaleDB
TimescaleDBは、包括的なSQLをサポートする迅速な抽出と複雑なクエリのために最適化されたオープンソースの時系列データベースです。これはPostgreSQLに基づいており、時系列データに最適なNoSQLとリレーショナルの世界を提供します。
以下は、TimescaleDBクエリの例です。
SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM testing
WHERE measurement = cpu and time > now() - '1 hour';
PostgreSQLの拡張機能として、TimescaleDBはリレーショナルデータベースです。これにより、新しいユーザーは学習曲線を短くすることができ、バックアップ用のpg_dumpやpg_backupなどのツールや、他の時系列データベースよりも優れている高可用性ツールを継承できます。また、高可用性設定で使用できるプライマリレプリケーション方式としてストリーミングレプリケーションをサポートします。障害のエスケープとバックアップに関しては、ClusterControlなどの外部システムを使用して自動的に実行できます。
TimescaleDBでは、各時系列測定値が独自の行に記録され、時間フィールドの後に、浮動小数点数、整数、文字列、ブール値、配列、JSON、地理空間次元、日付など、他のタイプのフィールドがいくつも続きます/時間/タイムスタンプ、通貨、バイナリデータなど
任意のフィールド（標準インデックス）または複数のフィールド（インデックスに従って）、または関数などの式にインデックスを作成し、インデックスを行自体（部分インデックス）に制限することもできます。これらのフィールドはいずれも補助テーブルへの外部キーとして使用でき、補助テーブルは他の元のデータを格納できます。
このように、プロトタイプを選択し、システムに必要なインデックスを決定する必要があります。
パフォーマンス
パフォーマンスについて話す場合は、TimescaleDBブログをチェックしてください。そこで、グラフとインジケーターを使用して、2つのデータベースのパフォーマンスを詳細に比較できます。それでは、このブログの最も重要な情報のいくつかを見てみましょう。
任意のフィールド（標準インデックス）または複数のフィールド（複合インデックス）、または関数のような式にインデックスを作成できます。または、インデックスを行のサブセット（部分インデックス）に制限することもできます。これらのフィールドはいずれも、追加のメタデータを格納できるセカンダリテーブルへの外部キーとして使用できます。
このように、スキーマを選択し、システムに必要なインデックスを決定する必要があります。
挿入パフォーマンス
- カーディナリティが非常に低いワークロード（100デバイスなど）の場合、InfluxDBはTimescaleDBよりもパフォーマンスが高くなります。
- カーディナリティが増加すると、InfluxDBの挿入パフォーマンスはTimescaleDBよりも速く低下します。
- カーディナリティが中程度から高いワークロード（たとえば、10個のメトリックを送信する100台のデバイス）の場合、TimescaleDBはInfluxDBよりもパフォーマンスが高くなります。
読み取りパフォーマンス
- 単純なクエリの場合、結果は大きく異なります。場合によっては、あるデータベースが別のデータベースよりもはるかに優れている一方で、他のデータベースはデータセットのカーディナリティに依存しています。ここでの違いは通常、1桁から2桁のミリ秒の範囲です。
- 複雑なクエリの場合、TimescaleDBのパフォーマンスはInfluxDBよりもはるかに優れており、幅広いクエリタイプをサポートしています。ここでの違いは通常、数秒から数十秒の間です。
- これを念頭に置いて、正しくテストする最良の方法は、実行する予定のクエリを使用してベンチマークすることです。
安定性
- カーディナリティが高い（100K +）場合、InfluxDBには安定性とパフォーマンスの問題があります。
まとめ
データがInfluxDBデータモデルに適していて、将来変更したくない場合は、列指向のメソッドを使用するほとんどのデータベースのようにモデルが使いやすいため、InfluxDBの使用を検討する必要があります。PostgreSQLやTimescaleDBよりも優れています。ディスク圧縮。
ただし、リレーショナルモデルはInfluxDBモデルよりも用途が広く、より多くの機能、柔軟性、および制御を提供します。これは、アプリケーションの開発時に特に重要です。システムを計画するときは、現在および将来のニーズを考慮する必要があります。
このブログでは、TimescaleDBとInfluxDBの短い比較を確認できます。また、PostgreSQLの拡張機能としてのTimescaleDBは、PostgreSQLから多くのものを継承しているため、成熟していて機能が豊富に見えます。ただし、このブログの前半で述べた長所と短所に基づいて独自の決定を行い、ワークロードのベンチマークを確認することができます。この時系列データベースの新しい世界で頑張ってください！
