อนาคตของ kdb+?

 (timestored.com)
1 คะแนน โดย GN⁺ 2024-08-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในภาคการเงิน kdb+ เคยเป็นเครื่องมือทรงพลังสำหรับ การวิเคราะห์ข้อมูลตลาดย้อนหลัง และการคำนวณแบบเรียลไทม์ แต่ตอนนี้มีเทคโนโลยีทดแทนที่สุกงอมเพียงพอเกิดขึ้นในแต่ละกรณีการใช้งานแล้ว
  • ผู้ใช้จำนวนมากไม่ได้ต้องการความเร็วสูงสุดของ kdb+ และแพลตฟอร์มภายในของธนาคารก็ไม่สามารถดึงประสิทธิภาพนั้นออกมาได้เต็มที่ ทำให้ ความได้เปรียบด้านความเร็ว มีความชี้ขาดน้อยลง
  • การวิเคราะห์ควอนต์บนเครื่องโลคัลถูกขับเคลื่อนโดย ecosystem ของ Python แทบทั้งหมด และ เครื่องมือคอมมูนิตี้ฟรี อย่าง DuckDB และ Polars ก็ได้เปรียบกว่าในแง่การเรียนรู้และการย้ายงาน
  • การสตรีมแบบเรียลไทม์และการประมวลผลแบบกระจายยังเป็นจุดแข็งของ kdb+ แต่ความยากในการติดตั้งใช้งานและ mindshare ของ Kafka·Flink·RisingWave ที่แพร่หลายขึ้นทำให้ขยายตัวได้ยาก
  • หาก kdb+ จะอยู่รอดในระยะยาว ก็จำเป็นต้องมีช่องทางใช้งานฟรี การโฟกัสที่ผลิตภัณฑ์หลัก การลดความชันของการเรียนรู้ และความเป็นมวลชนที่พอจะขยายออกนอกภาคการเงินได้

บทบาทที่ kdb+ รับผิดชอบมาในภาคการเงิน

  • kdb+ ถูกใช้งานในหลายระบบและงานวิเคราะห์ของภาคการเงิน
    • การจัดเก็บและวิเคราะห์ข้อมูลตลาดย้อนหลัง: ตัวอย่างเช่น MS Horizon, Citi CloudKDB, UBS Krypton
    • การวิเคราะห์ควอนต์บนเครื่องโลคัล: การวิเคราะห์สภาพคล่อง, การวิเคราะห์ PnL, การวิเคราะห์ความสามารถทำกำไรแยกตามลูกค้า
    • เอนจินคำนวณสตรีมมิงแบบเรียลไทม์: Streaming VWAP, Streaming TCA
    • การประมวลผลแบบกระจาย: งานอย่างการคำนวณมาร์จินพอร์ตหุ้นและการวิเคราะห์ความเสี่ยง ที่ต้องแบ่งข้อมูลไปคำนวณแล้วรวมกลับมา

ข้อมูลตลาดย้อนหลัง: ลูกค้าเดิมยังอยู่ แต่การขยายลูกค้าใหม่ทำได้ยาก

  • ผู้ใช้จำนวนมากต้องการคิวรีข้อมูลขนาดใหญ่เพื่อสร้าง minute bar ทำ asof join หรือทำ การวิเคราะห์อนุกรมเวลา ที่ซับซ้อนยิ่งขึ้น
  • ตัวเลือกคู่แข่งขยายกว้างไปถึงฐานข้อมูลใหม่อย่าง ClickHouse และ QuestDB, ผู้ให้บริการคลาวด์อย่าง BigQuery และ Redshift, รวมถึง Market Data as a Service
  • มี 3 เหตุผลที่ทำให้ความได้เปรียบด้านความเร็วของ kdb+ ไม่ได้ชี้ขาดเหมือนเมื่อก่อน
    • ผู้ใช้ส่วนใหญ่ไม่ได้ต้องการ “ความเร็ว” ระดับของ kdb+
    • แพลตฟอร์มภายในของธนาคารส่วนใหญ่ไม่สามารถดึงความเร็วของ kdb+ ออกมาได้เต็มที่
    • ผลิตภัณฑ์คู่แข่งตอนนี้เร็วพอแล้ว
  • ClickBench benchmark ถูกยกเป็นตัวอย่างของ benchmark ที่เปิดเผยอย่างโปร่งใส
  • kdb+ อาจรักษา ลูกค้าเดิม ไว้ได้ แต่บริษัทระดับ tier 2 ต้องการทางเลือกแบบ cloud-native หรือทางเลือกอื่น ๆ มากกว่า จึงไม่ง่ายที่จะได้ลูกค้าใหม่
  • ลูกค้าหลักเดิมต้องลงทุนสูงมากเพื่อสร้างแพลตฟอร์มของตนเอง และแพลตฟอร์ม kdb cloud เองก็ยังมีส่วนที่ต้องขัดเกลาอีก

