Get best of the week

لماذا قواعد بيانات NoSQL هي حل سيئ للتطبيقات الحديثة

مرحبا يا هابر.

نلفت انتباهكم اليوم إلى ترجمة مقالة من مدونة MemSQL ، وهي في الأصل إعلان (مخصص لمزايا MemSQL ، تم تحديثه في أوائل يناير 2020). لكننا ما زلنا قررنا ترجمته في شكل مختصر ، لأنه يشرح بالتفصيل لماذا لم نقرر بعد نشر أي شيء على MongoDB أو Cassandra أو غيرها من قواعد البيانات غير العلائقية. ربما كنا على حق ، ونقتصر على الكتاب الناجح للغاية " MySQL إلى أقصى حد ".

حان الوقت للتعرف على الحقيقة المعروفة منذ فترة طويلة: قواعد بيانات NoSQL ليست مناسبة لحل العديد من المشكلات العملية التي تواجه التطبيقات الحديثة ، وقد مر الوقت لقواعد البيانات هذه.

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

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

لقد تطورت قواعد البيانات العلائقية ، مما أدى إلى ظهور جيل جديد تمامًا من الأنظمة التي يمكنها التعامل مع أي حمل تقريبًا وتلبية متطلبات قابلية التوسع والموثوقية والتوافر التي تنطبق على التطبيقات الحديثة. نحن نتحدث عن أعباء العمل المختلفة - من التقليدية ، مثل تطبيقات المعاملات وتحليلات الأعمال ، إلى تلك الأكثر ابتكارًا ، مثل مشاركة البرامج بين المشتركين المختلفين (متعدد المصادر) والتحليلات التشغيلية. أثبت صعود قواعد البيانات الجديدة ، وخاصة Google Spanner و Azure Data Warehouse و MemSQL ، أنه في معظم الحالات تكون قواعد البيانات الارتباطية أسهل في الاستخدام ، وكقاعدة عامة ، تظهر أداء أفضل من أنظمة NoSQL.

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

NoSQL الشروق


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

أنا شخصياً قدرت أولاً القيمة الكاملة للتحجيم الأفقي عندما قرأت المقالةجيمس هاميلتون على تصميم ونشر خدمات على نطاق الإنترنت. في البداية ، تمكنت من توسيع مستوى التطبيقات ، نظرًا لأن النظام عديم الحالة أسهل في التوسع. مستوى تخزين البيانات قصة أخرى. تعمل قواعد البيانات ، بحكم تعريفها ، مع الحفاظ على الدولة ، ومن الصعب حقًا إعطاء ضمانات (بمعنى حمض ACID ) حول هذه الحالة على نطاق النظام الموزع بالكامل. لذلك ، تم بناء مستويات جديدة فوق أنظمة قواعد البيانات الحالية (MySQL ، SQL Server ، إلخ) لإنشاء مستوى تخزين البيانات الموزعة.

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

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

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

ونتيجة لذلك ، قامت الخدمات السحابية واسعة النطاق (Google و Facebook و Yahoo و Microsoft وغيرها) ببناء أنظمتها الخاصة لتلبية الحاجة إلى التوسع. كانت هذه الأنظمة مختلفة ، ولكن تم وضع أفكار مشتركة فيها. في المرحلة التالية ، بدأت أنظمة المصادر المفتوحة التي تستخدم نفس الأفكار في التكاثر ، وهكذا نشأت حركة NoSQL.

لحل المشاكل على نطاق الويب ، اختلفت NoSQL عن قواعد البيانات التقليدية حول العديد من المؤشرات الرئيسية. لذا ، دعونا نلقي نظرة على سبب اتخاذ هذه القرارات المحددة هنا.

الأداء وعيوب المطابقة في نهاية المطاف


هناك طريقتان معماريتان ، ACID و BASE .

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

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

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

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

لذا ، لدينا مكان لتطبيق الاتساق على المدى الطويل ، ولكن ، بالطبع ، ليس الحل الوحيد. يجب أن يكون المهندسون المعماريون ومطورو نظم البيانات قادرين على اختيار مستوى الاتساق الذي يحتاجونه. يجب أن يعتمد هذا الاختيار على تفاصيل الاستخدام ، وليس على قدرات النظام الأساسي.

تحاول أن تعيش بدون مخطط


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

لكن هذه مغالطة.

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

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

الحقيقة هي أن هناك دائمًا دائرة. تحمل البيانات دائمًا معنى ما لشخص ما. ولكن يجب أن يقضي شخص ما وقتًا ويدمج معرفته بهذا المعنى في النظام الأساسي حتى يتمكن الآخرون من استخدام البيانات بعده. إذا كنا نتعامل مع البيانات ، وبعضها مفهوم لنا ، والجزء الآخر يتغير بسرعة ، ثم يقع الجزء الثاني في عمود يحتوي على معلومات منظمة جزئيًا ، ثم نقرر أي الأعمدة التي سنشكلها لاحقًا من هذه المعلومات المنظمة جزئيًا. تمكن SQL Server و Oracle من القيام بذلك في XML منذ 15 عامًا. في MemSQL وبعض قواعد البيانات الحديثة الأخرى اليوم ، يتم نفس الشيء باستخدام بيانات JSON. يجب أن يكون تخزين المستندات للبيانات (والعمل مع أزواج القيمة الرئيسية) ميزات لقواعد البيانات الحديثة ، ولكن ليس الاحتمال الوحيد لهذا المنتج أو ذاك.

بناء جملة الاستعلام ليس مثل SQL


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

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

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

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

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

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

وداعا NoSQL


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

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

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

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

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

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

More articles:


All Articles