الملاحظة: MariaDB ليس سحابيًا أصليًا

لنكن صادقين: MariaDB / MySQL في شكلها الحالي ليست قواعد بيانات سحابية أصلية. لقد تم تصميمها لتعمل على خادم واحد مع مساحة تخزين محلية. حتى بنيات النسخ المتماثل الرئيسية والتابعة هي في الأساس نسخ كاملة من البيانات الموجودة على كل عقدة.

في السحابة، يطرح هذا عدة مشاكل أساسية:

تقترن مساحة التخزين بالحوسبة. إذا كنت بحاجة إلى المزيد من وحدة المعالجة المركزية (CPU)، فيجب عليك توفير خادم جديد بكل مساحة التخزين. إذا كنت بحاجة إلى مساحة تخزين أكبر، فيجب عليك تغيير حجم الخادم.
القياس الأفقي محدود. تحتوي كل نسخة متماثلة على نسخة كاملة من البيانات. إن إضافة خادم سعة 2 تيرابايت يعني نسخ 2 تيرابايت من البيانات.
يتضمن تجاوز الفشل فترة توقف. يتضمن ترقية العبد فترة تقارب قد يتم خلالها فقدان أحدث عمليات الكتابة (في النسخ المتماثل غير المتزامن) أو تكون المجموعة خلالها غير متاحة (في النسخ المتماثل المتزامن).

لقد نجحت قواعد البيانات الحديثة السحابية مثل Amazon Aurora أو Google AlloyDB أو PostgreSQL Neon في حل هذه المشكلات عن طريق فصل الحساب عن التخزين.

الإلهام: PostgreSQL Neon

PostgreSQL Neon هو مشروع رائع. يأخذ PostgreSQL ويستبدل طبقة التخزين المحلية بالتخزين الموزع عن بعد. يعمل محرك PostgreSQL كعقدة حسابية خالصة: فهو يتلقى الاستعلامات ويجدول التنفيذ ويتبادل صفحات البيانات مع خدمة التخزين عن بعد عبر الشبكة.

الفوائد مذهلة:

القياس الفوري: إضافة عقدة حسابية لا يتطلب أي نسخ للبيانات
التفرع: يتم إنشاء "فرع" لقاعدة البيانات (مثل فرع Git) بشكل فوري - فهي عملية بيانات وصفية، وليست نسخة فعلية
الدفع لكل استخدام: يتم إيقاف عقد الحوسبة غير النشطة، ولا تدفع إلا مقابل التخزين

هل يمكن لـ MariaDB اتباع نفس المسار؟

المعالج API: نقطة الفصل الطبيعية

يتمتع MariaDB بميزة معمارية فريدة لا تمتلكها PostgreSQL: المعالج API. إنها الواجهة المجردة بين محرك SQL (المحلل اللغوي والمحسن والمنفذ) ومحركات التخزين (InnoDB وAria وRocksDB وColumnStore وما إلى ذلك).

يحدد المعالج API عمليات مثل:


cpp
handler::ha_open()       // ouvrir une table
handler::ha_read_first() // lire la première ligne
handler::ha_read_next()  // lire la ligne suivante
handler::ha_write_row()  // écrire une ligne
handler::ha_update_row() // mettre à jour une ligne
handler::ha_delete_row() // supprimer une ligne
handler::ha_index_read() // lecture par index

ينفذ كل محرك تخزين هذه الأساليب. يقوم InnoDB بتنفيذها من خلال الوصول إلى صفحات B-tree المحلية. تطبقها إريا بشكل مختلف. يستخدم RocksDB أشجار LSM.

ماذا لو قام محرك تخزين بتنفيذ هذه الأساليب عن طريق الوصول إلى الصفحات البعيدة عبر الشبكة؟

نهج PolarDB (علي بابا)

لقد أثبتت شركة Alibaba بالفعل أن هذا ممكن مع PolarDB، والذي يعتمد على الكود MySQL. يستخدم PolarDB:

نظام الملفات الموزعة (PolarFS) الذي يحل محل التخزين المحلي
بروتوكول إجماع (الطوافة) للاستدامة
ذاكرة تخزين مؤقت للصفحة مشتركة بين العقد الحسابية

والنتيجة هي MySQL الذي تم فصل تخزينه عن الحساب. يمكن لعقد حسابية متعددة قراءة نفس البيانات في وقت واحد، وتتولى عقدة واحدة فقط عمليات الكتابة.

يوضح PolarDB أن معالج API لـ MariaDB / MySQL يمثل نقطة فصل قابلة للتطبيق. لم تقم شركة Alibaba بإعادة كتابة محرك SQL، بل قامت بتطبيق معالج يمكنه الوصول إلى وحدة التخزين البعيدة.

