kdb+ का भविष्य?

 (timestored.com)
1 पॉइंट द्वारा GN⁺ 2024-08-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें

उपयोग के मामले

  • ऐतिहासिक market data का स्टोरेज और विश्लेषण

    • उदाहरण: MS Horizon, Citi CloudKDB, UBS Krypton

  • लोकल quant विश्लेषण

    • उदाहरण: liquidity analysis, PnL analysis, customer-wise profitability analysis

  • रियल-टाइम streaming calculation engine

    • उदाहरण: streaming VWAP, streaming TCA

  • distributed computing

    • उदाहरण: stock portfolio का margin calculation या risk analysis

विकल्प

ऐतिहासिक market data - kdb+ के विकल्प

  • नई database technologies

    • Clickhouse, QuestDB

  • cloud vendors

    • Bigquery, Redshift

  • market data services

    • अधिकांश users को kdb+ की "speed" की ज़रूरत नहीं होती
    • अधिकांश internal bank platforms kdb+ की speed का पूरा उपयोग नहीं करते
    • competitors भी अब काफ़ी तेज़ हैं

अपेक्षित परिणाम

  • kdb+ मौजूदा customers को बनाए रख सकता है, लेकिन cloud-native या कुछ और चाहने वाली दूसरे स्तर की कंपनियाँ नहीं जीत पाएगा

लोकल quant विश्लेषण - विकल्प

  • Python
    • DuckDB, Polars, PyKX, dataframe/modin आदि

अपेक्षित परिणाम

  • DuckDB या Polars जीतेंगे, क्योंकि वे मुफ़्त हैं

रियल-टाइम streaming / distributed computing

  • kdb+ की सबसे बड़ी ताकत streaming और historical data को एक ही मॉडल में जोड़ना है
  • लेकिन इसके लिए अनुभवी लोगों की ज़रूरत होती है, नहीं तो चीज़ें उलझनभरी हो जाती हैं

अपेक्षित परिणाम

  • kdb+ नहीं जीतेगा। Kafka पहले ही mindshare हासिल कर चुका है, और flink/risingwave जैसे tools उभरते सितारे हैं

सारांश

  • kdb+ एक शानदार technology है, लेकिन यह 15 साल पहले के ही स्तर पर है

  • बेहतरीन open source कंपनियाँ kdb+ के ideas को अपना चुकी हैं

    • Parquet/Iceberg, kdb+ का disk format है
    • Apache Arrow, kdb+ का memory format है
    • Kafka के log/replay/ksql concepts भी मिलते-जुलते हैं
    • QuestDB, DuckDB, Clickhouse सभी asof join को support करते हैं

  • competitors ने kdb+ के सबसे अच्छे हिस्सों को standardize कर दिया है

    • उदाहरण: Snowflake, Dremio, Confluent, Databricks सभी Apache Iceberg/parquet को support करते हैं
    • QuestDB, DuckDB, Python सभी parquet को native रूप से support करते हैं

  • KX को ये चार काम करने चाहिए

    • मुफ़्त version देना चाहिए, और कम लागत वाले licenses उपलब्ध कराने चाहिए
    • core product को शानदार बनाना चाहिए
    • learning curve को कम करना चाहिए
    • इसे ज़्यादा लोकप्रिय बनाना चाहिए

GN⁺ का सार

  • kdb+ अब भी एक शक्तिशाली technology है, लेकिन competitors तेज़ी से इसकी बराबरी कर रहे हैं
  • मुफ़्त और open source tools लोकप्रिय हो रहे हैं, इसलिए kdb+ की market share घटने की संभावना है
  • kdb+ को ज़्यादा लोकप्रिय बनाने के लिए मुफ़्त version, कम learning curve और मज़बूत core product की ज़रूरत है
  • समान features वाले products में DuckDB, Polars, QuestDB आदि शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-04
Hacker News की राय

  • TimeScale एक Postgres extension है, इसलिए SQL features को ज्यों का त्यों इस्तेमाल किया जा सकता है

    • इसमें column store compression है, इसलिए यह बहुत तेज़ चलता है
    • इसे financial applications में इस्तेमाल करने का अनुभव रहा है, और यह बड़ी मात्रा में data को तेज़ी से प्रोसेस कर सकता है
    • Slack पर support अच्छा है, और व्यक्तिगत रूप से संतोषजनक लगा
    • kdb महंगा है, और इसकी language अक्षम है

  • kdb+ इस्तेमाल करने के अनुभव के कारण 2 हफ्तों में नौकरी छोड़ देने का एक मामला

    • language design और debugging असुविधाजनक हैं, और coding conventions नहीं हैं या बहुत कम हैं
    • company culture भी समस्या है, और code अच्छी तरह documented नहीं है
    • पूरा stack पुराना है, और qStudio से Excel में data कॉपी करके graph बनाने का तरीका इस्तेमाल होता है
    • Docker और k8s का इस्तेमाल न करके सीधे server पर deploy करना एक सकारात्मक बात है
    • kdb एक tool से ज़्यादा हथियार की तरह इस्तेमाल होता है

  • kdb+ की vertical integration capability इसका फ़ायदा है

    • एक ही technology कई तरह की भूमिकाएँ निभा सकती है
    • Q language, data serialization, और IPC features होने से custom systems बनाए जा सकते हैं
    • लेकिन kdb+ proprietary और महंगा है, इसलिए नए projects में इसे अपनाना मुश्किल है

  • kdb+ का free version नहीं होने से इसकी पहचान कम है

    • finance क्षेत्र में kdb+ इस्तेमाल करने का अनुभव रहा है, और इसका design और simplicity Unix philosophy जैसा है
    • finance industry छोड़ने के बाद भी kdb+ इस्तेमाल करना चाहते थे, लेकिन free version न होने से असुविधा हुई

  • q/kdb+ से नफ़रत होने के कारण अपनी language विकसित करने का एक मामला

    • Python इस समय सबसे ज़्यादा इस्तेमाल हो रहा है

  • kdb+ का इस्तेमाल करके startup सफलतापूर्वक चलाने का अनुभव

    • team को expand करने के लिए इसे FOSS में फिर से लिखना पड़ा
    • लगता है कि kx को platform को open source में बदलना चाहिए

  • kdb+ दिलचस्प है, लेकिन इसकी कीमत बहुत ज़्यादा है

    • यह कई संभावित ग्राहकों को नज़रअंदाज़ कर रहा है

  • ClickHouse के बारे में कुछ सुधार

    • ClickHouse 2016 से open source है, और 2009 से इसका development हो रहा है
    • ClickHouse तीनों use cases को संभाल सकता है
    • ClickHouse 2019 में ASOF JOIN पेश करने वाला पहला SQL database था

  • Python इस समय हावी है, लेकिन technical debt की वजह से नए platform पर जाना मुश्किल है

    • नए development projects में Python का इस्तेमाल होगा

  • kdb+ developer के रूप में बहुत पैसा कमाया जा सकता है या नहीं, इस पर सवाल

    • कुछ साल पहले $1 million annual salary वाले positions मौजूद थे