← أحدث الأبحاث
💻 علوم الحاسوب

A Comparative Performance Evaluation of SQL and NoSQL Databases Under Different Indexing and Cache Conditions

تقارن هذه الدراسة بين MySQL 8.0.46 وMongoDB 8.0.32 عبر أحجام مجموعات بيانات واستراتيجيات فهرسة وظروف ذاكرة تخزين مؤقت متفاوتة، مما يكشف أن MongoDB يتفوق في عمليات الكتابة الجماعية بينما يستفيد كلا النظامين بشكل كبير من الفهرسة لعمليات البحث، وهو ما يثبت في النهاية أن أداء قواعد البيانات يعتمد بشكل كبير على السياق بدلاً من كونه متفوقاً بشكل مطلق لأي منهما.

المؤلفون الأصليون: Amir Khan, Sawaira Gull, Arooj Shahzadi

نُشر 2026-11-13✓ Author reviewed ⓘ
📖 5 دقيقة قراءة🧠 قراءة متعمّقة

المؤلفون الأصليون: Amir Khan, Sawaira Gull, Arooj Shahzadi

البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

في العالم الرقمي، يترك كل فعل تقريبًا أثرًا خلفه. عملية شراء، أو تسجيل دخول، أو رسالة مرسلة؛ كل حدث يُخزن في قاعدة بيانات، وهي بمثابة خزانة ملفات إلكترونية ضخمة تحفظ ذاكرة الحياة المعاصرة. ولإبقاء هذه الأنظمة تعمل بسلاسة، يجب على المهندسين الاختيار بين نوعين رئيسيين من أنظمة الملفات. النوع الأول، المعروف بالعلائقي (Relational)، ينظم البيانات في جداول صارمة ذات صفوف وأعمدة محددة، تمامًا مثل جداول البيانات التقليدية. أما النوع الآخر، المسمى NoSQL، فيخزن المعلومات كوثائق مرنة وذاتية الاحتواء يمكن أن تختلف في الشكل والحجم. لسنوات، ظل هناك جدل مستمر حول أي نظام هو الأسرع أو الأفضل. ومع ذلك، فإن الإجابة نادرًا ما تكون بسيطة، لأن السرعة تعتمد كليًا على ما تطلبه من النظام وكيفية البحث في كمية البيانات.

سعت دراسة حديثة إلى حسم هذا السؤال ليس من خلال النظرية، بل عبر تجربة منضبطة. قام الباحثون أمير خان، وسوارا غول، وأرووج شاهزادي ببناء بيئة اختبار على جهاز كمبيوتر واحد لمعرفة كيفية أداء نظامين شائعين، وهما MySQL وMongoDB، تحت ظروف متطابقة. لم يسألوا فقط أيهما أسرع، بل سألوا كيف تتغير السرعة عندما ينمو حجم البيانات من كومة صغيرة إلى جبل هائل، وكيف يؤثر استخدام الفهارس (Indexes) —وهي اختصارات متخصصة تساعد النظام على العثور على المعلومات بسرعة— على النتائج. لقد اختبروا ثلاث مهام محددة: صب كمية كبيرة من البيانات الجديدة في النظام، والعثور على سجل واحد بناءً على اسم محدد، وتجميع العديد من السجلات معًا لحساب إجمالي.

بدأ الباحثون بإنشاء سجلات معاملات اصطناعية، حيث أنشأوا ثلاث مجموعات بيانات منفصلة تحتوي على عشرة آلاف، ومائة ألف، ومليون إدخال. قاموا بتحميل هذه السجلات في كلا نظامي قواعد البيانات وقاسوا الوقت المستغرق لإكمال كل مهمة. في الاختبار الأول، الذي تضمن كتابة جميع البيانات في النظام دفعة واحدة، أثبت النظام القائم على الوثائق، MongoDB، أنه أسرع باستمرار. فعند التعامل مع مليون سجل، أنهى المهمة في حوالي اثني عشر ثلث ثانية تقريبًا، بينما استغرق النظام العلائقي، MySQL، ما يقرب من ثلاثين ثانية. وكان هذا الفرق قائمًا بغض النظر عما إذا كانت مجموعة البيانات صغيرة أم كبيرة، مما يشير إلى أنه بالنسبة لعملية إدخال البيانات الصرفة، كان للنهج القائم على الوثائق ميزة واضحة في هذا الإعداد المحدد.

