نقدّم 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 الثنائية — فتح سلسلة، وإلحاق مدخل في سجل الاستنساخ، ودفع أصوات الثقة، ومراقبة النهائية — من دون 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. هذه هي خلفية التحليلات والرؤى التي نشغّلها بأنفسنا — وجّه أحداثك إليها واستعلم عنها من جديد بسرعة الأعمدة.