ストリーミングデータベースとは、大量のリアルタイムデータを処理するために特化して設計されたデータベースの一種です。従来のデータベースは、データを一括で格納し処理するのに対し、ストリーミングデータベースはデータが生成されると同時に処理を行い、リアルタイムなインサイトや分析を可能にします。また、従来のストリーム処理エンジンはデータを永続化しませんが、ストリーミングデータベースはデータを保存し、ユーザーのデータアクセス要求に応答できます。これにより、ストリーミングデータベースはリアルタイム分析、不正検知、ネットワーク監視、IoT（モノのインターネット）などの低遅延を要求されるアプリケーションに最適であり、技術スタックを簡素化することも可能です。
簡単な歴史
ストリーミングデータベースの概念は、2002年に学術界で初めて提唱されました。ブラウン大学、ブランダイス大学、MITの研究者グループが、データベース内でのデータストリーム管理の需要を指摘し、初のストリーミングデータベース「Aurora」を構築しました。その数年後、大手企業がこの技術を採用しました。オラクル、IBM、マイクロソフトの3大データベースベンダーはそれぞれ、Oracle CQL、IBM System S、Microsoft SQLServer StreamInsightと呼ばれるストリーム処理ソリューションを相次いで発表しました。これらのベンダーは、ストリーミングデータベースをゼロから開発するのではなく、既存のデータベースにストリーム処理機能を直接統合しました。
2000年代後半以降、MapReduceに触発された開発者たちは、ストリーム処理機能をデータベースシステムから分離し、Apache Storm、Apache Samza、Apache Flink、Apache Spark Streamingなどの大規模なストリーム処理エンジンを開発しました。これらのシステムは、取り込んだデータストリームを継続的に処理し、結果を下流システムに提供するよう設計されています。しかし、ストリーミングデータベースと比較すると、ストリーム処理エンジンはデータを保存せず、ユーザーが主導するアドホッククエリに対応することはできません。
ストリーミングデータベースは、ストリーム処理エンジンと並行して進化を続けています。2010年代には、PipelineDBやKsqlDBといった2つのストリーミングデータベースが開発され、当時の人気を博しました。2020年代初頭には、RisingWave、Materialize、DeltaStreamなど、いくつかのクラウドベースのストリーミングデータベースが登場しました。これらの製品は、クラウド上でストリーミングデータベースサービスを提供することを目的としており、そのために無制限の水平スケーラビリティと優れたコスト効率を実現するアーキテクチャの設計に注力しています。
典型的なユースケース
ストリーミングデータベースは、リアルタイムでの結果を要求するアプリケーションに最適です。IoTやネットワーク監視のように、サブセカンドの遅延が求められるものもあれば、広告推薦、株式ダッシュボード、食品配達など、数百ミリ秒から数分の遅延が許容されるものもあります。ストリーミングデータベースは、低遅延で継続的に結果を提供し、これらのアプリケーションに適しています。
一方、数十分、数時間、あるいは数日間の遅延を許容できるアプリケーションもあります。代表例として、ホテル予約や在庫管理が挙げられます。この場合、ストリーミングデータベースまたは従来のバッチベースのデータベースのどちらを使用するかは、コスト効率、柔軟性、技術スタックの複雑さなどの他の要因に基づいて判断する必要があります。
リアルタイムアプリケーションでは、ストリーミングデータベースは他のデータシステムと組み合わせて使用されることが一般的で、ストリーミングデータ取り込み（ETL）とストリーミング分析という2つの典型的なユースケースを促進します。
ストリーミングデータ取り込み（ETL）
ストリーミングデータ取り込みは、あるシステム群から別のシステム群へデータを継続的に流すプロセスです。開発者はストリーミングデータベースを使用して、ストリーミングデータをクリーンアップし、複数のストリームを結合し、結合結果をリアルタイムで下流システムに転送することができます。現実世界のシナリオでは、ストリーミングデータベースに取り込まれるデータは、OLTPデータベース、メッセージキュー、またはストレージシステムから来ることが一般的です。処理後の結果は、これらのシステムに戻されるか、データウェアハウスまたはデータレイクに挿入されることが多いです。
ストリーミング分析
ストリーミング分析は、複雑な計算をリアルタイムで実行し、常に最新の結果を提供することに焦点を当てています。このシナリオでは、データは通常、OLTPデータベース、メッセージキュー、ストレージシステムから供給されます。結果は、通常、提供システムに取り込まれ、ユーザーがトリガーするリクエストに対応します。また、ストリーミングデータベース自体がクエリに応答することも可能です。ユーザーはBIツールをストリーミングデータベースに直接接続して、結果を可視化することができます。
リアルタイム機械学習の需要が増加する中で、ストリーミングデータベースは機敏な特徴量エンジニアリングを可能にする重要なツールにもなっています。ストリーミングデータベースを使用して変換済みのデータを特徴量として保存することで、開発者はデータパターンの変化や新しいイベントに迅速に対応できます。ストリーミングデータベースは、データのリアルタイム取り込み、処理、および変換を可能にし、機械学習モデルの精度と効率を向上させる有意義な特徴量を生成します。この結果、データの重複を減らし、データ品質を向上させながら、組織はより迅速かつ情報に基づいた意思決定を行い、機械学習のワークフローを最適化し、競争優位性を得ることができます。
ストリーミングデータベースと従来型データベースの違い
従来型データベースは、大量のバッチデータを格納し、それに対するトランザクションやクエリを迅速かつ一貫して処理するために設計されています。これらは、集計や結合などの複雑な操作を一括で処理するよう最適化されています。従来型データベースの実行モデルは一般に「人間が能動的でDBMSが受動的（HADP: Human-Active, DBMS-Passive）」モデルと呼ばれます。つまり、従来型データベースはデータを受動的に格納し、人間が積極的にクエリを実行して計算をトリガーします。代表的な例として、MySQLやPostgreSQLのようなOLTPデータベース、DuckDBやClickHouseのようなOLAPデータベースがあります。
一方、ストリーミングデータベースは、継続的に取り込まれる大量のデータをリアルタイムで増分処理し、データや結果への低遅延アクセスを提供するために設計されています。これらは、データが到着するたびに処理を行うことを最適化しており、データの永続化後に一括処理する従来型データベースとは異なります。ストリーミングデータベースの実行モデルは「DBMSが能動的で人間が受動的（DAHP: DBMS-Active, Human-Passive）」モデルと呼ばれます。ストリーミングデータベースはデータの到着に応じて計算を積極的にトリガーし、人間はデータベースから結果を受動的に受け取ります。PipelineDB、KsqlDB、RisingWaveなどがストリーミングデータベースの例です。
ストリーミングデータベースとOLTPデータベースの違い
OLTP（オンライン・トランザクション処理）データベースは、ACID特性（原子性、一貫性、独立性、持続性）を満たしており、複数のトランザクションを同時に処理することができます。一方、ストリーミングデータベースはACID特性を保証しないため、トランザクション処理のワークロードには適しません。データの正確性に関して、ストリーミングデータベースは一貫性と完全性を重視します。適切に設計されたストリーミングデータベースは、次の2つの特性を保証するべきです：
-
Exactly-once セマンティクス
すべてのデータイベントが、システム障害が発生した場合でも、1回だけ確実に処理されること。 -
順不同データの処理
データイベントが順不同で到着した場合でも、事前に定義された順序で処理することをユーザーが指定できること。
ストリーミングデータベースとOLAPデータベースの違い
OLAP（オンライン分析処理）データベースは、ユーザーが主導する分析クエリを効率的に処理するよう最適化されています。OLAPデータベースは、一般に列指向ストレージとベクトル化実行エンジンを実装しており、大量のデータに対する複雑なクエリ処理を高速化します。これらは、インタラクティブなクエリが重要なユースケースに最適です。
これに対し、ストリーミングデータベースは結果の鮮度を重視しており、低遅延を最適化するために増分計算モデルを採用しています。ストリーミングデータベースは通常、列指向ストレージを使用しませんが、クエリ処理を高速化するためにベクトル化実行を採用する場合があります。
結論
ストリーミングデータベースは、大量のデータからリアルタイムでインサイトを得る必要がある組織にとって不可欠なシステムです。リアルタイム処理、スケーラビリティ、信頼性を提供することで、ストリーミングデータベースは、組織がより良い意思決定を行い、機会を特定し、脅威にリアルタイムで対応するのを支援します。