kdb+の未来？

 (timestored.com)
1 ポイント 投稿者 GN⁺ 2024-08-04 | 1件のコメント | WhatsAppで共有

ユースケース

  • 過去の市場データの保存と分析

    • 例: MS Horizon, Citi CloudKDB, UBS Krypton

  • ローカルなクオンツ分析

    • 例: 流動性分析、PnL分析、顧客別収益性分析

  • リアルタイムストリーミング計算エンジン

    • 例: ストリーミングVWAP、ストリーミングTCA

  • 分散コンピューティング

    • 例: 株式ポートフォリオのマージン計算またはリスク分析

代替案

過去の市場データ - kdb+の代替

  • 新しいデータベース技術

    • Clickhouse, QuestDB

  • クラウドベンダー

    • Bigquery, Redshift

  • 市場データサービス

    • ほとんどのユーザーはkdb+の「速度」を必要としていない
    • ほとんどの銀行内製プラットフォームはkdb+の速度を完全には活用していない
    • 競合も今では十分に高速

予想される結果

  • kdb+は既存顧客を維持できるかもしれないが、クラウドネイティブや別のものを求める二次的な企業は獲得できないだろう

ローカルなクオンツ分析 - 代替

  • Python
    • DuckDB, Polars, PyKX, dataframe/modin など

予想される結果

  • DuckDBまたはPolarsが勝つだろう。無料だからだ

リアルタイムストリーミング / 分散コンピューティング

  • kdb+の最大の強みは、ストリーミングと過去データを1つのモデルで結び付けること
  • しかし、経験豊富な人材が必要で、そうでなければ混乱しやすい

予想される結果

  • kdb+は勝てないだろう。Kafkaがすでにマインドシェアを獲得しており、flink/risingwave などが新星として台頭している

要約

  • kdb+は驚くべき技術だが、15年前と同じレベルにとどまっている

  • 最高のオープンソース企業がkdb+のアイデアを持っていった

    • Parquet/Icebergはkdb+のディスク形式
    • Apache Arrowはkdb+のメモリ形式
    • Kafkaのログ/再生/ksqlの概念も似ている
    • QuestDB, DuckDB, Clickhouse はすべて asof join をサポートしている

  • 競合はkdb+の最良の部分を標準化した

    • 例: Snowflake, Dremio, Confluent, Databricks はすべて Apache Iceberg/parquet をサポートしている
    • QuestDB, DuckDB, Python はすべて parquet をネイティブサポートしている

  • KXは次の4つを行う必要がある

    • 無料版を提供し、低コストで使えるライセンスを提供すべき
    • コア製品を優れたものにすべき
    • 学習曲線を下げるべき
    • もっと人気を高めるべき

GN⁺のまとめ

  • kdb+は依然として強力な技術だが、競合が急速に追いついている
  • 無料およびオープンソースのツールが人気を集めており、kdb+の市場シェアが低下する可能性が高い
  • kdb+がより人気を得るには、無料版の提供、学習曲線の緩和、コア製品の強化が必要
  • 類似機能を持つ製品としては DuckDB, Polars, QuestDB などがある

関連記事

1件のコメント

 
GN⁺ 2024-08-04
Hacker Newsのコメント

  • TimeScaleはPostgres拡張で、SQLの機能をそのまま使える

    • カラムストアとして圧縮機能があり、非常に高速に動作する
    • 金融アプリケーションで使った経験があり、大量のデータを高速に処理できる
    • Slackでのサポートが手厚く、個人的に満足している
    • kdbはコストが高く、言語も非効率的だ

  • kdb+を使った経験が原因で、2週間で退職した事例

    • 言語設計とデバッグが不便で、コーディング規約もないか不十分だった
    • 企業文化にも問題があり、コードがきちんと文書化されていない
    • スタック全体が古く、qStudioからExcelにデータをコピーしてグラフを描くやり方を使っていた
    • Dockerやk8sを使わず、サーバーに直接デプロイする点は肯定的に見ている
    • kdbはツールというより武器のように使われていた

  • kdb+の垂直統合機能が強み

    • 1つの技術でさまざまな役割を担える
    • Q言語、データシリアライズ、IPC機能があり、カスタムシステムを構築できる
    • しかし、kdb+はプロプライエタリで高価なため、新規プロジェクトに導入しにくい

  • kdb+には無料版がないため知名度が低い

    • 金融分野でkdb+を使った経験があり、その設計とシンプルさはUnix哲学に近い
    • 金融業界を離れた後もkdb+を使いたかったが、無料版がなく不便だった

  • q/kdb+が嫌いで独自言語を開発した事例

    • 現在もっとも使われているのはPython

  • kdb+を使ってスタートアップを成功させた経験

    • チーム拡大のためにFOSSとして書き直す必要があった
    • kxはプラットフォームをオープンソース化すべきだと思う

  • kdb+は興味深いが、価格が高すぎる

    • 多くの潜在顧客を無視している

  • ClickHouseに関するいくつかの補足

    • ClickHouseは2016年からオープンソースで、2009年から開発されている
    • ClickHouseは3つのユースケースすべてに対応できる
    • ClickHouseは2019年にASOF JOINを導入した最初のSQLデータベースだった

  • 現在はPythonが優勢だが、技術的負債のため新しいプラットフォームへの移行は難しい

    • 新しい開発プロジェクトではPythonを使うことになるだろう

  • kdb+開発者として大金を稼げるのかという質問

    • 数年前には年収100万ドルのポジションがあった