KDB+/Q: ภาษาของฐานข้อมูลราคาแบบ tick
วอลล์สตรีทจัดเก็บและค้นข้อมูลตลาดนับพันล้านจุดอย่างไร
KDB+ และ Q ในหนึ่งนาที
KDB+ เป็นฐานข้อมูลอนุกรมเวลา (time-series) แบบเรียงคอลัมน์ (column-oriented) Q คือภาษาเวกเตอร์ของมัน บริษัทฝั่ง sell-side และ buy-side นำมันมาใช้สำหรับการเก็บข้อมูล tick การเชื่อมตาราง และการวิเคราะห์แบบ rolling ในกรณีที่การสแกนแบบคอลัมน์เร็วกว่าการวนซ้ำแบบแถวต่อแถว
ประสิทธิภาพมาจากการจัดวางแบบคอลัมน์ การใช้ memory mapping อย่างเข้มข้น และ vector primitive ที่ทำงานใกล้ชิดกับฮาร์ดแวร์ มันไม่ใช่ตัวแทน OLTP ทั่วไป แต่ถูกปรับให้เหมาะกับข้อมูลอนุกรมเวลาที่เน้นการเพิ่มข้อมูลต่อท้าย (append-heavy)
พื้นฐานของ Q
Q เป็นภาษาที่กระชับและประเมินผลจากขวาไปซ้าย เวกเตอร์เป็นชนิดข้อมูลดั้งเดิม การวนซ้ำ (loop) มีอยู่จริงแต่เส้นทางที่ใช้งานหนักจะหลีกเลี่ยงมัน ตารางคือ dictionary ของคอลัมน์ ซึ่งสอดคล้องกับวิธีการเก็บข้อมูล tick
prices: 100.5 101.2 99.8
avg prices
deltas pricesโค้ด Q ที่อ่านง่ายมาจากฟังก์ชันขนาดเล็กและคอมเมนต์ — ความกระชับเพียงอย่างเดียวไม่ใช่ข้อดีในโค้ดเบสที่ใช้งานร่วมกัน
Tickerplant, RDB, HDB
รูปแบบทั่วไป: tickerplant รับข้อมูล feed เข้ามาและกระจายไปยังผู้สมัครสมาชิก (subscriber); real-time database (RDB) เก็บข้อมูลของเซสชันปัจจุบัน; historical database (HDB) เก็บข้อมูลประวัติแบบแบ่งพาร์ทิชันบนดิสก์ กระบวนการสิ้นวัน (end-of-day) จะโอนข้อมูลจาก RT เข้าสู่พาร์ทิชันของ HDB
select last price by sym from trades where time > .z.t - 00:05คริปโตไม่มีวันปิดตลาด ดังนั้นขอบเขต "เซสชัน" จึงเป็นการตัดสินใจเชิงปฏิบัติการ ไม่ใช่ระฆังเปิด-ปิดตลาดของตลาดแลกเปลี่ยน
มันปรากฏอยู่ที่ไหน
บริษัทต่าง ๆ ใช้ KDB+ สำหรับแดชบอร์ดการเฝ้าติดตาม (surveillance) การวิเคราะห์ราคาเสนอ และชุดข้อมูลวิจัย ชื่อและรูปแบบการติดตั้งแตกต่างกันไป แต่รูปแบบหลักคือการตัดแบ่งและวิเคราะห์ข้อมูล tick และคำสั่งซื้อขายอย่างรวดเร็ว
ตลาดคริปโตสร้างข้อมูลอย่างต่อเนื่อง — ให้วางแผนเรื่องการเก็บรักษาข้อมูล การเล่นซ้ำ และการส่งออกเพื่อการปฏิบัติตามกฎระเบียบไว้ล่วงหน้า
ต้นทุนใบอนุญาตและตัวเลือกอื่น
ค่าใบอนุญาตเชิงพาณิชย์และการจ้างบุคลากรเฉพาะทางเป็นต้นทุนจริง ตัวเลือกแบบเปิด (ClickHouse, Timescale, QuestDB, DuckDB บน Parquet) แลกความเข้ากันได้กับระบบนิเวศเพื่อราคาที่ถูกกว่า ให้ทำเบนช์มาร์กจากรูปแบบการค้นหาข้อมูลของคุณเอง ไม่ใช่จากสไลด์ของผู้ขาย
สแต็กข้อมูล tick สำหรับคริปโต
หลายทีมจับคู่ Kafka หรือ Redpanda กับที่เก็บข้อมูลแบบคอลัมน์และเอนจิน SQL หลักการที่ไม่เปลี่ยนแปลงจาก KDB+ ยังคงใช้ได้: แบ่งพาร์ทิชันตามเวลา รักษา schema ให้เคร่งครัด และวัดความล่าช้าตั้งแต่ต้นจนจบ (end-to-end lag) จาก timestamp ของตลาดแลกเปลี่ยนไปจนถึงผลลัพธ์การค้นหา
ผู้ใช้ API ของ GaiaEx ควรบันทึก timestamp ของเซิร์ฟเวอร์และตัวระบุลำดับ (sequence identifier) หากมีการเปิดเผยไว้ — การเชื่อมโยงข้อมูลดีกว่าการเดา
