إن شعبية نظامي قواعد البيانات هذين ترجع جزئيًا إلى قابليتهما العالية للتوسع وتوافرهما الدائم. صدر كلاهما للاستخدام منذ أكثر من عقد من الزمان: تم إطلاق Cassandra كمشروع مفتوح المصدر في عام 2008، بينما صدر MongoDB في العام التالي.
على الرغم من أوجه التشابه، فإن Apache Cassandra و MongoDB يختلفان بشكل كبير فيما يتعلق بنماذج البيانات، والبنية، والمكونات الأخرى. تؤثر هذه الاختلافات الأساسية على أدائها فيما يتعلق بالخصائص الرئيسية، ويمكن أن تؤثر أيضًا على حالات استخدام إدارة البيانات التي تخدمها بشكل أفضل.
قبل مقارنة Apache Cassandra و MongoDB، من المفيد ترسيخ فهم لقواعد بيانات NoSQL.
قواعد بيانات NoSQL، قواعد بيانات NoSQL، التي يُشار إليها أيضًا باسم قواعد بيانات "not only SQL" أو "non-SQL"، هي قواعد بيانات موزعة. وهذا يعني أن المعلومات الموجودة بداخلها تخضع للتكرار إلى عُقد مختلفة (وهي خوادم فردية تقوم بتخزين البيانات). تدعم هذه البنية الموزعة التوافر العالي والمتانة؛ فإذا توقفت عقدة واحدة أو أكثر عن العمل، يمكن لبقية قاعدة البيانات الاستمرار في التشغيل.
لكن الأهم من ذلك، أن قواعد بيانات NoSQL مصممة لتخزين البيانات والاستعلام عنها خارج الهياكل التقليدية الموجودة في أنظمة إدارة قواعد البيانات العلائقية. بدلاً من الالتزام ببنية جدولية صارمة متأصلة في قواعد البيانات العلائقية التقليدية، لا يتطلب تصميم قواعد البيانات غير العلائقية مخططًا صارمًا. يتيح ذلك قابلية التوسع السريع لإدارة مجموعات البيانات الكبيرة، بما في ذلك مجموعات البيانات المنظمة وشبه المنظمة وغير المنظمة.
(من المهم ملاحظة أن قابلية التوسع التي تحظى بتقدير كبير في قواعد بيانات NoSQL، بما في ذلك Cassandra و MongoDB، هي قابلية التوسع الأفقي أو "scaling out". في قابلية التوسع الأفقي، يمكن تقسيم أعباء العمل على عدة خوادم، على عكس قابلية التوسع العمودي أو "scaling up" المرتبطة بقواعد بيانات SQL، والذي يتطلب إضافة المزيد من الذاكرة للأجهزة الموجودة.)
لقد برزت قواعد بيانات NoSQL كخيار مفضل لدعم تطبيقات البيانات الكبيرة وأحمال التشغيل في الوقت الفعلي، وذلك بفضل أدائها وقابليتها للتوسع ومرونتها. بالإضافة إلى Apache Cassandra و MongoDB، تشمل قواعد بيانات NoSQL الشائعة الأخرى DynamoDB (المقدمة من AWS) و Redis و CouchDB.
النشرة الإخبارية الخاصة بالمجال
ابقَ على اطلاع دومًا بأهم—اتجاهات المجال وأكثرها إثارة للفضول—بشأن الذكاء الاصطناعي والأتمتة والبيانات وغيرها الكثير مع نشرة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيتم تسليم اشتراكك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك هنا. راجع بيان خصوصية IBM لمزيد من المعلومات.
على الرغم من أن كليهما نشأ بعد بضع سنوات فقط من مطلع الألفية، إلا أن لكل من Apache Cassandra و MongoDB تاريخًا مميزًا.
يعود تاريخ Apache Cassandra إلى Facebook في عام 2007 تقريبًا، عندما سعى المهندسون لإنشاء نظام يمكنه تخزين البيانات لمنصة المراسلة المتنامية للشركة. بتوليفة بين نماذج قواعد بيانات NoSQL المعمول بها، أنشأوا نظامًا يتمتع بهياكل بيانات فعّالة واتساق نهائي—حيث تنتشر التحديثات حتى تتطابق جميع النسخ المتماثلة بمرور الوقت. أصدر المهندسون Cassandra كمشروع مصدر مفتوح في عام 2008. وبعد مرور عام، تولت مؤسسة Apache Software مسؤولية الإشراف.
بدأت MongoDB كجزء من مشروع منصة كخدمة من شركة 10Gen في عام 2007. حوَّلت الشركة تركيزها إلى MongoDB—الذي سُميَ تلاعباً بكلمة "humongous" (ضخم جداً)- وطوّرته ليكون قاعدة بيانات موجهة للمستندات، تعمل بسرعة وسهلة الاستخدام. 1
أطلقت شركة 10Gen، التي غيرت اسمها لاحقًا إلى MongoDB Inc.، مشروع MongoDB كمشروع مفتوح المصدر في عام 2009. أحدث إصدارات MongoDB، ومع ذلك، يتم نشرها بموجب الترخيص العام من جانب الخادم الإصدار الأول.
الاختلافات الجوهرية بين Apache Cassandra و MongoDB تؤثر على أدائهما وحالات الاستخدام المثلى لكل منهما. وتشمل العناصر الرئيسية ما يلي:
تعتمد قواعد بيانات NoSQL على واحد من أربعة أنواع من نماذج البيانات:
نموذج بيانات Cassandra هو نموذج عمود واسع، ويعرف أيضًا باسم تخزين العمود الواسع. يحتوي كل صف في جدول Cassandra على مجموعة من الأعمدة ومفتاح تقسيم فريد يستخدم لتوزيع البيانات عبر العقد ومراكز البيانات. يتم تعريف الصفوف بواسطة مفاتيح أساسية، والتي يمكن أن تتكون من مفاتيح تقسيم و، بشكل اختياري، مفاتيح تجميع (وهي أعمدة يمكنها تحديد الصفوف بشكل فريد داخل مجموعة أو قسم واحد).
هذا الأسلوب أكثر مرونة من أسلوب قواعد البيانات العلائقية، التي يتم فيها تخصيص مساحة لعدد ثابت من الأعمدة. من خلال نموذج بيانات Cassandra، يؤدي استخدام الأعمدة الضرورية فقط إلى تخزين أكثر كفاءة واستعلامات أسرع. 2
في المقابل، يستخدم MongoDB نموذج مستند. تُخزَّن البيانات بشكل أساسي بصيغة BSON، وهي تمثيل ثنائي لـ JSON تم تطويره بواسطة MongoDB.
تم تطوير BSON لمعالجة العقبات التي كانت تواجهها صيغة JSON القياسية في قواعد البيانات، وهي: محدودية أنواع البيانات التي تدعمها، وعدم وجود طول ثابت للكائنات (مما يبطئ سرعة التنقل بينها)، وافتقارها إلى البيانات الوصفية (التي تبطئ استرجاع المستندات). تم تصميم BSON لتحقيق أقصى قدر من السرعة والكفاءة عن طريق ترميز معلومات التنسيق والطول. كما أنها تدعم بعض أنواع بيانات JSON غير الأصلية، مثل التواريخ والبيانات الثنائية. 3
قواعد بيانات NoSQL، مثل Apache Cassandra و MongoDB، تدعم الأنظمة الموزعة، مع تخزين البيانات عبر عدة موارد حاسوبية للحد من فترات التعطل. ولكن، وكما هو الحال مع نماذج بياناتهما، فإن البنية التي يقوم عليها هذا التوزيع مختلفة بشكل جوهري.
تعتمد Apache Cassandra على بنية نظير إلى نظير. كل عقدة في مجموعة Cassandra متساوية، دون الاعتماد على العقدة الرئيسية. عندما يتم وضع البيانات في مجموعة، يتم تطبيق دالة تجزئة على مفتاح التقسيم الخاص بالصف، ويتم استخدام الناتج لتعيين البيانات إلى عقد محددة. يتم أيضًا نسخ البيانات إلى العقد الأخرى.
يصف عامل التكرار لقاعدة بيانات Cassandra عدد نسخ البيانات المخزنة في قاعدة البيانات. يستخدم محرك التخزين في Cassandra تدفقًا متدرجًا (أو مسار كتابة) يتكون من: سجل الالتزام، وجدول في الذاكرة، وملفات جدول السلاسل المرتبة.
على عكس Cassandra، يستخدم MongoDB نموذجًا أساسيًا / ثانويًا لبنيته الموزعة. في MongoDB، تتألف مجموعة النسخ المتماثلة (مجموعة من المثيلات) عقدة أساسية تتعامل مع جميع عمليات الكتابة (إضافة البيانات أو تعديلها)، وعقد ثانوية تعكس البيانات الموجودة في العقدة الأساسية.
يمكن أيضًا توزيع مجموعات البيانات الكبيرة في MongoDB على أجهزة متعددة من خلال عملية تُعرف باسم التجزئة. تُقسَّم المعلومات إلى مجموعات مجزأة—وهي عبارة عن مجموعات نسخ متماثلة متعددة، ومُوجِّه يقوم بنقل الاستعلامات من التطبيقات إلى مجموعات النسخ المتماثلة—وذلك لتحسين قدرة النظام على التعامل مع طلبات البيانات.
وتستخدم قواعد البيانات أيضًا أساليب فهرسة مختلفة. في Apache Cassandra، يُعد المفتاح الأساسي هو مفتاح التقسيم، على الرغم من أن وثائق Cassandra تشير إلى أن الفهرسة المرفقة-بالتخزين (التي تتضمن فهارس للأعمدة غير التقسيمية) تُعد مناسبة لمعظم حالات الاستخدام. 4 Cassandra لديها أيضًا فهارس ثانوية، وهي فهارس محلية تُخزن في جداول منفصلة عن القيم التي يتم فهرستها. يدعم MongoDB عدة أنواع مختلفة من الفهارس لتناسب حالات استخدام متنوعة، بما في ذلك الفهارس الجغرافية المكانية، والفهارس متعددة المفاتيح، وفهارس النصوص.
بحكم التعريف، لا تستخدم قواعد بيانات NoSQL لغة الاستعلام الهيكلية (SQL) وهي لغة البرمجة القياسية لقواعد البيانات العلائقية. ومع ذلك ، فإن كلاً من Apache Cassandra و MongoDB لهما لغات الاستعلام الخاصة بهما.
تستخدم Cassandra نسخة مخصصة من لغة SQL تُسمى لغة استعلام Cassandra (CQL). على الرغم من أن CQL تشبه SQL إلى حد كبير، إلا أن هناك اختلافات جوهرية بين الاثنتين. على سبيل المثال، تعمل SQL على جداول في حالتها المعيارية، بينما تم تصميم CQL لبيانات Cassandra اللامعيارية والمتوافقة مع مفاتيح التقسيم. بالإضافة إلى ذلك، فإن لغة SQL مُحسّنة للمعاملات، بينما لغة CQL مُصممة للاستعلامات في الوقت الفعلي وعمليات الكتابة عالية الحجم.
تستخدم MongoDB لغة استعلام MongoDB (MQL). صُممت للاستعلام عن نماذج المستندات، وتشترك لغة استعلام MQL في البنية النحوية ذاتها للمستندات—مما يمثل ابتعاداً عن لغة SQL أكبر من ابتعاد لغة استعلام Cassandra. وُصفت MQL على أنها تمكِّن مجموعة من قدرات الاستعلام ومعالجة البيانات، بما في ذلك الاستعلامات المعقدة، ومسارات تجميع البيانات، واستعلامات البيانات الجغرافية المكانية 5
بالإضافة إلى لغات الاستعلام الخاصة بكل منها، تختلف قواعد البيانات في دعم البرمجة. توفر MongoDB برامج تشغيل رسمية لأكثر من اثنتي عشرة لغة برمجة، مثل Java و Python و Ruby و Node.js. تتوافق هذه اللغات وغيرها مع Cassandra، ولكن يتم توفير برامج التشغيل الخاصة بها إلى حد كبير من قِبل جهات خارجية.
تنشأ بعض الاختلافات في الخصائص المرتبطة بأدائهما نتيجة للفروق الأساسية بين Apache Cassandra و MongoDB. يمكن أيضا تفسير هذه الاختلافات من خلال نظرية CAP.
CAP هي اختصار يمثل ثلاث خصائص مرغوبة في الأنظمة الموزعة: الاتساق (حيث يرى جميع العملاء نفس البيانات في الوقت ذاته)، والتوافر (حيث يتلقى أي عميل يطلب البيانات استجابة، حتى لو تعطلت عقدة واحدة أو أكثر)، وتحمل الانقسام (حيث تستمر مجموعة العقد في العمل حتى في خضم أعطال الاتصال بين عقدتين أو أكثر).
نظرية CAP تفرض أن أي نظام موزع يمكنه توفير خاصيتين فقط من ثلاث خصائص مرغوبة. تُصنّف Apache Cassandra بشكل عام كقاعدة بيانات من نوع "AP"، حيث توفر أداءً عاليًا يركز بشكل أساسي على التوافر وتحمل الانقسام.
في الوقت نفسه، تُعرف MongoDB بأنها قاعدة بيانات من نوع "CP"، وهي تتفوق في جوانب تحمل الانقسام والاتساق. ولكن بالنسبة لقواعد البيانات كلتيهما، توجد أيضًا تدابير لتحسين الأداء في الخصائص التي يُزعم أنها مُخترقة—أي الاتساق بالنسبة لـ Cassandra، والتوافر بالنسبة لـ MongoDB.
دعونا نلقي نظرة عن كثب على الخصائص الثلاث المرغوبة.
تتمتع Cassandra بدعم عالٍ للتوافر، وذلك لأنها نظام لامركزي يتم فيه نسخ البيانات إلى عدة عُقد، مما يمنحها قدرة عالية على تحمل الأخطاء وعدم وجود نقطة فشل واحدة. ذا تعرضت إحدى العقد للتوقف، يمكن للعقد الأخرى التي تحتوي على نسخ من نفس البيانات تلبية طلب البيانات. بالإضافة إلى ذلك، فإن تكرار البيانات إلى مراكز البيانات حول العالم يتيح زمن وصول قصير للمستخدمين المحليين.
بما أن بنية MongoDB تعتمد على نموذج رئيسي/ثانوي، يمكن أن تحدث نقطة فشل واحدة عندما تتعطل العقدة الرئيسية. ومع ذلك، يُعتبر تجاوز الفشل في MongoDB قويًا: فخلال ما يُعرف بانتخابات مجموعة النسخ المتماثلة، تختار العُقد التابعة لمجموعة النسخ المتماثلة عُقدة أساسية جديدة لتحل محل العُقدة الأساسية غير المتاحة. تتيح هذه العملية أيضًا لـ MongoDB توفير توافر عالي، وإن كان ذلك مع تأخير وجيز—حيث لا تستأنف الأداء إلا بعد اختيار العقدة الأساسية الجديدة.
توفر MongoDB بطبيعتها اتساقًا عاليًا لأن جميع العملاء يكتبون إلى مصدر واحد للحقيقة—فكل مجموعة نسخ متماثلة يمكن أن تحتوي على عقدة أساسية واحدة فقط تتلقى جميع عمليات الكتابة. في المقابل، توفر Apache Cassandra الاتساق النهائي: يمكن للعملاء الكتابة على أي عقدة في أي وقت، ومن ثم تتم تسوية التناقضات بأسرع ما يمكن.
يسمح Cassandra أيضا للمستخدمين بتحسين الاتساق (مع تقليل الأولوية للتوافر) من خلال ما يعرف بالاتساق القابل للضبط. يمكن للمستخدمين تحديد مستوى الاتساق، والذي يحدد عدد النسخ المتماثلة التي يجب أن تقرأ أو تكتب البيانات وتؤكدها قبل تأكيد العملية لتطبيق العميل. تتطلب مستويات الاتساق الأعلى استجابة المزيد من النسخ المتماثلة بإقرارات، ولكن هذا يزيد أيضًا من زمن الانتقال ويقلل من التوافر.
كلا من Apache Cassandra و MongoDB يوفران تحمل تقسيم الشبكة لأنهما مصممان لمواصلة العمل حتى عند حدوث خلل في الاتصالات في جزء واحد من النظام.
في Apache Cassandra، تظل العُقد متاحة في حال حدوث مشكلة في الاتصال، لكن بعض العقد قد لا تُسلِّم أحدث إصدارات البيانات (استجابةً لطلبات البيانات) حتى يتم حل التقسيم. في MongoDB، يكون التوافر محدودًا لضمان تماسك البيانات أثناء معالجة التقسيم.
Apache Cassandra غالبًا ما يُوصى به لأعباء العمل ذات معدل النقل العالي، والموزعة عالميًا، والكثيفة في عمليات الكتابة، حيث تكون كل من التوافر وقابلية التوسع أمرًا بالغ الأهمية، كما في مجالات البث والترفيه. على سبيل المثال، خدمات البث مثل Netflix تستخدم Cassandra للتعامل مع نشاط المستخدم العالمي.
تُعد MongoDB مثاليًا لحالات استخدام المخططات المرنة التي تتمحور حول المستندات والتي تستفيد من سرعة المطورين والاتساق القوي. غالبًا ما تعتمد الشركات على MongoDB لدعم أنظمة إدارة المحتوى الخاصة بها لأن MongoDB تقوم بتخزين وخدمة مجموعة متنوعة من أصول المحتوى.
على الرغم من الاختلافات بين قاعدتي البيانات، هناك حالات استخدام لـ Apache Cassandra وحالات استخدام لـ MongoDB يمكن أن تتداخل. وتوضح دراسات الحالة لكل قاعدة بيانات مدى فعاليتها في تطبيقات إنترنت الأشياء (IoT) والتجارة الإلكترونية والمزيد.
صمم استراتيجية بيانات تقضي على صوامع البيانات، وتقلل من التعقيدات وتحسّن جودة البيانات للحصول على تجارب استثنائية للعملاء والموظفين.
يتيح لك watsonx.data توسيع نطاق التحليلات والذكاء الاصطناعي باستخدام جميع بياناتك، أينما كانت، من خلال مخزن بيانات مفتوح وهجين ومُدار.
استفِد من قيمة بيانات المؤسسة باستخدام IBM Consulting، من خلال بناء مؤسسة تعتمد على الرؤى التي تقدِّم ميزة للأعمال.
1 Plugge, E., Membrey, P. and Hawkins, T. “The Definitive Guide to mongodb: The nosql database for Cloud and desktop computing”(PDF), Tenth Edition, Apress, 2010.
2 Carpenter, J. and Hewitt, E. “Cassandra The Definitive Guide: Distributed Data at Web Scale” (PDF)” , Third Edition, O’Reilly, 2020.
3 “JSON and BSON”, MongoDB, 9 September 2025.
4 “Cassandra Query Language : Indexing concepts“ , Apache Foundation, 10 September 2025
5 Rathore, M. and Bagui, S.S. “MongoDB: Meeting the Dynamic Needs of Modern Applications“. Encyclopedia, 27 September 2024.