ركز الاختبار الثاني على العثود على سجل واحد، بشكل مشابه للبحث عن عميل معين باستخدام رقم تعريفه. هنا، قاس الباحثون الوقت المستغرق للعثور على سجل سواء بدون مساعدة أو بمساعدة فهرس. بدون فهرس، كان على النظام مسح كل سجل للعثور على المطابقة. ومع نمو البيانات إلى مليون إدخال، أصبح هذا البحث بطيئًا للغاية، حيث استغرق أكثر من نصف ثانية في كلا النظامين. ومع ذلك، بمجرد أن أضاف الباحثون فهرسًا أحادي الحقل —وهو قائمة بسيطة تشير مباشرة إلى موقع كل معرف— تغيرت النتائج بشكل كبير. فقد انخفض الوقت اللازم للعثود على السجل إلى ما يزيد قلي دوميل ثانية واحدة فقط لكلا النظامين. هذا الانخفاض، الذي تجاوز 99%، أظهر أنه بالنسبة لعمليات البحث البسيطة، فإن نوع قاعدة البيانات كان أقل أهمية من وجود خريطة جيدة لتوجيه البحث.

كان الاختبار الثالث أكثر تعقيدًا، حيث تضمن عملية تجميع مصفاة (Filtered Aggregation). طلب الباحثون من النظام العثور على جميع المعاملات في فئة معينة، وتجميعها حسب حالتها، وجمع المبالغ الإجمالية. هذه المهمة أصعب لأنها لا تتطلب العثور على البيانات فحسب، بل تتطلب أيضًا فرزها وحسابها. في هذا السيناريو، كانت النتائج أقل اتساقًا. فبالنسبة لمجموعات البيانات الأصغر، كان النظام العلائقي أسرع أحيانًا، ولكن مع نمو البيانات إلى مليون سجل، تفوق النظام القائم على الوثائق بشكل ملحوظ. فقد أكمل النظام المعتمد على الوثائق المهمة في حوالي ثلاثمائة مللي ثانية، بينما استغرق النظام العلائقي أكثر من ثانية.

ربما ظهرت النتيجة الأكثر إثارة للدهشة خلال هذا الاختبار الثالث مع أكبر مجموعة بيانات. فعندما استخدم الباحثون فهرسًا على حقل الفئة لتسريع النظام العلائقي، أصبحت المهمة في الواقع أبطأ مما كانت عليه بدون فهرس على الإطلاق. استغرق النظام أكثر من ثانية مع الفهرس، مقارنة بنحو سبعمائة مللي ثانية بدونه. لم تكن هذه النتيجة المناقضة للمنطق خطأً؛ فقد كرر الباحثون الاختبار بشكل مستقل وأكدوا أن الفهرس كان بالفعل يسبب تأخيرًا في هذا التكوين المحدد. يبدو أنه بالنسبة لهذا النوع من الحسابات المعقدة، فإن العبء الإضافي لاستخدام الفهرس فاق فوائده، وهو تفصيل دقيق قد تغفله نتيجة بسيطة مثل "واحد أسرع من الآخر".

كما بحثت الدراسة في كيفية سلوك الأنظمة عندما تكون "دافئة" (Warm)، مما يعني أنها عالجت طلبات مماثلة مؤخرًا وأن البيانات جاهزة في ذاكرتها. في هذه الظروف، أصبح كلا النظامين أسرع، لكن درجة التحسن تباينت. شهد النظام القائم على الوثائق دفعة كبيرة في سرعة التجميع لديه عندما يكون دافئًا، بينما أظهر النظام العلائقي مكسبًا أكثر تواضعًا. تعزز هذه النتائج أن الأداء ليس خاصية ثابتة للبرنامج نفسه، بل هو نتيجة مرنة للتفاعل بين حجم البيانات، ونوع الاستعلام، ووجود الفهارس، والحالة الراهنة لذاكرة النظام.

في النهاية، تخلص الدراسة إلى أنه لا يوجد فائز عالمي. لا يمكن اتخاذ القرار بشأن الاختيار بين هذين النموذجين لقواعد البيانات بناءً على اختبار سرعة واحد. فإذا كان الهدف هو إدخال كميات هائلة من البيانات الجديدة بسرعة، فقد أظهر النظام القائم على الوثائق تميزًا واضحًا. وإذا كان الهدف هو استرجاع سجل واحد، فإن كلا النظامين يؤديان بشكل متساوٍ طالما وجد فهرس مناسب. ومع ذلك، بالنسبة للحسابات المعقدة التي تتضمن أحجامًا كبيرة من البيانات، يمكن أن يتأرجح الأداء اعتمادًا على كيفية هيكلة البيانات وفهرستها. وتعد هذه الدراسة بمثابة تذكير بأنه في عالم البيانات، تعتمد الأداة المناسبة تمامًا على المهمة المحددة، وأن المسار الأكثر كفاءة غالبًا ما يتم العثور عليه ليس باختيار علامة تجارية، بل بفهم الشكل الفريد للعمل المراد القيام به.

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →