RisingWave はストリーム処理と低遅延配信をSQLで一体化する

CDCから提供までを一つのSQL系統に置く

RisingWave は agentic AI 向けの event streaming platform と説明されています。Webhook、PostgreSQLやMySQLなどのトランザクションログによるCDC、Kafka・Pulsar・Kinesisなどのイベントストリーム、S3やデータウェアハウスの履歴データを取り込みます。これらのソースは同じSQLインターフェースに統合され、stream と table を結合できます。Debezium、Kafka、Flink、serving DBを個別に連結する構成との差分は、運用部品を減らす主張として読むべきです。

増分計算がmaterialized viewを更新する

上流データが変わったとき、影響を受ける結果だけを再計算する incremental computation が中核です。README は end-to-end freshness を100ms未満としていますが、入力の種類、結合、状態量、ハードウェアが記載値と同じとは限りません。定期的な全更新を待たずに結果を保つ設計なので、監視の閾値評価やライブダッシュボードに適します。実測ではイベント時刻、更新反映時刻、viewの読み取り時刻を同じ基準で保存します。

row storeとIcebergは用途を分ける

低遅延の問い合わせ結果は内部 row store から配信され、README は10から20ms p99を説明しています。長期保持と分析には Apache Iceberg table へ書き出し、Iceberg REST catalog、compaction、小ファイル最適化、snapshot cleanupをRisingWaveが扱います。Icebergの読み取りにはApache DataFusionを使い、Spark、Trino、DuckDBなどからも開ける形式です。高速な現在値と、耐久性を持つオープン形式の履歴を同じ保存層の性質として扱わないことが設計上の要点です。

エージェントと既存ツールの接続口

PostgreSQL wire protocolで接続できるため、psql、JDBC、Postgres互換ツールを利用できます。agent向けには MCP server、CLI、Skills が提供されるとREADMEにあります。独自アダプターを先に作るのではなく、SQL接続で通常の利用者と同じ結果を得られるか、MCP経由の操作権限をどう制限するかを分けて確認します。テレメトリは Scarf による匿名インストール分析と匿名利用統計で、どちらも opt out 可能です。

管理サービスとセルフホストを選ぶ

マネージド版は RisingWave Cloud、セルフホストは Docker Compose、Kubernetes Helm、Kubernetes Operator が案内されています。60秒の導入例は curl -L https://risingwave.com/sh | sh ですが、実運用の認証、ストレージ、バックアップをこの一行から推測できません。まず quickstart の対象環境でソース接続とクエリを通し、HelmやOperatorへ移る場合は同じviewの更新とIceberg保守を比較します。Apache License 2.0 も配布形態ごとに記録します。検証用パイプラインでは、まずPostgreSQLの変更をCDCで取り込み、KafkaまたはWebhookのイベントと結合したmaterialized viewを作ります。更新発生時刻からrow storeでSQL結果を読めるまでを測り、100ms未満と10から20ms p99の説明を入力件数・結合数ごとに比較します。Icebergを有効にした場合はREST catalogの登録、snapshot生成、compaction、小ファイル最適化、snapshot cleanupを順に確認します。出力をSparkやDuckDBから読めるかも検証し、row storeの現在値とIcebergの履歴が同じ目的でないことをテストデータで示します。Docker Composeで再現した後、HelmまたはOperatorへ移し、設定・永続ボリューム・障害復旧の差を記録します。MCP serverとCLIは読み取り権限から始め、Scarfの匿名統計とopt out設定を組織のテレメトリ方針に合わせます。RisingWaveの評価では、入力の到着から結果を読むまでの時間を一つの値にまとめず、CDC、Webhook、Kafkaなどのソース別に記録します。materialized viewの結合対象、更新頻度、状態量を変えて、増分計算が影響部分だけを処理できるかを観測します。row storeのp99を測るときは、クエリ、キャッシュ、同時接続数を固定し、READMEの10から20msという説明と条件を並べます。IcebergではREST catalog、テーブルのsnapshot、compaction、小ファイル、削除処理を確認し、Spark、Trino、DuckDBから履歴を読めることを試します。PostgreSQL wire protocolを使うpsqlとJDBCの接続を分け、MCP serverやCLIは読み取り専用から権限を広げます。Docker Compose、Helm、Operatorは同じデータを投入して更新と復旧を比べ、Cloudを選ぶ場合は管理範囲と自社の保持要件を記録します。Scarfの匿名テレメトリとopt outを確認し、Apache License 2.0、ストレージ、バックアップ、障害時の再処理を本番判断の項目にします。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。この確認では版、設定、入力、出力、エラーを同じ記録に残します。再実行して結果が変わった場合は、対象データと依存部品の差分を先に調べます。運用へ移す前に、失敗時に元へ戻せる手順と担当者を決めます。RisingWaveでは現在値の配信と履歴分析を別の利用者が読むため、同一イベントをrow storeとIcebergの両方で追跡します。遅延、再試行、重複、削除後のsnapshotを確認し、SQL結果と保存結果の差を記録します。入力遅延と保存遅延を分けて測ります。

編集部の結論

常時更新される監視、特徴量、ダッシュボードをSQLで構築し、低遅延の結果と分析用の長期保存を分けたいチームに向きます。README の100ms未満や10から20ms p99は記載上の目標値・説明であり、入力量と構成を越えて保証されません。採用前に PostgreSQL wire で接続し、CDCからmaterialized view、row store、Iceberg snapshotまでを小規模データで測定してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes