最近、フードデリバリーやライドシェア、ロジスティクスといったプラットフォームにとって中核機能となる、リアルタイムの位置マッチングシステムを構築しました。
その過程で気づいたのは、適切なツールがあれば、フル機能のジオ空間データベースを立ち上げる必要はないということです。
この記事では、リアルタイムの位置ストリームを処理するために RisingWave をどのように活用し、そのデータを Redis に送信して、高速かつ近接ベースの検索を実現したかをご紹介します。
注目すべきは次の点です。すべて SQL だけで完結し、シンプルな 1 つのシンク設定で実現できます。マイクロサービスも、接着用コードも不要です。
🚗 課題：最も近いドライバーをすばやく見つけるには？
ユーザーと近くのドライバーやレストランをマッチングするのは一見簡単そうですが、実際には以下のような複雑な要件があります：
- ライブな位置情報の更新
- ジオ空間インデックスの作成
- サブセカンド（秒未満）のクエリ性能
従来であれば、PostGIS や MongoDB の導入と多くのカスタムロジックが必要でした。しかし私は、もっと軽量な道を見つけました。
それは、Redis のネイティブなジオ空間機能と、RisingWave のストリーミング SQL を組み合わせる方法です。
🔧 アーキテクチャ：ストリーム処理 × リアルタイム提供
以下がパイプラインの全体像です：
- RisingWave がドライバーまたはレストランの位置情報ストリームを取り込みます。
- プレーンな SQL を使ってデータを処理・フィルタリング・整形します。
-
GEOADDコマンドを内部で使用し、Redis に直接書き込みます。 - アプリケーションが
GEORADIUSやGEOSEARCHを使って Redis にクエリを実行します。
Redis は超低遅延のデータ提供に優れていますが、RisingWave によってパイプライン全体が宣言的かつリアルタイムで更新されるのが大きな強みです。ジョブスケジューラやカスタム ETL スクリプトは不要です。
🧪 例：ジオ空間データを Redis に書き込む
たとえば、ドライバーからライブな GPS 座標がストリーミングされてくるとします。RisingWave で使ったテーブルスキーマは以下のとおりです：
CREATE TABLE driver_locations (
driver_id VARCHAR,
city VARCHAR,
longitude FLOAT,
latitude FLOAT
);
この位置情報をジオ空間データとして Redis に保存する Redis Sink を次のように定義します：
CREATE SINK geo_sink
FROM driver_locations
WITH (
connector = 'redis',
redis.url = 'redis://127.0.0.1:6379/',
primary_key = 'driver_id,city' -- 一意性を確保する
) FORMAT UPSERT ENCODE TEMPLATE (
redis_value_type = 'geospatial',
key_format = 'drivers:{city}', -- 例：drivers:san_francisco
member = 'driver_id', -- トラッキング対象のオブジェクト
longitude = 'longitude',
latitude = 'latitude'
);
このようにして Redis は drivers:berlin や drivers:tokyo などのライブインデックスを維持します。例えば以下のようにして、特定地点から半径 5km 内のドライバーを検索できます：
GEORADIUS drivers:berlin 13.40 52.52 5 km
Redis はこれに対し、数ミリ秒以内で応答します。
✅ この組み合わせがうまく機能する理由
- 追加インフラが不要：Redis はジオ空間インデックスをネイティブでサポートし、RisingWave は直接接続可能。
- SQL 中心の設計：すべてのデータロジックは SQL に集約されており、複雑な処理パイプラインを構築する必要はありません。
- ライブ更新が可能：新しい位置データがストリーミングされるたびに、Redis がリアルタイムで更新されます。
- スケーラブルかつ柔軟：都市ごとにシャーディングしたり、キー形式を変更したり、複数セットを横断してクエリを実行することができます。
🧠 まとめ
最も印象的だったのは、RisingWave と Redis の相性の良さです。Redis は超高速なデータ提供を得意としますが、RisingWave のストリーミング SQL レイヤー があることで、ストリームの生データが構造化され、即座にクエリ可能な状態へと変換します。
この 2 つを組み合わせれば、従来なら複数のサービスや膨大な実装作業が必要だったロケーション対応のリアルタイムシステムを、シンプルかつ効率的に構築できます。
もしロジスティクス、モビリティ、デリバリー関連の製品を開発しているなら、このアーキテクチャはぜひ検討すべき構成です。