การวิเคราะห์ควอนต์บนเครื่องโลคัล: ecosystem ของ Python เหนือกว่า

  • ทางเลือกสำหรับการวิเคราะห์ควอนต์บนเครื่องโลคัล ส่วนใหญ่จัดอยู่ในแนวทาง ยึด Python เป็นศูนย์กลาง
    • Python + DuckDB
    • Python + Polars
    • Python + PyKX
    • Python + dataframe, Modin เป็นต้น
  • ในพื้นที่นี้ Python ชนะไปแล้ว และคำถามที่เหลือใกล้เคียงกับว่าใครจะเป็นผู้ให้เครื่องมือเสริมด้านความเร็วที่ดีกว่า
  • เหตุผลที่ DuckDB และ Polars มีโอกาสสูงคือความเป็น ฟรี
    • ผู้ใช้ที่เริ่มตั้งแต่มหาวิทยาลัยมักเรียนด้วยเครื่องมือฟรี และมีโอกาสสูงที่จะไม่เปลี่ยนในภายหลัง
    • ควอนต์ที่ทำงานอยู่ในบริษัทก็ชอบเครื่องมือฟรีที่สามารถใช้วิเคราะห์ลักษณะเดียวกันต่อได้ในงานถัดไป
    • หากพึ่งพา kdb+ อย่างเดียว เมื่อย้ายไปบริษัทที่ไม่มี kdb+ ก็อาจสูญเสียทักษะส่วนใหญ่ของตนไป
  • kdb+ เป็นผลิตภัณฑ์เฉพาะทางที่ยังไม่สามารถขยายออกนอกวงการการเงินได้มาก มีต้นทุนเริ่มต้นสูง และมีจุดอ่อนเรื่องไวยากรณ์ที่ไม่คุ้นเคย

การสตรีมแบบเรียลไทม์และการประมวลผลแบบกระจาย: มีจุดแข็ง แต่ผู้ชนะยังไม่แน่ชัด

  • การสตรีมแบบเรียลไทม์และการประมวลผลแบบกระจายเป็นกรณีใช้งานที่ได้รับความนิยมน้อยกว่าของ kdb+ มาโดยตลอด และก็ไม่ใช่เหตุผลหลักที่ทำให้ปิดสัญญาได้
  • ความสามารถในการผสาน ข้อมูลเรียลไทม์และข้อมูลย้อนหลัง เข้าด้วยกันในโมเดลเดียว ถูกมองว่าเป็นจุดแข็งที่สุดของ kdb+
  • ในการติดตั้งใช้งานจริง บางครั้งต้องอาศัยคนที่เชี่ยวชาญมาก ไม่เช่นนั้นระบบอาจเละเทะได้
    • กรณีล้มเหลวแบบนี้ยังส่งผลลบต่อการที่หน่วยงานอื่นในบริษัทจะนำ kdb+ ไปใช้ในวัตถุประสงค์อื่นด้วย
  • ผู้ชนะสุดท้ายของพื้นที่นี้ยังไม่ชัดเจน แต่โอกาสที่จะเป็น kdb+ ดูค่อนข้างต่ำ
  • Kafka มีการติดตั้งใช้งานขนาดใหญ่และ mindshare ไปแล้ว และเทคโนโลยีอย่าง Flink กับ RisingWave ก็กำลังมาแรง

