ストリーミングデータベースと時系列データベースの違いを徹底解説：ユースケースと選び方

![00018566-96cb-43e2-8d83-a4443facf5c6 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945294/30e4e5b6-6081-36e7-aa2f-82b226feebdf.png)
RisingWave Labsのデベロッパーアドボケイトとして、[RisingWave](https://risingwave.com/)のような[ストリーミングデータベース](https://risingwave.com/blog/streaming-databases-everything-you-wanted-to-know/)と[時系列データベース](https://en.wikipedia.org/wiki/Time_series_database) (TSDB)の違いについて混乱を抱える人にしばしば出会います。どちらも高速データを扱いますが、それぞれの強みは異なる分野にあります。本記事ではこれらの違いを明確にし、RisingWaveを例とするストリーミングデータベースと、[InfluxDB](https://github.com/influxdata/influxdb)、[Prometheus](https://prometheus.io/)、[TimescaleDB](https://www.timescale.com/)のような人気のあるTSDBを対比して、リアルタイムデータのニーズに最適なツールを選ぶお手伝いをします。

**免責事項:** RisingWave Labsのデベロッパーアドボケイトとして、ストリーミングデータベースに対する自然な偏りがあります。しかし、本記事はTSDBとストリーミングデータベースを公平に比較し、特定の要件に基づいて情報に基づいた選択ができるよう支援することを目的としています。

## TL;DR

**次のような場合はTSDBを選択してください:**

- 生の時系列データの保存と取得が必要な場合。
- 長期間にわたる履歴トレンドを分析するためのアドホッククエリが必要な場合。

**次のような場合はRisingWaveのようなストリーミングデータベースを選択してください:**

- 継続的なイベントストリームのリアルタイム処理が必要な場合。
- 数百ミリ秒の遅延で事前定義されたメトリクスの結果が必要な場合。
- 複雑な変換（多方向結合、集約、ウィンドウ関数など）を伴うデータの事前処理が必要な場合。

## 時系列データとイベントストリーミングデータ: 基本的な違いの理解

TSDBとストリーミングデータベースの基本的な違いは、それぞれが処理するデータの性質にあります：

| 特徴 | 時系列データ (TSDB) | イベントストリーミングデータ (ストリーミングDB) |
| --- | --- | --- |
| 性質 | 規則的で時間順に並んだデータポイント | 個別の、不規則である可能性のあるイベント |
| スキーマ | 通常固定で予測可能 | 柔軟でイベントごとに異なる可能性がある |
| 到着 | 通常一定間隔 (例: 毎分) | イベントによってトリガーされ、不規則な場合もある |
| 例 | センサーの読み取り値 (温度、湿度)、株価、CPU使用率 | ユーザーアクション (クリック、購入)、システムイベント (ログイン、エラー)、金融取引 |
| 焦点 | 履歴トレンドの保存とクエリ | データの流動中の処理と分析 |
| 一般的なクエリ | 過去1週間の平均温度はどれくらいだったか？ | 過去5分間にサインアップしたユーザー数は？ |
| 一般的なフィールド | timestamp (文字列)、sensor_id (文字列)、value (数値)、unit (文字列) | event_id (文字列)、event_type (文字列)、timestamp (文字列)、user_id (文字列)、...（他のフィールドはイベントタイプごとに異なる） |

![](https://storage.googleapis.com/zenn-user-upload/645ebc72dc5d-20250128.png)


TSDBは履歴トレンドの保存と分析に優れており、「保存してから分析する」というアプローチを取ります。一方、ストリーミングデータベースはデータ到着時に処理を行い（「流動中のデータ」）、リアルタイムの洞察とアクションを可能にします。ストリーミングデータベースの重要な特徴は、リアルタイムストリームをテーブルに存在する履歴データと結合できる点です。

## アーキテクチャの役割: デスティネーション vs. エンジン

TSDBとストリーミングデータベースはデータアーキテクチャで異なる役割を果たします：

**TSDBの役割：デスティネーション**
TSDBは履歴時系列データの保存と分析に最適化されています。これは後でトレンドやパターンを分析するためにデータを保存する*デスティネーション*（目的地）です。たとえば、長期的な株式市場のトレンドを分析する際には、TSDBが最適です。

**ストリーミングデータベースの役割：エンジン**
RisingWaveのようなストリーミングデータベースは、リアルタイムデータパイプラインの*エンジン*として機能します。これらは継続的なデータストリームを取り込み、処理し、変換してリアルタイム分析やイベント駆動型アプリケーションをサポートします。処理済みデータ（マテリアライズドビュー）を保存できますが、長期保存のためにはデータレイクやデータウェアハウスに送信されることがよくあります。

![](https://storage.googleapis.com/zenn-user-upload/40d7f3f634d4-20250128.png)


## クエリパターン: アドホック vs. 継続的

**TSDB**は、履歴データに対する***アドホッククエリ***および***時間範囲スキャン***に最適化されています。

例：「過去1か月間の平均CPU使用率はどれくらいか？」

**ストリーミングデータベース**は、ストリーミングデータに対する***継続的***かつ***事前定義されたクエリ***のために設計されています。これらのクエリは通常、*ストリーミングジョブ*と呼ばれ、事前に定義され、継続的に実行され、新しいデータが到着するたびに結果が更新されます。例えば、RisingWaveでは、次のように1分ごとのユーザーサインアップ数を追跡するマテリアライズドビューを作成できます：

```sql
CREATE MATERIALIZED VIEW signup_rate AS
SELECT COUNT(*) FROM users WHERE signup_time > now() - interval '1 minute';

```

このマテリアライズドビューは継続的に更新され、常に過去1分間の最新のサインアップ数を提供します。

## データ保持: ポリシー vs. 一時的なフィルタ

**TSDB:** *保持ポリシー*を使用してデータを管理します。これらのポリシーでは、データが自動削除されるまでの期間を定義します（例：「データを30日間保持する」）。

**ストリーミングデータベース:** ストリーミングジョブ内で*一時的なフィルタ*を使用して、最新のデータのみを処理することがよくあります。これらのフィルタでは、処理対象の時間範囲を定義します（例：「過去1時間のデータを処理する」）。RisingWaveでは、次のように`WHERE event_time > NOW() - INTERVAL '1 hour'`というフィルタを使用して、過去1時間のデータのみを処理できます。

## 統合パターン: プル型 vs. イベント駆動型

**TSDB**は通常、**プル型**統合パターンに従います。ダウンストリームシステム（BIツールや分析アプリケーションなど）がクエリを実行してTSDBからデータを取得する責任を負います。例えば、ダッシュボードツールは定期的にTSDBにクエリを送信して最新のメトリクスを取得し、可視化します。

**ストリーミングデータベース**は、プル型統合パターンに加えて、**イベント駆動型**統合パターンも採用できます。ストリーミングデータベースは、新しいデータや更新をダウンストリームシステムに即時にプッシュすることができます。これを実現するために、メッセージングキューへのストリーミング結果の送信やWebSocketの使用が一般的です。例えば、RisingWaveはApache Kafkaのようなメッセージングキューのソースとして機能し、処理済みデータや変更イベントをKafkaトピックに公開します。ダウンストリームシステムはこれらのトピックを購読できます。

## エコシステム: モニタリング vs. リアルタイムパイプライン

**TSDB**は、*モニタリングおよび可観測性*のエコシステムと密接に統合されています。これらはデータ収集エージェント、モニタリングシステム、可視化ツール、アラートシステムと連携し、システムの健全性やパフォーマンスの包括的なビューを提供します。

**ストリーミングデータベース**は、*リアルタイムデータ処理パイプライン*の重要な構成要素です。これらは、ストリーミングプラットフォーム（Kafkaなど）、運用データベース、データウェアハウス/データレイク、BIツールと統合し、リアルタイム分析やイベント駆動型アプリケーションを可能にします。

## **ユースケースと相乗効果: TSDBとストリーミングデータベースの力を組み合わせる**

![](https://storage.googleapis.com/zenn-user-upload/dae0673b63fa-20250128.png)


TSDBとストリーミングデータベースは、それぞれ異なる分野で優れています：

- **TSDB**は、履歴分析に最適です。一般的なユースケースには以下が含まれます：
    - **履歴市場分析:** 株価の履歴トレンドを研究する。
    - **インフラモニタリング:** 履歴パフォーマンスデータを分析してリソース利用を最適化する。
- **ストリーミングデータベース**は、リアルタイム分析とイベント駆動型アクションを目的として設計されています。主な適用例：
    - **不正検出:** 発生時に不正取引を特定する。
    - **リアルタイムモニタリングと市場分析:** 財務市場やその他の業界向けに最新のダッシュボードで主要指標を追跡する。

### **協力して機能する**

それぞれ独立して優れていますが、TSDBとストリーミングデータベースは効果的に連携させることが可能です。一般的なパターンとして、リアルタイム処理にストリーミングデータベースを使用し、その後、集約データをTSDBに保存して長期的な履歴分析を行う方法があります。たとえば、あるシステムでは、ストリーミングデータベースを使用して異常を検出しアラートをトリガーする一方で、データをTSDBに送信して根本原因を後で特定することができます。

## **将来のトレンド**

TSDBとストリーミングデータベースの境界はますます曖昧になりつつあります。一部のTSDBがストリーミング機能を追加し、逆に一部のストリーミングデータベースが履歴データの保存機能を強化しているのを目にします。この傾向は、リアルタイムデータと履歴データの両方を処理できるシステムへの需要の高まりを反映しています。クラウドネイティブアーキテクチャ、サーバーレスデプロイメント、およびAIにおけるストリーム処理の増加は、この進化をさらに加速させています。

## まとめ

この比較は、TSDBとストリーミングデータベースの主な違いを明らかにしています。適切なツールの選択は、特に履歴トレンドの分析が必要か、リアルタイムでイベントに対応する必要があるかという特定のニーズに依存します。ストリーミングデータベースに興味がある方は、[RisingWave](https://risingwave.com/)をご覧ください。オープンソースであり、公式ウェブサイトやコミュニティでより多くのリソースやチュートリアルを見つけることができます！