L’avenir de kdb+ ?

 (timestored.com)
1 points par GN⁺ 2024-08-04 | 1 commentaires | Partager sur WhatsApp

Cas d’usage

  • Stockage et analyse de données de marché historiques

    • Ex. : MS Horizon, Citi CloudKDB, UBS Krypton

  • Analyse quantitative locale

    • Ex. : analyse de liquidité, analyse du PnL, analyse de rentabilité par client

  • Moteur de calcul en streaming temps réel

    • Ex. : VWAP en streaming, TCA en streaming

  • Calcul distribué

    • Ex. : calcul de marge ou analyse des risques pour des portefeuilles d’actions

Alternatives

Données de marché historiques - alternatives à kdb+

  • Nouvelles technologies de base de données

    • Clickhouse, QuestDB

  • Fournisseurs cloud

    • Bigquery, Redshift

  • Services de données de marché

    • La plupart des utilisateurs n’ont pas besoin de la « vitesse » de kdb+
    • La plupart des plateformes bancaires internes n’exploitent pas pleinement la vitesse de kdb+
    • Les concurrents sont désormais eux aussi suffisamment rapides

Résultat attendu

  • kdb+ peut conserver ses clients existants, mais ne gagnera probablement pas les entreprises de second rang qui veulent du cloud native ou autre chose

Analyse quantitative locale - alternatives

  • Python
    • DuckDB, Polars, PyKX, dataframe/modin, etc.

Résultat attendu

  • DuckDB ou Polars l’emporteront, parce qu’ils sont gratuits

Streaming temps réel / calcul distribué

  • La plus grande force de kdb+ est de combiner streaming et données historiques dans un seul modèle
  • Mais cela demande des personnes expérimentées, sinon cela devient vite confus

Résultat attendu

  • kdb+ ne l’emportera pas. Kafka a déjà capté le mindshare, et flink/risingwave sont des étoiles montantes

Résumé

  • kdb+ est une technologie remarquable, mais elle en est toujours au même niveau qu’il y a 15 ans

  • Les meilleures entreprises open source ont repris les idées de kdb+

    • Parquet/Iceberg correspondent au format disque de kdb+
    • Apache Arrow correspond au format mémoire de kdb+
    • Les concepts de log/replay/ksql de Kafka sont également similaires
    • QuestDB, DuckDB, Clickhouse prennent tous en charge les jointures asof

  • Les concurrents ont standardisé les meilleurs aspects de kdb+

    • Ex. : Snowflake, Dremio, Confluent et Databricks prennent tous en charge Apache Iceberg/parquet
    • QuestDB, DuckDB et Python prennent tous en charge parquet nativement

  • KX doit faire les quatre choses suivantes

    • Proposer une version gratuite et des licences utilisables à faible coût
    • Rendre son produit principal excellent
    • Réduire la courbe d’apprentissage
    • Gagner en popularité

La synthèse de GN⁺

  • kdb+ reste une technologie puissante, mais les concurrents rattrapent rapidement leur retard
  • Les outils gratuits et open source gagnent en popularité, ce qui augmente fortement le risque d’un recul de la part de marché de kdb+
  • Pour devenir plus populaire, kdb+ doit proposer une version gratuite, réduire la courbe d’apprentissage et renforcer son produit principal
  • Parmi les produits aux fonctionnalités similaires, on trouve DuckDB, Polars et QuestDB

À lire aussi

1 commentaires

 
GN⁺ 2024-08-04
Avis Hacker News

  • TimeScale est une extension Postgres, ce qui permet d’utiliser directement les fonctionnalités SQL

    • Il dispose d’une compression en stockage colonnaire, ce qui le rend très rapide
    • Je l’ai utilisé dans des applications financières, et il peut traiter rapidement de grands volumes de données
    • Le support sur Slack est bon, et j’en suis personnellement satisfait
    • kdb coûte cher et son langage est inefficace

  • Un cas de démission au bout de deux semaines à cause de l’expérience avec kdb+

    • Le design du langage et le débogage sont peu pratiques, et les conventions de codage sont inexistantes ou insuffisantes
    • La culture d’entreprise pose aussi problème, car le code est mal documenté
    • Toute la stack est vieillissante, et ils utilisent qStudio puis copient les données dans Excel pour tracer des graphiques
    • Le fait de ne pas utiliser Docker ni k8s et de déployer directement sur les serveurs est vu comme un point positif
    • kdb est utilisé davantage comme une arme que comme un outil

  • Les capacités d’intégration verticale de kdb+ constituent un avantage

    • Une seule technologie peut remplir plusieurs rôles
    • Avec le langage Q, la sérialisation des données et les fonctions IPC, il est possible de construire un système sur mesure
    • Cependant, comme kdb+ est propriétaire et coûteux, il est difficile de l’introduire dans de nouveaux projets

  • L’absence de version gratuite de kdb+ limite sa notoriété

    • Quelqu’un l’a utilisé dans la finance et estime que sa conception et sa simplicité rappellent la philosophie Unix
    • Même après avoir quitté la finance, il voulait continuer à utiliser kdb+, mais l’absence de version gratuite était contraignante

  • Un cas où quelqu’un a tellement détesté q/kdb+ qu’il a développé son propre langage

    • Python est aujourd’hui le plus utilisé

  • Expérience d’une startup exploitée avec succès grâce à kdb+

    • Il a fallu réécrire en FOSS pour agrandir l’équipe
    • Selon lui, kx devrait faire évoluer la plateforme vers l’open source

  • kdb+ est intéressant, mais son prix est beaucoup trop élevé

    • Cela revient à ignorer de nombreux clients potentiels

  • Quelques corrections à propos de ClickHouse

    • ClickHouse est open source depuis 2016 et est développé depuis 2009
    • ClickHouse peut couvrir les trois cas d’usage
    • ClickHouse a été la première base de données SQL à introduire ASOF JOIN en 2019

  • Python domine actuellement, mais la dette technique rend difficile la transition vers une nouvelle plateforme

    • Les nouveaux projets de développement utiliseront Python

  • Question sur la possibilité de gagner beaucoup d’argent comme développeur kdb+

    • Il y a quelques années, il existait des postes rémunérés 1 million de dollars par an