永続化と処理

Center

Center は、アプリケーション・ファブリックにおける処理、キャッシュ、永続化のノードです。

ファブリック内での役割

大容量・高速・多様なデータの信頼できる唯一の情報源

Center は、受信イベントが構造化された状態になり、業務ロジックがデータの近くで適用され、処理結果がアプリケーション、Gateway、他の Center、あるいは下流システムへ公開される場所です。

Center がデータを取り込み、現在状態と履歴を保持し、結果を公開する仕組み

難しいデータ課題に応える

3forge の Center は、ソフトウェアエンジニアが日常的に直面するデータ課題に応える機能を備えています。

  • リアルタイム・ストリーミング分析
  • 追加コード不要のレプリケーション、シャーディング、Webロードバランシング
  • 即時整合性を保ったヒストリカルテーブルへのストリーミング挿入
  • ヒストリカルテーブルの疎な更新
  • 高度なコンフレーション
  • スキーマの自己検出
  • リモートプロシージャコール
  • テストとコードカバレッジのツール
  • クエリプランナ
  • マルチスレッドクエリ
  • データの再投入が不要なヒストリカルスキーマ変更

これらの機能は、3つのアーキテクチャ上の機能によって提供されます。

インメモリキャッシュ型カラムナSQLデータベース

Center が接続するすべてのソースは、メモリ上に保持され SQL で照会できるビジネスの一つのライブな全体像に集約されます。アプリケーションはストリームを解釈する必要がなくなり、状態を読むだけで済みます。

カラムナ型かつインメモリであるため、デスクが求めるビューは、問いが届いた時点ですでに計算済みです。問いを受けてから組み立てるのではありません。

一つのSQL方言が両方のストアをカバーするため、クエリは対象の行がまだメモリ上にあるのか、すでにディスク上にあるのかを意識する必要がありません。

> 200万

リアルタイムDBスループット(ops/秒)

< 100 µs

リアルタイムDBレイテンシ

ペタバイト級ヒストリカル・カラムナSQLデータベース

最も高いクエリ性能はリアルタイムデータベースで得られますが、3forge は数兆行を保持できるカラムナ型のヒストリカルテーブルも提供します。ディスクに永続化されパーティショニングに対応するこれらのテーブルは、大量のデータを高速に格納し素早く取り出すために設計されており、しかもリアルタイムテーブルと同じSQL構文で扱えます。

ヒストリカルテーブルのデータは照会してリアルタイムテーブルへ読み込むことができ、そこでは他テーブルとの結合を含む、あらゆるクエリ最適化が利用できます。

  • 多数のカラムと重量級のデータ型(blob フィールドなど)
  • スキーマ管理。ヒストリカルパーティションに影響を与えずにカラムを追加・削除・変更できます。パーティションカラムは不変のため、テーブル設計時の計画が重要です。HDB は古いパーティションを新しいスキーマへシームレスに対応づけ、履歴の整合性を保ちます
  • 行レベルの操作。パーティション最適化を保ったまま UPDATE と DELETE を実行できます。パーティション内の大きな変更は自動的に再最適化され、ソートインデックスがクエリ性能をさらに高めます

システムは最適化の際、実際のデータ利用状況に基づき、ディスク効率とクエリ速度のためにパーティション単位でストレージ型を動的に適応させます。各カラムは最適な性能が得られるよう次のように設定できます。

FLATINT、FLOAT、DOUBLE などの固定長型
VARSIZESTRING、BINARY などの可変長型(最大1TB)
BITMAPカーディナリティの低い文字列に有効
PARTITION行を独立したパーティションへ整理

> 10兆

ヒストリカルDB容量(行)

> 1,000

ヒストリカルDBカラム数

10兆行とはどれくらいか

米国市場の株式取引・気配の統合フィードである SIP は、1営業日あたり約25億メッセージを運びます。1行が取引と気配を含む1件の統合SIPメッセージだとすると、10兆行は4,000営業日、およそ16年分に相当します。

オプション市場データははるかに高密度で、活況時の OPRA では1日あたり約2,000億件の気配更新が発生します。その勢いでも、10兆件の気配更新はオプション気配トラフィックの約2.5か月分です。

複合イベント処理エンジン

3forge はリアルタイムテーブルとデータベースネイティブの機能を提供し、データ更新に基づいて業務ロジックをその場で実行できるようにします。データベースネイティブのトリガーが、ソーステーブルの変化に応じて情報を集約、フィルタ、結合、拡充、変換でき、挿入・更新・削除に応じてカスタムロジックを実行できます。