الرؤية: معالج API عن بعد لـ MariaDB

لنتخيل محرك تخزين MariaDB يسمى RemoteStore:

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255)
) ENGINE=RemoteStore
CONNECTION='storage-cluster.internal:9000/db1';

لن يحتوي محرك التخزين هذا على بيانات محلية. ستتم ترجمة كل استدعاء إلى معالج API إلى استدعاء شبكة لخدمة تخزين موزعة. ستقوم خدمة التخزين بإدارة:

نسخ البيانات (3 نسخ كحد أدنى)
الاستدامة (سجل الكتابة المسبقة الموزع)
اللقطة والتفرع
الضغط والتصنيف (البيانات الساخنة في SSD، البيانات الباردة في S3)

ترجمة MariaDB بدون محركات داخلية

ستكون الخطوة الأولى نحو هذه الرؤية هي القدرة على تجميع MariaDB بدون أي محرك تخزين مدمج. اليوم، يتم تجميع InnoDB في الملف الثنائي mariadbd. تسمح لك خيارات الترجمة بتعطيل بعض المحركات، لكن InnoDB يظل متكاملاً بعمق.

سيبدو محرك MariaDB "بدون رأس" - وهو محرك SQL خالص بدون تخزين - كما يلي:

MariaDB SQL Engine (parser + optimizer + executor)
       ↓ handler API
Plugin: RemoteStore → réseau → Stockage distribué

سيكون هذا MariaDB بدون رأس خفيف الوزن (بضع مئات ميغابايت من ذاكرة الوصول العشوائي)، وسيبدأ بالمللي ثانية، ويمكن نشره كحاوية عديمة الحالة في Kubernetes.

التحديات التقنية

ولا تخلو هذه الرؤية من التحديات:

زمن وصول الشبكة

كل وصول إلى الصفحة يمر عبر الشبكة. يتراوح زمن وصول الشبكة في مركز البيانات من 100 إلى 500 ميكروثانية. وهذا أبطأ بمقدار 100 إلى 1000 مرة من الوصول إلى SSD المحلي. يعد وجود ذاكرة تخزين مؤقت قوية للصفحة في عقدة الحساب أمرًا ضروريًا.

إدارة القفل

InnoDB يدير الأقفال محليًا. مع التخزين البعيد المشترك، يجب توزيع إدارة القفل. هذه مشكلة صعبة يمكنها تقديم حالات توقف تام ومهلات إضافية.

تجمع المخزن المؤقت الموزع

تجمع المخزن المؤقت InnoDB محلي. في البنية السحابية الأصلية، يجب أن تكون هناك آلية لإبطال ذاكرة التخزين المؤقت بين عقد الحوسبة. عندما تكتب عقدة صفحة، يجب إبطال ذاكرة التخزين المؤقت للعقد الأخرى.

تسجيل المعاملات

سجل الإعادة وسجل التراجع لـ InnoDB محليان. في البنية المنفصلة، يجب أن يتم توزيع شبكة WAL ويمكن الوصول إليها من خلال جميع العقد.

ما هو موجود بالفعل

بعض مكونات هذه الرؤية موجودة بالفعل في النظام البيئي MariaDB:

MariaDB ColumnStore: محرك تخزين عمودي يمكنه استخدام تخزين S3
Spider: محرك تخزين يقوم بتوزيع البيانات عبر عدة خوادم MariaDB
الاتصال: محرك تخزين يمكنه الوصول إلى مصادر البيانات الخارجية

لا يحقق أي من هذه المحركات فصلًا كاملاً للحساب/التخزين، لكنها تثبت مرونة المعالج API.

الخلاصة

يعد جعل MariaDB سحابيًا أصليًا تحديًا طموحًا ولكنه ليس غير واقعي. يوفر المعالج API نقطة فصل طبيعية لا تتمتع بها PostgreSQL أو Oracle MySQL بشكل نظيف.

لقد أثبت PolarDB التابع لشركة علي بابا أنه ممكن من الناحية الفنية. أثبت PostgreSQL Neon أن السوق متطلب. السؤال ليس "هل هذا ممكن؟" ولكن "من سيفعل ذلك أولاً في مجتمع MariaDB؟"

يمكن أن يبدأ اليوم MariaDB كحاوية عديمة الحالة بسعة 200 ميجابايت، والاتصال بالتخزين الموزع، وتقديم الطلبات بالمللي ثانية - في ذلك اليوم، تتغير اللعبة.

تم نشر هذه المقالة في الأصل على متوسط.

جعل MariaDB سحابيًا أصليًا: فصل الحوسبة عن التخزين