دليل NoSQL للمطورين

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

لماذا نحتاج فجأة إلى قاعدة بيانات جديدة؟

قد تحتار عندما تسأل: ما هو الخطأ في قواعد البيانات العلائقية؟ النقطة المهمة هي أنهم عملوا بشكل جيد لسنوات عديدة، ولكن الآن هناك مشكلة لم يعد بإمكانهم التعامل معها. وفقا لبعض التوقعات، في عام 2018 سوف تنتج البشرية 50 ألف غيغابايت من البيانات في الثانية. هذه كمية هائلة من البيانات! يشكل تخزينها ومناولتها تحديًا هندسيًا خطيرًا. والأسوأ من ذلك هو أن هذا الحجم يتزايد باستمرار. كما اتضح، فإن قواعد البيانات العلائقية غير مناسبة للتعامل مع كميات كبيرة من البيانات. وهي مصممة للعمل على جهاز واحد، وإذا كنت ترغب في التعامل مع المزيد من الطلبات، فإن الخيار الوحيد هو شراء جهاز كمبيوتر مزود بذاكرة وصول عشوائي (RAM) أكبر ومعالج أكثر قوة. لسوء الحظ، عدد الاستعلامات التي يمكن لجهاز واحد التعامل معها محدود، وبالنسبة للعمل الموزع عبر أجهزة متعددة، نحتاج إلى تقنية قاعدة بيانات مختلفة. بالطبع، سوف يضحك بعض القراء عند هذه النقطة ويقولون إن هناك طريقتين مستخدمتين على نطاق واسع لاستخدام أجهزة متعددة في حالة قاعدة البيانات العلائقية: النسخ المتماثل والمشاركة. وهذا صحيح، ولكن هذه الأساليب ليست كافية للتعامل مع مهامنا. النسخ المتماثل للقراءة هو أسلوب يتم من خلاله نشر كل تحديث لقاعدة البيانات إلى الأجهزة الأخرى التي يمكنها التعامل مع طلبات القراءة فقط. في هذه الحالة، يتم تنفيذ جميع التغييرات بواسطة خادم واحد، يسمى العقدة الرئيسية، بينما تحتفظ الخوادم الأخرى، التي تسمى النسخ المتماثلة للقراءة، بنسخ من البيانات فقط. يمكن للمستخدم القراءة من أي جهاز، ولكن تغيير البيانات فقط من خلال العقدة الرئيسية. هذه طريقة مريحة وشائعة جدًا، ولكنها تسمح لك فقط بمعالجة المزيد من طلبات القراءة ولا تحل بأي شكل من الأشكال مشكلة معالجة كميات البيانات المطلوبة. المشاركة هي طريقة شائعة أخرى تستخدم مثيلات متعددة لقاعدة بيانات علائقية. ويتولى كل منهم عمليات الكتابة والقراءة لجزء من البيانات. إذا قامت قاعدة بيانات بتخزين معلومات حول العملاء، على سبيل المثال، باستخدام التقسيم، فيمكن لجهاز واحد التعامل مع جميع طلبات العملاء الذين تبدأ أسماؤهم بالحرف A، ويمكن لجهاز آخر تخزين جميع البيانات للعملاء الذين تبدأ أسماؤهم بالحرف B، وهكذا. على الرغم من أن التجزئة تسمح لك بتسجيل المزيد من البيانات، فإن إدارة قاعدة البيانات هذه تعد كابوسًا حقيقيًا: يجب عليك محاذاة البيانات عبر الأجهزة وتوسيع نطاق المجموعة في كلا الاتجاهين حسب الحاجة. على الرغم من أن الأمر يبدو بسيطًا من الناحية النظرية، إلا أن تحقيقه بشكل صحيح يمثل تحديًا كبيرًا.

هل يمكن تحسين قواعد البيانات العلائقية؟