โอเพนซอร์สและการทำให้เป็นมาตรฐานกำลังดูดซับข้อดีของ kdb+

  • kdb+ เป็นเทคโนโลยีที่ยอดเยี่ยม แต่ในขณะที่มันยังยอดเยี่ยมอยู่ในระดับใกล้เคียงกับเมื่อ 15 ปีก่อน ecosystem รอบข้างกลับเปลี่ยนไปอย่างรวดเร็ว
  • บริษัทโอเพนซอร์สที่ดีหลายแห่งได้นำแนวคิดแกนหลักของ kdb+ ไปใช้
    • Parquet/Iceberg คล้ายกับฟอร์แมตดิสก์ของ kdb+ สำหรับการจัดเก็บแบบคอลัมน์ที่ปรับแต่งมาอย่างดี
    • ฟอร์แมต in-memory ของ Apache Arrow คล้ายกับฟอร์แมตคอลัมน์ in-memory ของ kdb+
    • แนวคิด log/replay/ksql ของ Kafka หากมองจากบางมุม ก็คล้ายกับ tplog
    • QuestDB, DuckDB, ClickHouse ล้วนรองรับ asof join
  • คู่แข่งไม่ได้เพียงเรียนรู้ข้อดีของ kdb+ แต่ยังทำให้มันกลายเป็นมาตรฐานด้วย
    • Snowflake, Dremio, Confluent, Databricks ต่างรองรับ Apache Iceberg และ Parquet แล้ว
    • QuestDB, DuckDB, Python ต่างรองรับ Parquet แบบเนทีฟแล้ว
  • เมื่อข้อมูลอยู่ในรูป Parquet เครื่องมือหลายตัวก็สามารถทำงานกับข้อมูลชุดเดียวกันได้
  • โครงสร้างการเปรียบเทียบจึงไม่ใช่ KX ปะทะคู่แข่งรายเดียวอีกต่อไป แต่เป็น KX ปะทะคู่แข่งหลายรายทั้งชุด

