00:00:00عندما تبدأ مشروعاً جديداً وتحتاج إلى قاعدة بيانات، ما هو أول خيار
00:00:03يخطر ببالك؟ SQLite؟ على الأرجح هو SQLite، أليس كذلك؟ أعني، إنه رائع وموثوق،
00:00:09ولا يحتاج إلى إعدادات، ويعتبر معياراً في الصناعة. ولكن مع زيادة حجم بياناتنا المحلية وتعقيد
00:00:14استعلاماتنا، بدأنا نصطدم بسقف ما يمكن لمحرك يعمل بمسار معالجة واحد
00:00:20ويعتمد على قفل الملفات أن يفعله. ولكن الآن هناك لاعب جديد في الساحة يحاول حل هذه المشكلات.
00:00:25يُدعى Stulab، وهو محرك قواعد بيانات مكتوب بالكامل بلغة Rust، وقد أصدر للتو
00:00:31برنامج تشغيل أصلي لـ Node.js يُظهر بصراحة أداءً قوياً للغاية. إن هذه
00:00:36القاعدة أسرع بـ 138 مرة من SQLite. لذا سنقوم في هذا الفيديو بإلقاء نظرة
00:00:43على خبايا Stulab، لنرى كيف يعمل ونقوم بإجراء اختبار قياس أداء حي لنرى ما إذا كان حقاً قوية
00:00:50كما يُزعم. سيكون الأمر ممتعاً للغاية، لذا دعونا نبدأ. ما هو Stulab بالضبط؟
00:01:00حسناً، في جوهره، Stulab هو قاعدة بيانات OLAP مدمجة أو معالجة تحليلية عبر الإنترنت. الآن إذا
00:01:06كنت معتاداً على قواعد البيانات القياسية مثل SQLite أو Postgres، فهذه عادةً ما تكون قواعد بيانات
00:01:14OLTP أو معالجة معاملات عبر الإنترنت، وهي، كما يوحي الاسم، محسنة للمعاملات. ولكن
00:01:20Stulab مختلف. فهو مصمم لأحمال العمل التحليلية ومبني من الصفر بلغة Rust
00:01:27مع التركيز على معالجة البيانات عالية السرعة. فكر فيه كأنه يمتلك سهولة نقل ملف SQLite،
00:01:33ولكن مع القوة التحليلية الخام لشيء مثل DuckDB أو BigQuery. ولكن أروع شيء
00:01:39هو أنه يمكنك الآن استخدامه مع Node.js بفضل برنامج التشغيل الأصلي الخاص به. وعندما أقول
00:01:45إنه برنامج تشغيل أصلي، فأنا لا أتحدث عن مجرد غلاف قياسي. عادةً عندما تكون قاعدة البيانات
00:01:49مكتوبة بلغة مختلفة مثل Rust أو C++، يتعين على تطبيق Node.js الخاص بك التواصل معها عبر جسر.
00:01:56وغالباً ما يعني ذلك تحويل بياناتك إلى JSON أو تنسيق آخر، وإرسالها عبر مقبس شبكة محلي
00:02:02ثم تحويلها مرة أخرى على الطرف الآخر. وهذا ما يسمى عبء التسلسل (serialization overhead) وهو
00:02:08قاتل حقيقي للأداء. لكن Stulab Node يفعل الأشياء بشكل مختلف. فهو يستخدم NAPI-RS،
00:02:15وهو إطار عمل يسمح بتجميع محرك Rust في ملف ثنائي أصلي يتم تحميله
00:02:21مباشرة في عملية Node.js الخاصة بك. لذا لا يوجد جسر ولا مترجم بينهما. فعندما ترسل
00:02:27استعلاماً، يتشارك كل من Node.js و Rust في نفس مساحة الذاكرة تقريباً. وهناك ثلاثة أسباب
00:02:33رئيسية تجعل Stulab سريعاً للغاية. أولاً، استخدامه لـ MVCC أو التحكم في التزامن متعدد الإصدارات.
00:02:40على عكس SQLite حيث يمكن لعملية كتابة واحدة قفل قاعدة البيانات بالكامل، يسمح Stulab لعدة
00:02:47قراء وكتاب بالعمل في نفس الوقت. ثانياً، يستخدم التنفيذ المتوازي. حيث يستخدم Stulab
00:02:53مجدولاً يسمى Rayon. ومع Rayon، عندما تقوم بتشغيل استعلام ضخم، بدلاً من إرساله إلى نواة معالج واحدة،
00:03:00فإنه يقوم بتفكيك هذا الاستعلام واستخدام كل نواة يمتلكها جهازك. وثالثاً، يستخدم مُحسِّناً
00:03:06قائماً على التكلفة. لذا فهو لا ينفذ استعلام SQL الخاص بك بشكل أعمى، بل يحلل بياناتك فعلياً،
00:03:13ويقدر تكلفة المسارات المختلفة، ويختار أسرع طريقة للوصول لنتائجك. هذا هو ما يفترض
00:03:19أن يجعل Stulab خياراً أسرع بكثير من SQLite. ولكن دعونا نختبر ذلك لنرى ما إذا كان هذا حقيقياً.
00:03:25لهذا الاختبار، سنستخدم مشروع Node.js بسيطاً وسنقوم بتثبيت كل من Stulab و
00:03:30SQLite كاعتماديات. إحدى أكبر الانتصارات التي يتألق فيها Stulab حقاً هي استخدام count distinct.
00:03:37لذا أنا فضولي جداً لمعرفة ما إذا كان هذا هو الحال فعلاً. لقد قمت بإعداد هذا السكربت البسيط حيث ننشئ
00:03:43نسخة في الذاكرة من كل قاعدة بيانات وننشئ جدول مبيعات بسيطاً. ثم نملأ هذا الجدول
00:03:49بـ 10,000 صف من بيانات مبيعات عشوائية حيث يمثل كل صف عملية بيع من مستخدم يتراوح معرفه
00:03:56من 0 إلى 1,000 وينتمي لإحدى الفئات المحددة. سنقوم بعد ذلك بإدراج البيانات دفعة واحدة
00:04:03في كلتا قاعدتي البيانات ثم نشغل اختبار الأداء حيث نختار عدداً مميزاً للمبيعات التي أجراها
00:04:10مستخدم معين في فئة معينة ونحسب أداء كل قاعدة بيانات. الآن يجب عليّ
00:04:16ملاحظة أنه من المحبط قليلاً أن الحزمة المثبتة لا تعمل حالياً. فإذا قمنا بتشغيل
00:04:22اختبار الأداء الآن، نرى أنه يشتكي من فقدان ارتباط أصلي (native binding). يبدو أن
00:04:28مؤلف المشروع نسي إضافة الملفات الثنائية أو ربط الملفات الصحيحة بالحزمة. لذا ما توجب عليّ
00:04:34فعله هو بناؤه من المصدر. لقد استنسخت المستودع، وقمت بالبناء داخله، ثم عدت
00:04:39إلى مشروع اختبار الأداء الخاص بي وربطت دليل المصدر الخاص بي كاعتمادية. هذا
00:04:44أمر محبط بعض الشيء في الوقت الحالي، لذا آمل أن يصلح مؤلفو المشروع هذا في المستقبل. ولكن
00:04:49على الرغم من ذلك، بعد القيام بذلك، أصبحنا أخيراً قادرين على تشغيل اختبار الأداء. فلنفعل ذلك الآن.
00:04:54كما ترون، عملية count distinct أسرع بكثير بالفعل على Stulab، وإن لم يكن
00:05:01بالقدر المعلن عنه. إنها أسرع بأربع مرات فقط. ماذا لو أضفنا صفراً آخر إلى عدد
00:05:07البيانات التي نريد تعبئتها ثم قمنا بتشغيل الاختبار مرة أخرى بمليون صف؟ لنحاول ذلك الآن.
00:05:12حتى مع مليون صف، فإن Stulab أسرع بست مرات فقط، وليس 138 مرة. ولكن مع ذلك،
00:05:20لا تزال نتيجة رائعة. كان هذا اختبار count distinct. قررت إجراء اختبار أداء آخر
00:05:26لاختبار عملية distinct + order by. وفي هذا الاختبار الثاني، قمت بإعداد حيث نقوم
00:05:33بإدخال بعض السجلات العشوائية بعناوين IP ورموز حالة مختلفة، ثم نحاول العثور على سجلات
00:05:39فريدة لكل زوج من عنوان IP ورمز الحالة، ثم ترتيبها حسب عنوان IP تصاعدياً ورمز الحالة
00:05:47تنازلياً. وكما ترون، بمجرد تشغيل هذا الاختبار، لا يزال أداء Stulab أفضل من SQLite،
00:05:53ولكن ليس بـ 14 مرة، بل أسرع بـ 1 إلى 1.5 مرة فقط. لذا فإن المقاييس المدرجة هنا مبالغ فيها قليلاً،
00:06:01في رأيي. ولكن مع ذلك، فإن Stulab أسرع بالفعل من SQLite، كما رأينا للتو في الاختبارات.
00:06:08للإنصاف، يذكر المؤلف أيضاً المجالات التي كان فيها أداء SQLite لا يزال أفضل من Stulab. وهذه
00:06:13غالباً ما تكون حالات تقوم فيها بعمليات على صف واحد. لذا فإن Stulab رائع للاستعلامات
00:06:19التحليلية والمعقدة. فهل Stulab هو قاتل SQLite؟ حسناً، في الحقيقة، لا. لقد صُنعا
00:06:26لأغراض مختلفة تماماً. لا يزال SQLite هو خيارك اليومي الموثوق للمعاملات،
00:06:32بينما قد يكون Stulab سيارة سباق عالية الأداء لتحليل البيانات. ولكن حقيقة
00:06:38أن لدينا الآن محركاً تحليلياً بلغة Rust خالصاً يمكننا إدراجه في مشروع Node.js باستخدام NAPI-RS
00:06:45هو أمر رائع حقاً. يحتاج أصحاب المشروع فقط للتأكد من إصلاح حزمة NPM الحالية،
00:06:50حتى لا نضطر لبنائها من المصدر. ها هو ذا Stulab باختصار.
00:06:55ولكن ما رأيكم فيه؟ هل تعزيز الأداء يستحق الانتقال إلى Stulab، أم أنكم متمسكون
00:07:01بموثوقية SQLite؟ أخبرونا في التعليقات أدناه. يا رفاق، إذا وجدتم هذا
00:07:06الفيديو مفيداً، يرجى إخباري من خلال الضغط على زر الإعجاب أسفل الفيديو. وأيضاً لا
00:07:11تنسوا الاشتراك في قناتنا. كان معكم أندريس من Better Stack وسأراكم في
00:07:17الفيديوهات القادمة.