SQL مقابل NoSQL – ما الذي يجب استخدامه في مشروعك التالي؟

أحد الأسئلة الأكثر شيوعًا – ما هي قاعدة البيانات التي يجب أن أستخدمها …


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

الاختلاف الأكثر شيوعًا بين نظامي قواعد البيانات هذين هو أن SQL علائقية و NoSQL غير علائقية.

دعنا نتعمق في قاعدتي البيانات هاتين لإبلاغ قرارك بشكل أفضل عندما تفكر في قاعدة بيانات لمشروعك في المرة القادمة.

هيكل قاعدة البيانات

لنتحدث عن الهيكلة.

SQL

SQL قاعدة البيانات لديها هيكل مخطط محدد.

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

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

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

في قاعدة بياناتنا يمكن أن يكون لدينا جدول مستخدمين منظم على النحو التالي,

users_table
—————————————————-
معرف | الاسم | البريد الإلكتروني
—————————————————–
1 إدريس [البريد الإلكتروني محمي]

أيضا ، يمكن أن يكون لدينا جدول أوامر

orders_table
———————————————————————————
معرف | user_id | رقم الأمر
———————————————————————————
1 1 20000001

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

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

users_table
————————————————————————————-
معرف | الاسم | البريد الإلكتروني
————————————————————————————-
1 إدريس [البريد الإلكتروني محمي]

وجدول الطلب سيكون

orders_table
———————————————————
معرف | رقم الأمر
———————————————————
1 2000001

ومن ثم سيحتفظ جدول Pivot بكلا المعرفين كمفاتيح أجنبية.

users_orders_table
——————————————————————————
معرف | order_id | معرف المستخدم
——————————————————————————
1 1 1

استنادًا إلى هذه البنية التي توفرها SQL ، يمكنك بسهولة كتابة الصلات بين الجداول التي ستوفر بيانات من جداول مختلفة مرتبطة معًا في استعلام واحد.

NoSQL

NoSQL تم بناء قواعد البيانات لتكون أكثر مرونة من قواعد بيانات SQL ، وكذلك لاحتواء كميات أكبر من البيانات.

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

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

بالعودة إلى المثيل الافتراضي الذي تم تحديده سابقًا لشركة لديها مستخدمون وأوامر.

يمكن تعريف مجموعة المستخدمين على أنها,

{id: 1 ، الاسم: “idris” ، البريد الإلكتروني: “[البريد الإلكتروني محمي]‘}

ويمكن تعريف مجموعة الطلبات على أنها,

{id: 1، order_number: 2000001، user_id: 1}

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

{id: 1، order_number: 200001، user {id: 1، name: ‘idris’، email: ‘[البريد الإلكتروني محمي]‘}}

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

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

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

تحجيم

دعنا نستكشف كيفية عمل المقياس.

SQL

لا يمكن قياس قواعد بيانات SQL أفقياً ولكن عمودياً فقط. ماذا يعني هذا حتى?

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

التحجيم الأفقي

التحجيم العمودي


NoSQL

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

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

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

ما هو التقاسم?

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

أمثلة قاعدة البيانات

SQL

  • MySQL – قاعدة بيانات مفتوحة المصدر تحظى بشعبية كبيرة. ومع ذلك ، يمكن أيضًا استخدام قاعدة البيانات المفضلة للعديد من مطوري PHP مع Node.js و C # و C ++ و Java و Perl و Ruby و Python.
  • MSSQL – يوفر Microsoft SQL الكثير من الاستقرار حيث أن تطويره يأتي مباشرة من Microsoft ، والذي يقدم أيضًا بعض الدعم من حيث التعافي من الكوارث.
  • MariaDB – تم بناء هذا على MySQL من قبل صانعي MySQL ، بقصد الاحتفاظ بـ MariaDB كإصدار مجاني إلى الأبد.
  • PostgresSQL – قاعدة بيانات مفتوحة المصدر تحظى بشعبية كبيرة. تفتخر بأنها قاعدة البيانات المفتوحة المصدر الأكثر تقدمًا في العالم
  • Oracle – يتم تصميم هذا عادةً لحلول المؤسسات من Oracle مع بعض القيود على نسخته المجانية.

NoSQL

  • MongoDB – ربما يكون NoSQL DB الأكثر شهرة ، وهو شائع بين مطوري التطبيقات الذين يعملون مع مكدس MERN (MongoDB أو Express أو React أو Node) أو مكدس MEAN (MongoDB أو Express أو Angular أو Node).
  • Firebase – تم تقديمه في عام 2011 واكتسبته Google في عام 2014 ، ويستخدمه مطورو تطبيقات الويب والجوال على نطاق واسع.
  • أباتشي الأريكة DB – NoSQL DB المستندة إلى المستندات التي تقوم بتخزين البيانات مثل JSON.
  • Redis: هذا هو NoSQL DB ، وهو على الأرجح معروف جدًا باستخدامه في تخزين البيانات مع وقت اختياري للعيش. كما أنها معروفة بسرعتها.

استنتاج

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

العلامات:

  • قاعدة البيانات

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map