KDB+/Q：ティックデータベースの言語

KDB+ は列指向の時系列データベースであり、Q はそのベクトル言語です。ティックデータの保存、結合、ローリング分析において、行ごとのループより列のスキャンが優れる場面で、セルサイド・バイサイド双方の企業がこれを採用してきました。

そのパフォーマンスは、列指向レイアウト、メモリマッピングの積極的な活用、そしてハードウェアに近いレベルで実装されたベクトル演算プリミティブから生まれます。汎用の OLTP の代替ではなく、追記が多い時系列データに最適化されたものです。

Q は簡潔で、右から左に評価されます。ベクトルはネイティブに扱われ、ループも存在しますが、ホットパスでは避けられます。テーブルは列の辞書として表現され、これはティックデータの保存形式とよく合致します。

prices: 100.5 101.2 99.8
avg prices
deltas prices

典型的なパターンとしては、ティッカープラントがフィードを取り込み、サブスクライバーに配信します。リアルタイムデータベースは現在のセッションを保持し、ヒストリカルデータベースはパーティション分割された過去データをディスクに保存します。日次バッチ処理が RT のデータを HDB のパーティションへロールします。

select last price by sym from trades where time > .z.t - 00:05

暗号資産市場は決してクローズしないので、「セッション」の境界は取引所のベルではなく、運用上の選択にすぎません。

企業は KDB+ をサーベイランスダッシュボード、クオート分析、研究用データセットに利用しています。企業名や導入形態はさまざまですが、パターンとしてはティックデータや注文データを高速にスライス＆ダイスすることに尽きます。

暗号資産の取引所は継続的にデータを生成するため、保持・リプレイ・コンプライアンス向けのエクスポートは前もって計画しておきましょう。

商用ライセンスと専門人材の確保は、実際にかかるコストです。オープンな代替手段（ClickHouse、Timescale、QuestDB、Parquet 上の DuckDB）は、エコシステムとの適合度を価格と引き換えにします。ベンダーのスライドではなく、自分たちのクエリの組み合わせでベンチマークしましょう。

多くのチームは Kafka や Redpanda を、列指向ストレージや SQL エンジンと組み合わせています。KDB+ から得られる不変の原則はいまも当てはまります。時間でパーティション分割し、スキーマを厳格に保ち、取引所のタイムスタンプからクエリ結果までのエンド・トゥ・エンドの遅延を測定することです。

GaiaEx の API 利用者は、公開されているならサーバーのタイムスタンプとシーケンス識別子をログに記録すべきです。推測よりも突き合わせのほうが確実です。