活用パターン

Center の活用方法

データを保持するだけなら簡単です。ここでは、データ量が増えても Center が高速であり続ける仕組み、当日のデータが中断なく履歴になる仕組み、そして業務ロジックがデータベースの外ではなく内部で実行される仕組みを紹介します。

大量負荷への最適化

3forge の Center は、データ伝送における速度の要求と、そのままでは流れを遅くしかねない技術的制約とを両立させるために、いくつかの高度な手法を用います。

デルタベース処理

更新のたびにデータセット全体を再処理・再送信するのではなく、Center は変更分だけを扱います。これによりリアルタイムシステムの性能と効率が大きく向上します。

デルタベース処理:変更された行だけを再処理・再送信

サマリー化

Center は平均、合計、件数、最小、最大といった通常およびデルタベースの集計値を計算・保持でき、データ量を圧縮し、傾向分析や移動平均などの時系列分析を支えます。

サマリー化:ソース行を通常およびデルタベースの集計値に集約

コンフレーション

階層アーキテクチャ間でデータを複製する際、Center はすべての更新を送るか、合意された間隔で最新の1件だけを送るかを設定できます。中間値を捨てることで、下流の利用者の負担が大幅に下がります。

コンフレーション:中間の更新を破棄し、一定間隔で最新値のみを送信

デコレーション

Center はデータ操作時に呼び出されるイベント駆動トリガーによる自動デコレーションに対応し、テーブルレベルの変化に応じた動的な拡充、検証、伝播を可能にします。

デコレーション:イベント駆動トリガーが変化する行を拡充

リアルタイムデータのアーカイブ

ストリーミング更新は、イベント駆動、バッチ、タイマー駆動の方式でリアルタイムテーブルからヒストリカルデータベースへ移されます。そのため、稼働を止めることなく履歴が常に最新に保たれます。

エクスポートも、ステージングも、再ロードも不要です。今日のティックがその場で昨年の履歴になるため、一つのクエリで現在と過去を同時に読むことができます。

アーカイブ:イベント、バッチ、タイマーによりリアルタイムテーブルからヒストリカルデータベースへ移行

複合イベント処理

プラットフォームには6種類のトリガーが標準で備わっており、これがイベント処理エンジンの語彙のすべてです。

  • 集約:集約テーブルの作成と更新
  • 射影:フィルタされたテーブルの生成
  • 結合:結合テーブルの作成
  • デコレート:別テーブルの情報でデータを拡充
  • Relay:3forge Relay 経由でのメッセージ送信
  • AmiScript:挿入・更新・削除のたびにカスタムスクリプトを実行

トリガーは SQL で宣言するため、イベントロジックはデータとともに存在します。デプロイ、バージョン管理、同期維持が必要な別サービスに置く必要はありません。

-- スクリプトトリガー
CREATE TRIGGER <trigger_name> OFTYPE AMISCRIPT ON
  <table_name> [PRIORITY priority] USE...

-- 集約トリガー
CREATE TRIGGER <trigger_name> OFTYPE AGGREGATE ON
  <source_table>,<target_table> USE...

-- 射影トリガー
CREATE TRIGGER <trigger_name> OFTYPE PROJECTION ON
  <source_tables>,<target_table> USE...

トリガーの実際の働き

リアルタイム P&L グリッドは一つの計算ではなく計算の連鎖であり、データの変化に応じて各トリガーがそれぞれの役割を果たします。

  • 3forge は約定のドロップコピーを銘柄データと結合して正規化
  • 3forge は約定を対象銘柄にフィルタし、日中の考慮事項を集約
  • 3forge は銘柄と為替レートの受信マーケットデータを保存し、必要な価格だけを残すようフィルタして専用テーブルへ射影
  • 3forge は日初の P&L と日中の P&L を組み合わせ、グリッドへ射影
  • 3forge は更新された価格と為替レートでグリッドデータをデコレート
リアルタイム P&L グリッドを構築する CEP トリガーの連鎖:結合、フィルタ、集約、射影、デコレート
ユーザーレイアウト上でリアルタイム P&L グリッドを構築する CEP ロジックの例。

配信レイヤー

Center が状態を保持し、Gateway がそれを届ける。

ファブリックが複数の Center へ広がるにつれ、利用者には物理的なトポロジーを意識せずにアクセスできる安定した手段が必要になります。