أعتقد أنك أصبحت تعتقد بالفعل أن قواعد البيانات العلائقية ليست هي الأنسب لحجم البيانات التي يتم إنشاؤها في العالم الحديث. على الرغم من أنك ربما لا تزال تتساءل لماذا لم يقم أحد حتى الآن بإنشاء قاعدة بيانات علائقية "أفضل" يمكن تشغيلها بكفاءة عبر أجهزة متعددة. قد يبدو أن هذه التكنولوجيا ببساطة لم يتم تطويرها بعد، وسوف تظهر قواعد البيانات العلائقية الموزعة قريبا جدا. للأسف، هذا لن يحدث. وهذا مستحيل رياضيا، ولا يمكن فعل أي شيء حيال ذلك. لفهم سبب ذلك، تحتاج إلى إلقاء نظرة على ما يسمى بنظرية CAP (المعروفة أيضًا باسم نظرية بروير). وقد تم إثبات ذلك في عام 1999، وينص على أن قاعدة البيانات الموزعة التي تعمل على أجهزة متعددة يمكن أن تحتوي على الخصائص الثلاثة التالية: الاتساق - أي عملية قراءة تقوم بإرجاع نتائج آخر عملية كتابة مقابلة. إذا كان النظام متسقًا، بعد كتابة بيانات جديدة، فمن المستحيل قراءة البيانات القديمة التي تمت الكتابة فوقها بالفعل. التوفر ( التوفر ) - يمكن للنظام الموزع خدمة طلب وارد في أي وقت وإرجاع استجابة خالية من الأخطاء. التسامح مع القسم - تستمر قاعدة البيانات في الاستجابة لطلبات القراءة والكتابة حتى عندما تكون بعض خوادمها غير قادرة مؤقتًا على التواصل مع بعضها البعض. يُسمى هذا الفشل المؤقت بفشل اتصال الشبكة ويمكن أن يحدث بسبب مجموعة متنوعة من العوامل، بدءًا من مشكلات الشبكة الفعلية بسبب الخادم البطيء إلى الأضرار المادية التي لحقت بمعدات الشبكة. من المؤكد أن كل هذه الخصائص مفيدة، ونرغب حقًا في إنشاء قاعدة بيانات لدمجها جميعًا. لن يرغب أي مطور عاقل في التخلي عن إمكانية الوصول، على سبيل المثال، دون الحصول على أي شيء في المقابل. ولسوء الحظ، تنص نظرية CAP أيضًا على أنه من المستحيل أن تبقى الخصائص الثلاثة في وقت واحد. قد لا يكون تحقيق ذلك أمراً سهلاً، لكنه ممكن. أولاً، إذا كنا بحاجة إلى قاعدة بيانات موزعة، فيجب أن تكون "متسامحة مع انقطاع الاتصال". لم تتم مناقشة هذا حتى. تحدث عمليات قطع الاتصال طوال الوقت ويجب أن تعمل قاعدة بياناتنا بالرغم من ذلك. الآن دعونا نفهم لماذا لا يمكننا تحقيق كل من الاتساق والتوافر. تخيل أن لدينا قاعدة بيانات بسيطة تعمل على جهازين: A وB. ويمكن لأي مستخدم الكتابة على أي من الجهازين، وبعد ذلك يتم نسخ البيانات إلى الجهاز الآخر. تخيل الآن أن هذه الأجهزة غير قادرة مؤقتًا على التواصل مع بعضها البعض، وأن الجهاز B غير قادر على إرسال البيانات إلى الجهاز A أو استقبال البيانات منه. إذا تلقى الجهاز "ب" خلال هذه الفترة الزمنية طلب قراءة من العميل، فسيكون لديه خياران:

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

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

كيف توازن قواعد بيانات NoSQL بين الاتساق والتوافر؟

قد يبدو لك أنه إذا اخترت قاعدة بيانات NoSQL، فسوف تتلقى دائمًا إما بعض البيانات القديمة أو خطأ في حالة حدوث أي فشل. ومن الناحية العملية، فإن التوفر والاتساق ليسا بأي حال من الأحوال الخيارين الوحيدين المتاحين. هناك مجموعة واسعة من الخيارات المتاحة لتختار من بينها. لا تحتوي قواعد البيانات العلائقية على هذه الخيارات، لكن NoSQL يسمح لك بالتحكم في تنفيذ الاستعلام بطريقة مماثلة. بطريقة أو بأخرى، فإنها تسمح لك بتعيين معلمتين عند إجراء عمليات الكتابة أو القراءة في قاعدة بيانات NoSQL: ث - عدد الأجهزة في المجموعة التي يجب أن تؤكد حفظ البيانات عند إجراء عملية الكتابة . كلما زاد عدد الأجهزة التي تكتب فيها بياناتك، أصبح من الأسهل قراءة أحدث البيانات في عملية القراءة التالية، ولكن أيضًا ستستغرق وقتًا أطول. R - عدد الأجهزة التي ترغب في قراءة البيانات منها . في النظام الموزع، قد يستغرق توزيع البيانات على جميع الأجهزة في المجموعة بعض الوقت، لذلك ستحتوي بعض الخوادم على أحدث البيانات بينما ستتأخر خوادم أخرى. كلما زاد عدد الأجهزة التي تتم قراءة البيانات منها، زادت فرص قراءة البيانات الحالية. دعونا نلقي نظرة على مثال عملي. إذا كان لديك خمسة أجهزة كمبيوتر في مجموعتك، وقررت كتابة البيانات على جهاز واحد فقط، ثم قراءة البيانات من جهاز كمبيوتر واحد تم اختياره عشوائيًا، فهناك احتمال بنسبة 80% أنك ستقرأ البيانات القديمة. ومن ناحية أخرى، سيستخدم هذا الحد الأدنى من الموارد. لذا، إذا كانت البيانات القديمة مناسبة لك، فهي ليست خيارًا سيئًا. في هذه الحالة، المعلمات W وR تساوي 1. من ناحية أخرى، إذا قمت بكتابة البيانات على جميع الأجهزة الخمسة في قاعدة بيانات NoSQL، فيمكنك قراءة البيانات من أي جهاز وتضمن حصولك على بيانات محدثة في كل مرة. سيستغرق تنفيذ نفس العملية على عدد أكبر من الأجهزة وقتًا أطول، ولكن إذا كانت البيانات المحدثة مهمة بالنسبة لك، فيمكنك اختيار هذا الخيار. في هذه الحالة، W = R = 5. ما هو الحد الأدنى لعدد عمليات القراءة والكتابة المطلوبة لتناسق قاعدة البيانات؟ فيما يلي صيغة بسيطة: R + W ≥ N + 1 ، حيث N هو عدد الأجهزة في المجموعة. وهذا يعني أنه مع خمسة خوادم، يمكنك اختيار إما R = 2 وW = 4، أو R = 3 وW = 3، أو R = 4 وW = 2. في هذه الحالة، لا يهم الأجهزة التي يتم إرسال البيانات إليها تمت كتابته، وستتم القراءة دائمًا من جهاز واحد على الأقل يحتوي على بيانات محدثة. قواعد البيانات الأخرى، مثل DynamoDB، لها قيود مختلفة وتسمح فقط بالكتابة المتسقة. يتم تخزين كل جزء من البيانات على ثلاثة خوادم، وعندما تتم كتابة أي بيانات، يتم كتابتها على جهازين من الأجهزة الثلاثة. ولكن عند قراءة البيانات، يمكنك اختيار أحد الخيارين:

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

