आज पेश है Hanzo Datastore: पोस्ट-क्वांटम युग के लिए तैयार स्तंभीय OLAP विश्लेषण इंजन

आज हम Hanzo Datastore जारी करते हैं — Hanzo डेटा प्लेटफ़ॉर्म का OLAP वाला आधा हिस्सा। यह ClickHouse 26.6 का फ़ॉर्क है, जिसका ब्रांड हटाकर उसे वैसे फिर से बनाया गया है जैसे हम विश्लेषण सच में चलाते हैं: भंडारण संगणना से अलग होकर Hanzo S3 पर है, अनुकूलित बाइनरी अधिक दुबली है, और पुरानी RPC सतह हटा दी गई है। इमेज ghcr.io/hanzoai/datastore:26.6.1.1 पर उपलब्ध है।

हमने कोई नया डेटाबेस नहीं लिखा। ClickHouse दुनिया का सबसे अच्छा स्तंभीय इंजन है और हम उसी पर खड़े हैं। हमने वे हिस्से बदले हैं जो मशीनों का बेड़ा चलाने में मायने रखते हैं: भंडारण की आधार परत, निर्माण, परिवहन, और समन्वय की रूपरेखा।

भंडारण और संगणना, अलग

MergeTree तालिका के पार्ट अपरिवर्तनीय ऑब्जेक्ट होते हैं। Datastore उन्हें किसी एक सर्वर से जुड़े स्थानीय डिस्क पर नहीं, बल्कि Hanzo S3 पर ऑब्जेक्ट के रूप में रखता है — यह हमारी SeaweedFS से निकली भंडारण परत है। इसके बाद अवस्था-रहित संगणना प्रतिकृतियाँ शून्य-प्रतिलिपि प्रतिकृति के ज़रिए डेटा की एक ही भौतिक प्रति साझा करती हैं।

यह सिद्ध है, महज़ आकांक्षा नहीं। हमारे स्केल-आउट परीक्षण में पाँच मिलियन पंक्तियों की एक तालिका, जिसकी भंडारण नीति S3 को लक्षित करती है, system.parts में डिस्क seaweed बताती है, और दो संगणना नोड उस एक प्रति पर फैलते हैं। पाठक जोड़ने से डेटा की प्रति नहीं बनती; वह उससे जुड़ जाता है। यही गुण चाहिए जब विश्लेषण का भार अचानक बढ़े और टेराबाइट दुबारा बाँटे बिना कुछ सेकंड में क्वेरी क्षमता जोड़नी हो।

-- 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 का एक पास चलाता है। परिणाम मूल निर्माण की तुलना में लगभग आधी रेज़िडेंट स्मृति और स्पष्ट रूप से छोटा बाइनरी है। aarch64 पर BOLT चलाना संभव बनाने के लिए XRay का उपकरणीकरण बंद करना पड़ा, जो तयशुदा रूप से चालू था और चुपचाप लिंक के बाद के पुनर्लेखन को रोक रहा था — वह सुधार स्रोत कोड में है। व्यावहारिक असर: वही क्वेरी योजना, कम गीगाबाइट, और एक बाइनरी जो तेज़ी से शुरू होती है।

gRPC हट चुका है

किसी डेटा भंडार का क्वेरी पथ ठीक एक होना चाहिए, तीन नहीं। हमने gRPC सर्वर पूरी तरह हटा दिया — न contrib/grpc, न protobuf की सेवा परिभाषाएँ, न ENABLE_GRPC निर्माण पथ — और उसी पास में तयशुदा कॉन्फ़िग से मृत <grpc> ब्लॉक भी मिटा दिया, ताकि भेजा गया उत्पाद निर्माण से मेल खाए। Datastore मूल TCP (9000), HTTP (8123), और सर्वरों के बीच प्रतिकृति (9009) बोलता है। यही पूरी सतह है।

आगे का इच्छित परिवहन ZAP है, हमारा Cap'n Proto से निकला RPC। सर्वर का स्टब आ चुका है; वह अभी जीवित क्वेरी पथ नहीं है। हम यह बताना बेहतर समझते हैं कि वह रेखा ठीक कहाँ है, बजाय इसके कि वह पूरा हो चुका है ऐसा आभास दें।

समन्वय किस ओर जा रहा है

Replicated* तालिकाएँ आज अंतःस्थापित Raft के ज़रिए समन्वय करती हैं, यानी ZooKeeper-संगत Keeper जो सर्वर प्रक्रिया के अंदर आता है — कोई अलग डेमन नहीं। यह काम करता है, और उत्पादन में अभी आप यही चलाते हैं।

दिशा उस Raft बैकएंड को Quasar से बदलने की है। यह Lux का बिना नेता वाला, पोस्ट-क्वांटम आम सहमति है, जिसे C++ सर्वर में मूल रूप से जोड़ा गया है। जोड़ वास्तविक है: एक C++ प्रोग्राम पहले से मूल आम-सहमति इंजन को उसकी C ABI के ज़रिए चलाता है — एक शृंखला खोलना, प्रतिकृति अभिलेख में प्रविष्टि जोड़ना, विश्वास के मत आगे बढ़ाना, अंतिमता देखना — बिना Raft और बिना शून्य-ज्ञान की मशीनरी के। यही प्रमाण है कि अदला-बदली जोड़ने की समस्या है, पुनर्लेखन नहीं। यह अभी उत्पादन की समन्वय परत नहीं है, और हम यह दिखावा नहीं करेंगे कि यह वही परत है।

दूसरा आधा

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 के ज़रिए पीछे आता है। यही विश्लेषण और अंतर्दृष्टि का बैकएंड है जिसे हम खुद चलाते हैं — अपने इवेंट इसी पर भेजें और उन्हें स्तंभीय गति से वापस क्वेरी करें।