أنواع قواعد بيانات NoSQL

أنواع قواعد بيانات NoSQL

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

مخازن المفاتيح والقيم (Key-Value Stores)

يُعدّ مخزن المفاتيح والقيم أبسط نموذج بيانات ممكن: جدول تجزئة موزع ضخم حيث كل قيمة يُعنوَن إليها بمفتاح مبهم. لا تُبدي قاعدة البيانات أي افتراض حول بنية القيمة — قد تكون نصاً أو كتلة ثنائية أو كائناً مُسلسَلاً أو حتى بنية بيانات معقدة (كما تُبرهن Redis بأنواعها الأصلية كالمجموعات المرتبة والتدفقات).

أمثلة شائعة: Redis، Amazon DynamoDB (في نمط استخدامه الأبسط)، Memcached، Riak KV.

نمط الوصول: GET key، SET key value، DEL key. كل عملية بتعقيد O(1). يمكنك البحث بالمفتاح؛ لكن لا يمكنك الفلترة بالقيمة بكفاءة دون فهرس ثانوي.

أين تتألق:

• تخزين الجلسات — رمز جلسة مؤلف من 64 حرفاً يُعيّن إلى كائن JSON للمستخدم. قراءات في مستوى الميلي ثانية. تخزّن Redis 100 مليون جلسة على عقدة واحدة.
• التخزين المؤقت (Caching) — تخزين نتيجة استعلام قاعدة بيانات مكلف بمفتاح مشتق من الاستعلام. نسبة إصابة بالكاش 95% تعني أن قاعدة البيانات تستقبل طلباً واحداً من كل عشرين فقط.
• تحديد معدل الطلبات — تزايد Redis الذري (INCR + EXPIRE) ينفّذ محددات معدل النافذة المنزلقة دون الحاجة لمعاملة.
• أعلام الميزات — قيمة بوليانية أو كائن JSON بمفتاح feature:{name}:{userId}.

القيود: لا روابط، لا فهارس ثانوية افتراضياً، لا استعلامات غنية. إذا احتجت لاحقاً أن تسأل "أعطني كل المستخدمين الذين اشتراكاتهم من نوع pro"، فإن مخزن المفاتيح والقيم الصرف يُجبرك على مسح كامل أو صيانة فهرس معكوس خاص بك.

مخازن المستندات (Document Stores)

يحفظ مخزن المستندات وثائق شبه منظمة — في الغالب كائنات JSON أو BSON — ويسمح لك بالاستعلام عن الحقول وفهرستها داخل هذه الوثائق. على عكس مخزن المفاتيح والقيم، تفهم قاعدة البيانات البنية الداخلية للقيمة.

أمثلة شائعة: MongoDB، Google Firestore، CouchDB، Amazon DocumentDB.

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

أين تتألق:

• إدارة المحتوى — منشور مدونة يمتلك عنواناً وجسماً وعلامات (مصفوفة) ومؤلفاً (كائن مضمّن) ومجموعة من حقول البيانات الوصفية المتغيرة. يتعامل مخزن المستندات مع هذا بشكل طبيعي؛ بينما يتطلب مخطط علائقي أعمدة nullable أو جداول EAV.
• كتالوجات المنتجات — التلفاز له سمات مختلفة عن القميص. تخزين المنتجات كوثائق يتجنب جدولاً بـ200 عمود حيث 180 منها تكون NULL لأي صف معين.
• ملفات تعريف المستخدمين — التفضيلات والروابط الاجتماعية وسجل النشاط التي تختلف بين أنواع المستخدمين.
• سجلات الأحداث — كل نوع حدث له حمولة مختلفة الشكل.

القيود: الروابط عبر المجموعات مكلفة وتجرى في طبقة التطبيق أو عبر مشغّل $lookup (MongoDB)، وهو بطيء على نطاق واسع. تتفاوت ضمانات الاتساق: تدعم MongoDB معاملات ACID متعددة المستندات منذ الإصدار 4.0، لكنها تتحمل تكلفة أداء كبيرة. الاتساق القوي عبر الشظايا لا يزال أصعب من الأنظمة العلائقية.

مخازن الأعمدة الواسعة (Wide-Column Stores)

تنظّم مخازن الأعمدة الواسعة البيانات على شكل خريطة من الصفوف، حيث يمكن لكل صف أن يمتلك مجموعة مختلفة من الأعمدة، وتُجمَّع الأعمدة في عائلات أعمدة. يجعل تخطيط التخزين الفيزيائي — تخزين كل قيم عائلة أعمدة معاً على القرص — القراءة المتسلسلة لعائلة أعمدة سريعة جداً حتى عبر مليارات الصفوف.

أمثلة شائعة: Apache Cassandra، Google Bigtable، Apache HBase، ScyllaDB.

