▲

GN⁺: kdb+의 미래?

 (timestored.com)
1P by neo 4달전 | favorite | 댓글 1개

사용 사례

  • 역사적 시장 데이터 저장 및 분석

    • 예: MS Horizon, Citi CloudKDB, UBS Krypton

  • 로컬 퀀트 분석

    • 예: 유동성 분석, PnL 분석, 고객별 수익성 분석

  • 실시간 스트리밍 계산 엔진

    • 예: 스트리밍 VWAP, 스트리밍 TCA

  • 분산 컴퓨팅

    • 예: 주식 포트폴리오의 마진 계산 또는 리스크 분석

대안

역사적 시장 데이터 - kdb+ 대안

  • 새로운 데이터베이스 기술

    • Clickhouse, QuestDB

  • 클라우드 벤더

    • Bigquery, Redshift

  • 시장 데이터 서비스

    • 대부분의 사용자는 kdb+의 "속도"가 필요하지 않음
    • 대부분의 내부 은행 플랫폼은 kdb+의 속도를 완전히 활용하지 않음
    • 경쟁자들도 이제 충분히 빠름

예상 결과

  • kdb+는 기존 고객을 유지할 수 있지만, 클라우드 네이티브 또는 다른 것을 원하는 2차 기업들은 얻지 못할 것임

로컬 퀀트 분석 - 대안

  • Python
    • DuckDB, Polars, PyKX, dataframe/modin 등

예상 결과

  • DuckDB 또는 Polars가 승리할 것임. 이유는 무료이기 때문임

실시간 스트리밍 / 분산 컴퓨팅

  • kdb+의 가장 큰 강점은 스트리밍과 역사적 데이터를 하나의 모델로 결합하는 것임
  • 그러나 경험이 풍부한 사람이 필요하거나, 그렇지 않으면 혼란스러워짐

예상 결과

  • kdb+가 승리하지 않을 것임. Kafka가 이미 마인드셰어를 차지했고, flink/risingwave 등이 떠오르는 별임

요약

  • kdb+는 놀라운 기술이지만, 15년 전과 동일한 수준임

  • 최고의 오픈 소스 기업들이 kdb+의 아이디어를 훔쳐갔음

    • Parquet/Iceberg는 kdb+의 디스크 형식
    • Apache Arrow는 kdb+의 메모리 형식
    • Kafka의 로그/재생/ksql 개념도 유사함
    • QuestDB, DuckDB, Clickhouse는 모두 asof 조인을 지원함

  • 경쟁자들은 kdb+의 최고의 부분을 표준화했음

    • 예: Snowflake, Dremio, Confluent, Databricks는 모두 Apache Iceberg/parquet을 지원함
    • QuestDB, DuckDB, Python은 모두 parquet을 네이티브로 지원함

  • KX는 다음 네 가지를 해야 함

    • 무료 버전을 제공하고, 적은 비용으로 사용할 수 있는 라이선스를 제공해야 함
    • 핵심 제품을 훌륭하게 만들어야 함
    • 학습 곡선을 줄여야 함
    • 더 인기를 끌어야 함

GN⁺의 정리

  • kdb+는 여전히 강력한 기술이지만, 경쟁자들이 빠르게 따라잡고 있음
  • 무료 및 오픈 소스 도구들이 인기를 끌고 있어, kdb+의 시장 점유율이 감소할 가능성이 큼
  • kdb+가 더 인기를 끌기 위해서는 무료 버전 제공, 학습 곡선 완화, 핵심 제품 강화가 필요함
  • 유사한 기능을 가진 제품으로는 DuckDB, Polars, QuestDB 등이 있음
▲
neo 4달전  [-]
Hacker News 의견

  • TimeScale는 Postgres 확장으로, SQL 기능을 그대로 사용할 수 있음

    • 컬럼 저장소로 압축 기능이 있어 매우 빠르게 작동함
    • 금융 애플리케이션에서 사용한 경험이 있으며, 많은 양의 데이터를 빠르게 처리할 수 있음
    • Slack에서 지원이 좋으며, 개인적으로 만족스러움
    • kdb는 비용이 많이 들고, 언어가 비효율적임

  • kdb+ 사용 경험으로 인해 2주 만에 퇴사한 사례

    • 언어 디자인과 디버깅이 불편하며, 코딩 규칙이 없거나 부족함
    • 회사 문화도 문제로, 코드가 잘 문서화되지 않음
    • 전체 스택이 구식이며, qStudio에서 Excel로 데이터를 복사해 그래프를 그리는 방식 사용
    • Docker와 k8s를 사용하지 않고 서버에 직접 배포하는 점은 긍정적임
    • kdb는 도구라기보다는 무기처럼 사용됨

  • kdb+의 수직 통합 기능이 장점임

    • 하나의 기술로 여러 가지 역할을 수행할 수 있음
    • Q 언어, 데이터 직렬화, IPC 기능이 있어 맞춤형 시스템을 구축할 수 있음
    • 그러나 kdb+가 독점적이고 비싸서 새로운 프로젝트에 도입하기 어려움

  • kdb+의 무료 버전이 없어서 인지도가 낮음

    • 금융 분야에서 kdb+를 사용한 경험이 있으며, 디자인과 단순함이 Unix 철학과 유사함
    • 금융업을 떠난 후에도 kdb+를 사용하고 싶었으나, 무료 버전이 없어 불편함

  • q/kdb+를 싫어해서 자체 언어를 개발한 사례

    • Python이 현재 가장 많이 사용됨

  • kdb+를 사용해 스타트업을 성공적으로 운영한 경험

    • 팀 확장을 위해 FOSS로 재작성해야 했음
    • kx가 플랫폼을 오픈 소스로 전환해야 한다고 생각함

  • kdb+는 흥미롭지만 가격이 너무 비쌈

    • 많은 잠재 고객을 무시하고 있음

  • ClickHouse에 대한 몇 가지 수정 사항

    • ClickHouse는 2016년부터 오픈 소스였으며, 2009년부터 개발됨
    • ClickHouse는 세 가지 사용 사례 모두를 처리할 수 있음
    • ClickHouse는 2019년에 ASOF JOIN을 도입한 첫 번째 SQL 데이터베이스였음

  • Python이 현재 우세하지만, 기술 부채로 인해 새로운 플랫폼으로의 전환이 어려움

    • 새로운 개발 프로젝트는 Python을 사용할 것임

  • kdb+ 개발자로 큰 돈을 벌 수 있는지에 대한 질문

    • 몇 년 전에는 연봉 1백만 달러를 받는 포지션이 있었음
답변달기