สิ่งที่ KX ต้องเปลี่ยน

  • มีการประเมินว่า KX กำลังเปลี่ยนแปลงอยู่ แต่ยังไม่เร็วพอ
  • การเปลี่ยนแปลงที่จำเป็นสรุปได้เป็น 4 ข้อ
    • ต้องมี เวอร์ชันฟรี ที่ใช้ได้หลายวัตถุประสงค์ และจัดทำไลเซนส์ที่สมเหตุสมผลเพื่อให้ลูกค้าที่มีงบจำกัดก็ใช้งานได้ง่าย
    • ต้องโฟกัสกับการทำให้ผลิตภัณฑ์หลักยอดเยี่ยม
    • MongoDB และ InfluxDB เป็นกรณีเปรียบเทียบว่าฐานข้อมูลที่ดีเพียงอย่างเดียวก็สามารถคว้าสัญญาใหญ่ได้
    • เมื่อเทียบกับผลิตภัณฑ์รายรอบอย่าง Delta และ kdb.ai ความสมบูรณ์ของผลิตภัณฑ์หลักสำคัญกว่า
  • ต้องลด เส้นโค้งการเรียนรู้ ที่ชันของ kdb+ ลงด้วย
    • หากจำเป็น ก็รวมถึงการเปลี่ยนภาษาและเทคโนโลยีเองด้วย
  • หากไม่สามารถกลายเป็นสิ่งที่คนวงกว้างเข้าถึงได้มากขึ้น ก็อาจนำไปสู่การถดถอยอย่างช้า ๆ
  • ไม่ใช่แค่ผลิตภัณฑ์เทคโนโลยีหลักเท่านั้น แต่ควรพิจารณาการเปลี่ยนแปลงในระดับบริษัทที่กว้างขึ้นด้วย รวมถึงต้นทุนและโครงการขนาดใหญ่อย่าง AI และงบการตลาดมหาศาล

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-04
ความคิดเห็นจาก Hacker News

  • อยากเสนอ TimescaleDB เป็นอีกตัวเลือกหนึ่งด้วย เพราะเป็นส่วนขยายของ PostgreSQL องค์ประกอบที่เกี่ยวกับ SQL อย่าง replication และ authentication จึงยังคงอยู่เหมือนเดิม
    รองรับทั้งการจัดเก็บแบบคอลัมน์และการบีบอัด และเร็วมาก เคยใช้ในแอปพลิเคชันด้านการเงินอยู่หลายแห่ง ข้อมูล tick ปริมาณมหาศาลไหลเข้ามาถึงแอปพลิเคชันด้วยความเร็วแทบจะสูงสุดเท่าที่ฮาร์ดแวร์จะรองรับได้
    การสนับสนุนก็ดี และตอบสนองรวดเร็วใน Slack เคยใช้ kdb เช่นกัน แต่มีข้อเสียใหญ่คือราคาแพง และภาษา Q แม้บางครั้งจะสนุกเหมือนเล่น code golf ด้วยโค้ดสั้น ๆ แต่สุดท้ายก็รู้ว่าตัวอักษรเดี่ยว ๆ ไม่ได้สื่อความหมายได้ดีอย่างที่คิด
    ถ้าเป้าหมายคือ การวิเคราะห์เชิงควอนต์ แบบเฉพาะหน้า kdb อาจเหมาะ เพราะคุณจะพิมพ์สตริงสั้น ๆ ลงใน REPL ทั้งวันเพื่อหาสิ่งที่ทำเงินได้ แต่หลายงานจริง ๆ แล้วใกล้เคียงกับงาน cron มากกว่า ดังนั้นถ้าจะรัน query ที่กำหนดไว้ตามตารางเวลา ควรทำให้อยู่ในรูปแบบที่คนถัดไปอ่านเข้าใจและดูแลต่อได้ดีกว่า

    • จุดแข็งอีกอย่างของ TimescaleDB คือเข้ากับ ส่วนขยายของ PostgreSQL อื่น ๆ ได้ดีมาก ประสบการณ์ตอนใช้ร่วมกับ PostGIS ดีมาก
      สถานการณ์อย่าง “แสดงเซ็นเซอร์บนแผนที่และแสดงกราฟค่าของแต่ละเซ็นเซอร์” สามารถจัดการได้รวดเร็วและเรียบร้อยด้วย query เดียว
    • ที่ทำงานใช้ TimescaleDB อยู่ และค่อนข้างชอบ ถ้าโครงสร้างข้อมูลถูกออกแบบมาดีก็สะดวกมากจริง ๆ
      แต่ข้อมูลของผมค่อนข้างผิดปกติ ฝั่งต้นทางสามารถเปลี่ยนโครงสร้างได้ตามใจ และผมต้องรองรับมัน ถ้าราคา InfluxDB ไม่บ้าคลั่งขนาดนั้น พูดตรง ๆ คงเลือกใช้ InfluxDB ทันที

  • เคย ลาออกหลังทำได้ 2 สัปดาห์ จากงาน quant trading ที่ใช้ kdb+ ใช้งานได้ก็จริง แต่ประสบการณ์แย่มาก
    จะบ่นว่า design ของภาษาหรือการ debug แย่มากก็ได้ แต่สิ่งที่น่าอึดอัดที่สุดคือวิธีที่มีหรือไม่มี coding rules ซึ่งผมมองว่าภาษาและชุมชนมีบทบาทมากในเรื่องนี้ วัฒนธรรมบริษัทก็มีส่วนด้วย พอถามว่าทำไมเอกสารถึงแย่ขนาดนี้ ก็ได้คำตอบว่า “พอเวลาผ่านไปเราจะเข้าใจเอง และต้องทำแบบนี้เพื่อไม่ให้ทีมอื่นเอาไอเดียของเราไปใช้ได้”
    สแต็กทั้งหมดก็เก่า และเครื่องมืออย่าง Q ก็ทำงานที่น่าสนใจได้ยากหลายอย่าง เช่น คัดลอกข้อมูลจาก qStudio ไป Excel เพื่อวาดกราฟ
    สิ่งเดียวที่ดีคือไม่ได้ตามกระแส Docker/Kubernetes แต่ deploy ลงเซิร์ฟเวอร์โดยตรง เป็นเรื่องสมเหตุสมผลที่ quant ควรแก้ไขสิ่งต่าง ๆ ใน production ได้รวดเร็ว แต่ผมก็คิดว่านักพัฒนาเว็บแอปก็ไม่ควรต้องรอทีละ 10 นาทีเพื่อดูผลการแก้ไขใน production เช่นกัน
    ผมมีทฤษฎีว่าทำไมเหล่า quant ถึงชอบ kdb: kdb เป็น อาวุธ ที่ดี เหมาะกับบางวัตถุประสงค์ แต่เรียกว่า เครื่องมือ ได้ยาก เพราะการสร้างอะไรด้วยมันน่าเบื่อ พวกเขาชอบตรงที่มันทำงานได้ทันที แต่การที่ใช้มีดตอกตะปูได้ ไม่ได้แปลว่านั่นคือจุดประสงค์ของมีด
    ถ้าต่อจากทฤษฎีนั้น LISP โดยเฉพาะ Racket อาจเป็นเครื่องมือที่ดีที่สุด แม้จะไม่ใช่ภาษาที่ทรงพลังที่สุดตั้งแต่แรก แต่เพราะมีความสามารถในการเปลี่ยนตัวภาษาเอง จึงสร้าง abstraction ได้มากมาย C++ และ Python เป็นภาษาโปรแกรมที่ยอดเยี่ยมสำหรับสร้างซอฟต์แวร์ที่ดี และ Python ก็เป็นอาวุธที่ค่อนข้างดีด้วย
    Q อาจทำให้เกิดภาพลวงตาว่าเป็นภาษาที่ดีที่สุดสำหรับสำรวจข้อมูล quant แต่จริง ๆ เป็นเพราะเหล่า quant ไม่ได้ลงทุนมากพอในการสร้างซอฟต์แวร์ที่ดีและใช้เครื่องมือที่ดี ถ้าเรียนรู้ Python IDE ให้ดี ก็อาจ productive กว่าโปรแกรมเมอร์ Q คนใดก็ได้
    เรื่อง performance ผมจะยังไม่เริ่มพูด แม้บทความในลิงก์จะไม่ค่อยดี แต่ก็แตะเรื่องนั้นไว้

    • บทความมองว่า Python และ DuckDB เป็นผู้สืบทอดที่เป็นไปได้
      สมัยก่อนเคยประทับใจ Kdb+ มาก เคยไป meetup ที่ Chicago ด้วย query ใหญ่ ๆ รันแทบจะทันที และ syntax แบบ APL ดูเหมือนคาถาวิเศษที่มีแต่คนสายคณิตศาสตร์เท่านั้นที่รู้ ตัวแทนฝ่ายขายบอกว่า Kdb ถูก optimize มากจนใส่ลงใน L1 cache ของโปรเซสเซอร์ในตอนนั้นได้
      ผ่านมา 10 ปี ตอนนี้ทำงานแบบเดียวกันบนไฟล์ Parquet ด้วย Python, DuckDB, Jupyter อยู่ DuckDB ไม่ได้ทำแค่ parallelization แต่ทำ vectorization ด้วย ไม่รู้ว่าถ้า benchmark เทียบกับ kdb+ จะเป็นอย่างไร แต่ responsiveness ของ DuckDB บน dataset ขนาดใหญ่ให้ความรู้สึกว่าเร็วอย่างน้อยเท่า kdb+ แน่นอนว่า kdb+ คงถูก optimize มากกว่ามาก แต่ความต่างคือ DuckDB ฟรี
    • การที่อยู่ในบทบาท quant finance ได้ ไม่ถึง 2 สัปดาห์ เพราะ kdb แล้วจากนั้นบอกว่าควรเขียนใหม่ทั้งหมดด้วย LISP นี่เป็นคอมเมนต์ที่น่าจะเป็นของคนคนนั้นในสไตล์ HN ที่สุดเท่าที่เคยเห็นมา
    • ไม่น่าจะถือว่าการเรียน Q ได้ใน 2 สัปดาห์ทำให้มีสิทธิ์สรุปได้ว่าคนที่ใช้ Python IDE เก่งจะ productive กว่านักพัฒนา quant ที่มีประสบการณ์หลายสิบปี
      ดูมีความเป็นไปได้มากกว่าว่าเขาหงุดหงิดและลาออกเพราะไม่เข้าใจโค้ด
      ถ้าเป็นนักพัฒนา quant ที่ชำนาญและตำแหน่งนั้นดีจริง การลาออกหลัง 2 สัปดาห์ภายใต้เงื่อนไขสัญญาแบบนี้คงเป็นหายนะต่อการจัดการการย้ายงานครั้งต่อไป
    • การผสานรวม pykx กำลังอุดช่องว่างหลายอย่างได้ค่อนข้างมาก เช่น charting, machine learning/statsmodels, การจัดการ HTML และ web scraping
      เช่น เปิด Jupyter Notebook แล้วทำแบบนี้ได้เลย
      import pykx as kx
      df = kx.q(“select from foo where bar”)
      plt.plot(df[“x”], df[“y”])
      เป็นการผสานรวมที่ลื่นไหลและทรงพลังมาก ได้ข้อดีของทั้งสองโลก และอาจกลายเป็นฟีเจอร์ที่ทำให้ผลิตภัณฑ์นี้อยู่รอดไปได้อีก 10 ปีข้างหน้า

  • ฟีเจอร์ที่น่าสนใจอย่างหนึ่งของ kdb+/Q ที่ไม่ได้กล่าวถึงอย่างชัดเจนตรงนี้คือ การผสานรวมแนวดิ่ง โดยปกติ use case ของทั้งสแตกที่ต้องเลือกเทคโนโลยีสำเร็จรูปหลายตัวมาประกอบกัน สามารถจัดการได้ด้วยเทคโนโลยีเดียว
    ด้วยภาษา Q, ความสามารถพื้นฐานในการ serialize ข้อมูล และความสามารถในการสื่อสารระหว่างโปรเซส โปรแกรมเมอร์ที่ชำนาญจึงสามารถสร้างระบบที่ต้องการให้พอดีได้ด้วยภาษาเดียว และ codebase ก็มักเล็กพอจะใส่ในเอกสารไม่กี่หน้า ไม่ใช่หลายร้อยหรือหลายพันหน้า
    ถ้าองค์กรตัดสินใจไปแล้วว่าจะให้ซอฟต์แวร์ โปรโตคอล หรือฟอร์แมตอื่นรับบทบาทบางส่วนเหล่านี้ ประโยชน์ของการผสานรวมแนวดิ่งทั้งในแง่ workflow การพัฒนาและประสิทธิภาพโดยรวมก็จะลดลง ยิ่ง kdb+ เองเป็นซอฟต์แวร์ proprietary และยังแพงด้วย จึงเข้าใจได้ว่าทำไมการนำมาใช้เต็มรูปแบบในโปรเจกต์ใหม่จึงหาเหตุผลรองรับได้ยาก ตัวเทคโนโลยีเองเหมือนอัญมณี น่าเสียดายจริง ๆ

    • ความสามารถด้าน การผสานรวมแนวดิ่ง ของ kdb+/Q นั้นน่าทึ่งจริง แต่ก็เข้าใจยากว่าทำไม Kx ถึงไม่ใช้ประโยชน์จากมันให้เต็มที่ Kx Platform ดูเหมือนจะเขียนด้วย Java เป็นส่วนใหญ่ และเอกสาร API ที่เรียกใช้ได้จาก Q ก็ไม่ได้ดีนัก
      ผลิตภัณฑ์แดชบอร์ดใช้งานยาก และมีบั๊กร้ายแรงที่ทำให้ตัวแก้ไขล่มบ่อยแม้กับแดชบอร์ดที่ซับซ้อนระดับกลาง Q มีฟีเจอร์มากมายจนถ้าใช้เขียนเว็บแอปพลิเคชันคงสนุกมาก แต่ถ้าจะส่งมอบอะไรให้ผู้ใช้กลับต้องใช้ตัวแก้ไขแบบ drag-and-drop เท่านั้น
      ผมคิดว่าถ้า Shakti มีไลบรารีสำหรับจัดการ use case ระดับองค์กรทั่วไป เช่น load balancing, สิทธิ์ผู้ใช้ และ SSO ก็อาจกลายเป็นคู่แข่งตัวจริงของ Kx ได้ โปรแกรมเมอร์ K ที่ชำนาญน่าจะทำได้ภายใน 1–2 สัปดาห์ แต่บริษัทใหญ่ ๆ มักจะอนุญาตให้นำผลิตภัณฑ์มาใช้ก็ต่อเมื่อฟีเจอร์เหล่านี้ถูก implement ไว้แล้ว
    • การเขียน โค้ดชุดเดียว เพื่อแก้ use case โดยไม่ต้องประกอบ message queue, stream processor, database, query engine ฯลฯ เข้าด้วยกัน เป็นข้อได้เปรียบอย่างมาก
      กำลังทดลองไอเดียสร้างเลเยอร์ผสานรวมแบบนี้ด้วย SQL บนเทคโนโลยีโอเพนซอร์สอย่าง Kafka, Flink, Postgres, Iceberg แล้วเติม syntax sugar ที่ทำให้การประมวลผล time series ใน SQL สะดวกขึ้น
      https://github.com/DataSQRL/sqrl/
      เป้าหมายคือแปลง SQL สร้าง DAG ของการคำนวณ แล้วให้ตัวเพิ่มประสิทธิภาพแบบ cost-based ตัด DAG เพื่อกระจายไปยังเทคโนโลยีข้อมูลพื้นฐานต่าง ๆ เพื่อมอบพลังของ kdb+ ในรูปแบบแพ็กเกจที่ผสานเทคโนโลยีโอเพนซอร์สกับ SQL

  • ควรออก เวอร์ชันฟรี ที่ใช้ได้หลายวัตถุประสงค์
    ผมคิดว่านี่คืออุปสรรคใหญ่ที่สุดที่ทำให้ kdb+ ไม่ได้รับการยอมรับในฐานะเทคโนโลยีและผลิตภัณฑ์ที่ยอดเยี่ยม และไม่เติบโตในชุมชนนักพัฒนา
    ผมเคยใช้ kdb+ อย่างหนักในวงการการเงินมาหลายปีจนกลายเป็นแฟน การออกแบบและความเรียบง่ายมีความงามสง่าเหมือนมีรากมาจากปรัชญา Unix หลังจากออกจากวงการการเงินและไม่ได้ทำงานในบริษัทที่ใช้ kdb+ แล้ว ผมก็ยังมักมีแรงอยากใช้ kdb+ กับโปรเจกต์เล็ก ๆ ตามที่ต่าง ๆ อยู่บ่อยครั้ง
    น่าหงุดหงิดที่ใช้ไม่ได้อีกแล้ว และไม่สามารถโชว์เครื่องมือ niche ที่ไม่ค่อยมีใครรู้จักนี้ให้เพื่อนร่วมงานดู แล้ว geek out ว่ามันเรียบง่ายและมีประสิทธิภาพแค่ไหนกับงานและการคำนวณบางประเภท

    • มันไม่มีอะไรอย่างเวอร์ชันฟรีหรือ?
      เมื่อก่อนผมต้องเขียนโค้ด C++ ที่ส่งข้อมูลไปยัง kdb และตัวถอดรหัส wire protocol ของพวกเขา ซึ่งทั้งสองอย่างมีไบนารี kdb สำหรับทดสอบแน่นอน
      แค่ต้องใช้ทดสอบเท่านั้น เหมือนว่า Kx จะให้ไลเซนส์สำหรับพัฒนา แต่ก็เป็นเรื่องค่อนข้างนานมาแล้ว
    • สงสัยว่า เวอร์ชันโอเพนซอร์ส อย่าง ngn/k หรือ Kerf ใช้ได้ดีพอไหม

  • โดยรวมเห็นด้วยกับเนื้อหาในบทความนี้ ถ้าสร้างใหม่ตอนนี้ก็เก็บข้อมูลไว้ใน Parquet แล้วเข้าถึงด้วย Polars หรือ DuckDB ก็พอ
    ผมเกลียด q/kdb+ มากจนถึงขั้นสร้างภาษาเองสำหรับวิเคราะห์ time series แต่ผู้ชนะมาหลายปีแล้วก็คือ Python

  • เคยสร้างสตาร์ทอัพที่ประสบความสำเร็จพอสมควรด้วย kdb+ เป็นเทคโนโลยีที่ผมรู้จัก และช่วยให้สร้างผลิตภัณฑ์ที่แข็งแรงได้อย่างรวดเร็ว แต่เมื่อขยายขนาดขึ้น ก็ต้องเขียนใหม่ด้วย ซอฟต์แวร์โอเพนซอร์ส เพื่อขยายทีม
    โดยรวมเห็นด้วยกับข้อเสนอแนะ แต่ผมคิดว่า Kx ควรเปิดแพลตฟอร์มเป็นโอเพนซอร์ส แบบนั้นจะดึงดูดนักพัฒนาประเภทที่อยากร่วมปรับปรุงและสร้างเครื่องมือให้ ecosystem ได้

    • อยากรู้ว่าสตาร์ทอัพนั้นคืออะไร และย้ายไปใช้ ซอฟต์แวร์โอเพนซอร์ส อะไร

  • Kdb+ ดูเท่มากจริง ๆ และผมเคยเรียนมันกับ APL แบบเล่น ๆ ในอุตสาหกรรมของผมก็น่าจะเหมาะกับหลายงานพอสมควร แต่ราคานี่เหลือเชื่อเกินไป
    เราจ่ายเงินแบบ 100,000 ดอลลาร์ต่อ CPU เหมือนที่ธนาคารในวงการการเงินจ่ายไม่ได้ ดังนั้นในทางปฏิบัติก็เท่ากับเมินกลุ่มลูกค้าที่มีศักยภาพขนาดใหญ่มากไป

    • พวกเขาหา niche market ที่ยอมจ่ายราคานั้นให้ผลิตภัณฑ์ที่ล้ำสมัยได้ ผมคิดว่าเป็นตัวเลือกที่ถูกต้อง เพราะตั้งแต่แรกมันไม่ใช่ผลิตภัณฑ์ที่ตั้งใจจะแก้ทุกปัญหาของโลก
      คนอื่นสามารถเรียนรู้เทคนิคของพวกเขา แล้วทำสิ่งเดียวกันให้เหมาะกับโดเมนและภาษาต่าง ๆ ได้

  • มีบางจุดในบทความที่ควรแก้ไข

    1. ClickHouse ไม่ใช่เทคโนโลยีใหม่ เป็นโอเพนซอร์สมาตั้งแต่ปี 2016 และพัฒนามาตั้งแต่ปี 2009
    2. ClickHouse จัดการ use case ทั้งสามแบบได้ รองรับทั้งข้อมูลย้อนหลังและข้อมูลแบบเรียลไทม์ ทั้งการประมวลผลแบบกระจายและแบบโลคัล ดู clickhouse-local และ chdb ได้
    3. ClickHouse เป็นฐานข้อมูล SQL ตัวแรกที่มี ASOF JOIN ในผลิตภัณฑ์หลักเมื่อปี 2019 kdb+ มีมาก่อนหน้านั้น แต่ไม่ใช่ SQL
    • ผมบริหารบริษัทที่ปรึกษาด้านข้อมูลที่โฟกัส ClickHouse อย่างมาก มีความสนใจสูงในการใช้ ClickHouse แทน KDB ผมคุยกับบริษัทที่กำลังพิจารณา migration น่าจะราว 10 ครั้งแล้ว
      แต่ยังไม่มีที่ไหนลงมือย้ายจริง เหมือนจะเป็นการตัดสินใจครั้งใหญ่เมื่อคิดถึง integration ต่าง ๆ ที่แตกแขนงออกมาจาก KDB ถึงอย่างนั้นก็ชัดเจนว่ามันให้ความรู้สึกเหมือนผู้สืบทอดทางจิตวิญญาณ
    • ข้อ 3 เป็นจุดที่คนที่ใช้ Q และเครื่องมือที่เกี่ยวข้องกับการคำนวณทางการเงินมักมองข้ามได้ง่าย พวกเขาเลือก kdb+ ด้วยเหตุผลบางอย่าง และเหตุผลนั้นไม่ใช่ฐานข้อมูล ผมก็รับสารหลักของบทความไปในทำนองนั้น

  • สงสัยว่าตอนนี้ถ้าเริ่มเรียนตั้งแต่ศูนย์ ยังสามารถทำเงินก้อนใหญ่จาก การพัฒนา kdb+ ได้ไหม จำได้ว่าเมื่อไม่กี่ปีก่อนเคยเห็นประกาศงานที่จ่ายประมาณปีละ 1 ล้านดอลลาร์ ซึ่งน่าทึ่งมาก

  • น่าเสียดายที่ kdb+ มี ข้อกำหนด DeWitt ทำให้ไม่มีใคร benchmark เทียบกับฐานข้อมูลอื่น ๆ ที่กล่าวถึงในบทความได้
    ก็สงสัยเหมือนกันว่ามี benchmark สาธารณะที่ทำโดยบุคคลที่สามหรือไม่