ขอแนะนำ Hanzo Datastore: เอนจิน OLAP แบบคอลัมน์ที่พร้อมสำหรับยุคหลังควอนตัม

วันนี้เราจัดส่ง Hanzo Datastore ครึ่ง OLAP ของแพลตฟอร์มข้อมูล Hanzo มันเป็นฟอร์กของ ClickHouse 26.6 ที่ถอดแบรนด์ออก แล้วสร้างใหม่ตามวิธีที่เราวิเคราะห์จริง คือแยกที่เก็บข้อมูลออกจากการคำนวณบน Hanzo S3 ได้ไบนารีที่ปรับให้เหมาะและบางลง และถอดพื้นผิว RPC เดิมออกแล้ว อิมเมจพร้อมใช้งานที่ ghcr.io/hanzoai/datastore:26.6.1.1

เราไม่ได้เขียนฐานข้อมูลใหม่ ClickHouse คือเอนจินแบบคอลัมน์ที่ดีที่สุดในโลก และเราต่อยอดจากมัน สิ่งที่เราเปลี่ยนคือส่วนที่สำคัญต่อการดูแลเครื่องทั้งชุด: ฐานชั้นที่เก็บข้อมูล กระบวนการบิลด์ การขนส่ง และแผนงานการประสานงาน

ที่เก็บข้อมูลและการคำนวณ แยกจากกัน

พาร์ตของตาราง MergeTree เป็นอ็อบเจกต์ที่เปลี่ยนแปลงไม่ได้ Datastore เก็บพวกมันเป็นอ็อบเจกต์บน Hanzo S3 ซึ่งเป็นชั้นที่เก็บข้อมูลที่เราต่อยอดจาก SeaweedFS แทนที่จะอยู่บนดิสก์ในเครื่องที่เชื่อมตายกับเซิร์ฟเวอร์เครื่องเดียว จากนั้นเรพลิกาการคำนวณที่ไม่มีสถานะจึงใช้สำเนาทางกายภาพเพียงชุดเดียวของข้อมูลร่วมกัน ผ่านการเรพลิเคตที่ไม่ต้องคัดลอก

เรื่องนี้พิสูจน์แล้ว ไม่ใช่แค่ความมุ่งหมาย ในการทดสอบขยายสเกลของเรา ตารางห้าล้านแถวที่นโยบายที่เก็บข้อมูลชี้ไปที่ S3 รายงานดิสก์ seaweed ใน system.parts และโหนดคำนวณสองโหนดขยายบนสำเนาเดียวนี้ การเพิ่มตัวอ่านไม่ได้คัดลอกข้อมูล แต่ไปผูกกับข้อมูลนั้น นี่คือคุณสมบัติที่ต้องการเมื่อโหลดงานวิเคราะห์พุ่ง และต้องเพิ่มความจุคิวรีภายในไม่กี่วินาทีโดยไม่ต้องจัดเทราไบต์ใหม่

-- parts live on S3, not on a node's local disk
SELECT name, disk_name FROM system.parts WHERE table = 'events' LIMIT 1;
-- ┌─name──────┬─disk_name─┐
-- │ all_1_1_0 │ seaweed   │
-- └───────────┴───────────┘

หน่วยความจำเหลือครึ่ง ไบนารีเล็กลง

บิลด์สำหรับรีลีสใช้การปรับให้เหมาะตามโปรไฟล์ การปรับให้เหมาะตอนลิงก์แบบบาง และรอบ BOLT หลังลิงก์ ผลลัพธ์คือหน่วยความจำประจำที่ราวครึ่งหนึ่งของบิลด์ต้นทาง และไบนารีที่เล็กลงอย่างเห็นได้ชัด การทำให้ BOLT ทำงานบน aarch64 ต้องปิดเครื่องมือวัด XRay ซึ่งเปิดเป็นค่าเริ่มต้นและแอบขวางการเขียนใหม่หลังลิงก์ การแก้ปัญหานั้นอยู่ในทรีแล้ว ผลในทางปฏิบัติคือแผนคิวรีเดิม ใช้กิกะไบต์น้อยลง และไบนารีเริ่มทำงานเร็วขึ้น

gRPC หายไปแล้ว