نموذج البيانات: فكّر في جدول متناثر ضخم. كل صف يمتلك مفتاحاً أساسياً. داخل الصف يمكن أن تكون آلاف الأعمدة، ويمكن أن تمتلك صفوف مختلفة أعمدة مختلفة تماماً. في Cassandra، يحدد مفتاح القسم أي عقدة تمتلك البيانات، ويتحكم مفتاح التجميع في ترتيب الفرز داخل القسم — مما يجعل المسح المتسلسل داخل القسم سريعاً جداً.

أين تتألق:

• بيانات السلاسل الزمنية — قراءات المستشعرات، أسعار الأسهم، مقاييس التطبيقات. نمذجة مفتاح القسم كمعرّف الجهاز/المقياس ومفتاح التجميع كالطابع الزمني تمنحك استعلامات متسلسلة أقل من الميلي ثانية كـ"كل قراءات المستشعر X في الساعة الأخيرة".
• الأحمال الكثيفة الكتابة — تستخدم Cassandra محرك تخزين LSM-tree. الكتابات تذهب دائماً إلى memtable في الذاكرة وتُضاف إلى سجل تنفيذ، مما يمنح إنتاجية كتابة بمئات الآلاف في الثانية لكل عقدة.
• صناديق الرسائل — صندوق بريد Facebook الأصلي بُني على HBase. التقسيم حسب معرّف المستخدم والتجميع حسب الطابع الزمني للرسالة.
• إنترنت الأشياء على نطاق واسع — مليارات الأحداث يومياً من ملايين الأجهزة.

القيود: يجب تصميم نموذج البيانات حول استعلاماتك لا حول كياناتك. إضافة نمط استعلام جديد كثيراً ما تستلزم جدولاً جديداً (نسخة إلغاء التطبيع من البيانات). لا توجد استعلامات مرنة مخصصة كـSQL. لا تدعم Cassandra الروابط وتدعم تجميعاً محدوداً.

قواعد البيانات الرسومية (Graph Databases)

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

أمثلة شائعة: Neo4j، Amazon Neptune، JanusGraph، TigerGraph.

أين تتألق:

• الشبكات الاجتماعية — توصيات الأصدقاء، استعلامات درجات الفصل، الروابط المشتركة. تستخدم LinkedIn تقنية الرسم البياني لتشغيل ميزة "أشخاص قد تعرفهم".
• كشف الاحتيال — يعيد المحتال استخدام عنوان أو جهاز أو رقم هاتف عبر حسابات متعددة. اجتيازات الرسم البياني تكتشف هذه الحلقات في ميلي ثوانٍ؛ الروابط الذاتية في SQL تكافح على العمق ذاته.
• رسوم المعرفة — Google Knowledge Graph وWikidata. الكيانات وعلاقاتها المكتوبة تشكّل العمود الفقري للبحث الدلالي.
• محركات التوصية — "المستخدمون الذين اشتروا X اشتروا أيضاً Y" مُمثَّل كرسم بياني ثنائي الاتجاه من المستخدمين والمنتجات.
• التحكم في الوصول / IAM — توارث الأدوار الهرمي في المنظمات المعقدة.

القيود: لا تتوسع قواعد البيانات الرسومية أفقياً بسهولة كمخازن الأعمدة الواسعة أو المفاتيح والقيم، لأن تقسيم رسم بياني شديد الترابط عبر العقد يُنشئ اجتيازات حواف مكلفة عبر الشظايا. كما أنها ضعيفة في التحليلات التجميعية (count/sum/group-by) على مجموعات البيانات الكبيرة — استخدم مستودع البيانات لذلك.

ملخص مقارن

يختصر الجدول أدناه العائلات الأربع في مرجع سريع لقرارات تصميم الأنظمة:

• Key-Value: النموذج = كتلة مبهمة لكل مفتاح. الكمون = أقل من ميلي ثانية. التوسع = أفقي (تجزئة متسقة). الأنسب لـ: التخزين المؤقت، الجلسات، أعلام الميزات.
• Document: النموذج = وثائق JSON/BSON بحقول مفهرسة. الكمون = ميلي ثوانٍ فردية. التوسع = تشظي أفقي. الأنسب لـ: المحتوى، الكتالوجات، المخططات المرنة.
• Wide-Column: النموذج = جدول متناثر، صفوف بمجموعات أعمدة متغيرة. الكمون = كتابات ميلي ثوانٍ فردية، مسح متسلسل سريع. التوسع = أفقي خطي. الأنسب لـ: السلاسل الزمنية، إنترنت الأشياء، الكتابة المكثفة.
• Graph: النموذج = عقد + حواف بخصائص. الكمون = اجتياز متعدد الخطوات سريع. التوسع = أفقي محدود. الأنسب لـ: الرسوم البيانية الاجتماعية، الاحتيال، التوصيات.