لماذا يوجد الكثير من قواعد بيانات NoSQL؟

إذا كنت تتابع آخر الأخبار في مجال تطوير البرمجيات، فمن المحتمل أنك سمعت عن العديد من قواعد بيانات NoSQL المختلفة، مثل MongoDB وDynamoDB وCassandra وRedis وغيرها الكثير. قد تتساءل: لماذا نحتاج إلى العديد من قواعد بيانات NoSQL المختلفة؟ السبب بسيط: أن قواعد بيانات NoSQL المختلفة مصممة لحل مشكلات مختلفة. وهذا هو السبب في أن عدد قواعد البيانات المتنافسة كبير جدًا. تنقسم قواعد بيانات NoSQL إلى أربع فئات رئيسية:

قواعد البيانات الموجهة نحو الوثائق

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

قواعد بيانات المفتاح/القيمة

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

قواعد بيانات الرسم البياني

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

قواعد البيانات العمودية

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

ما هي قاعدة البيانات التي يجب أن تختارها؟

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

كيف من المفترض أن تتعلم كل هذا؟

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

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


2. دينامو دي بي . إذا كنت تستخدم Amazon Web Services (AWS)، فمن الأفضل أن تتعلم المزيد عن DynamoDB. إنها قاعدة بيانات موثوقة للغاية وقابلة للتطوير ومنخفضة زمن الاستجابة مع مجموعة ميزات غنية وتكامل مع العديد من خدمات AWS الأخرى. أفضل جزء هو أنه ليس عليك نشره بنفسك. لا يستغرق إعداد مجموعة DynamoDB القابلة للتطوير والتي يمكنها التعامل مع آلاف الاستعلامات سوى بضع نقرات. إذا كان هذا يهمك، يمكنك إلقاء نظرة على هذه الدورة .


3. Neo4j . قاعدة بيانات الرسم البياني الأكثر شيوعا. يعد هذا حلاً مستقرًا وقابلاً للتطوير ومناسبًا لأولئك الذين يرغبون في استخدام نموذج بيانات الرسم البياني. إذا كنت تريد معرفة المزيد، ابدأ بهذه الدورة .


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

في عام 2018 مع NoSQL

تعد قواعد بيانات NoSQL مجالًا واسعًا وسريع النمو. إنها تسمح لك بتخزين ومعالجة كميات من البيانات لم تكن تتخيلها سابقًا، ولكن ذلك يأتي بتكلفة. لا تحتوي قواعد البيانات هذه على العديد من الميزات التي تعرفها في قواعد البيانات الارتباطية، وقد يكون من الصعب إعداد نفسك لاستخدامها. ولكن بمجرد أن تتقنها، يمكنك إنشاء قواعد بيانات موزعة وقابلة للتطوير يمكنها التعامل مع كميات مذهلة من طلبات القراءة والكتابة، والتي يمكن أن تكون في غاية الأهمية مع إنشاء كميات أكبر وأكبر من البيانات. الأصل: https://simpleprogrammer.com/guide-nosql-software-developers/