ที่เก็บข้อมูลควรมีเส้นทางคิวรีเส้นเดียว ไม่ใช่สาม เราถอดเซิร์ฟเวอร์ gRPC ออกทั้งหมด ไม่มี contrib/grpc ไม่มีนิยามบริการ protobuf และไม่มีเส้นทางบิลด์ ENABLE_GRPC ในรอบเดียวกันก็ลบบล็อก <grpc> ที่ตายแล้วออกจากคอนฟิกเริ่มต้น เพื่อให้ผลิตภัณฑ์ที่ส่งมาตรงกับบิลด์ Datastore พูด TCP แบบเนทีฟ (9000), HTTP (8123) และการเรพลิเคตระหว่างเซิร์ฟเวอร์ (9009) นั่นคือพื้นผิวทั้งหมด

การขนส่งที่ตั้งใจเดินต่อคือ ZAP ซึ่งเป็น RPC ที่เราต่อยอดจาก Cap'n Proto สตับของเซิร์ฟเวอร์เข้ามาในโค้ดแล้ว แต่ยังไม่ใช่เส้นทางคิวรีที่ใช้งานอยู่ เราอยากบอกให้ชัดว่าเส้นนั้นอยู่ตรงไหน มากกว่าจะทำให้เข้าใจว่ามันเสร็จแล้ว

การประสานงานกำลังมุ่งไปทางไหน

ตาราง Replicated* วันนี้ประสานงานผ่าน Raft ที่ฝังมา คือ Keeper ที่เข้ากันได้กับ ZooKeeper และมากับโพรเซสของเซิร์ฟเวอร์ โดยไม่มีดีมอนแยก สิ่งนี้ใช้ได้ และนี่คือสิ่งที่คุณรันในโปรดักชันตอนนี้

ทิศทางคือการแทนที่แบ็กเอนด์ Raft นั้นด้วย Quasar ฉันทามติแบบไม่มีผู้นำและเป็นแบบหลังควอนตัมจาก Lux ที่ลิงก์เข้ากับเซิร์ฟเวอร์ C++ โดยตรง รอยต่อนี้เป็นของจริง โปรแกรม C++ ขับเคลื่อนเอนจินฉันทามติแบบเนทีฟผ่าน C ABI อยู่แล้ว เปิดเชน เติมรายการบันทึกการเรพลิเคต ขับโหวตความเชื่อมั่น และสังเกตภาวะสิ้นสุด โดยไม่มี Raft และไม่มีกลไก zero-knowledge นั่นคือข้อพิสูจน์ว่าการสลับเป็นปัญหาการลิงก์ ไม่ใช่การเขียนใหม่ มันยังไม่ใช่ชั้นประสานงานของโปรดักชัน และเราจะไม่แสร้งว่ามันเป็นชั้นนั้นแล้ว

อีกครึ่งหนึ่ง

Datastore คือ OLAP ครึ่ง OLTP ของแพลตฟอร์มเป็นเอนจิน SQL แบบกระจายศูนย์ที่สร้างบน SQLite/Base ออกแบบแล้ว กำลังสร้าง และยังไม่ส่ง หากวันนี้คุณต้องการเรื่องข้อมูลที่เริ่มจากเครื่องตัวเองในไฟล์เดียว สายนั้นปรากฏอยู่แล้วใน Hanzo Brain และฐานชั้นที่เก็บข้อมูลที่ทั้งสองครึ่งใช้ คือสิ่งที่เราเปิดตัวใน Hanzo Storage

รันได้เลย

docker run -d --name datastore \
  -p 8123:8123 -p 9000:9000 \
  ghcr.io/hanzoai/datastore:26.6.1.1

• ซอร์ส: github.com/hanzoai/datastore
• ผลิตภัณฑ์: hanzo.ai/datastore
• เอกสาร: docs.hanzo.ai

อิมเมจ arm64 เผยแพร่แล้วตอนนี้ ส่วนบิลด์ amd64 ตามมาทาง CI นี่คือแบ็กเอนด์การวิเคราะห์และข้อมูลเชิงลึกที่เราใช้เอง ชี้เหตุการณ์ของคุณมาที่นี่ แล้วคิวรีกลับด้วยความเร็วแบบคอลัมน์