NoSQL مقابل SQL و حالات إستخدام كل واحد منهما

  • sami-abdo

السلام عليكم و رحمة الله

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

المشكلة التي واجهتني لم تكن في عمل تطبيق سطح المكتب نفسه ، أو حتى ربطه مع الخادوم (الترجمة من server في أكادمية حسوب) ولكن المشكلة الحقيقية التي واجهتني هي كيفية وضع البيانات في قاعدة البيانات .

في البداية فكرت في أن أستخدم sqlite على تطبيق سطح المكتب المشكلة أن التطبيق الذي أعمل عليه متداخل البيانات بصورة يجعله يستخدم علاقات m:n (أو كما يقال بالعربية مجموعة لـ مجموعة) أما إذا أردت جلب البيانات من هذه جداول فعلي أن أستخدم join مع عدة أليات لتصفية البيانات و إختيار الانسب منها -_- .

ثم فكرت في إستخدام neDB و هي عبارة محرك قاعدة بيانات يعمل على ملف واحد ولكن يحتوي على json (كأنك تعمل على mongodb ولكن ببساطة أكثر) في هذه الحالة تم إختصار الروابط بين الجداول بعملية التداخل ، مما جعل عملية الحفظ و التخزين أسهل ما يكون ، في المقابل عقد عملية التصفية و جمع البيانات التي يحتاجها المستخدم ، مثل :

إذا إستخدمنا عمل مدونة كمثال :

  • كل تدوينة تحتوي على (إسم ، تاريخ إنشاء ، محرر ، و تعليقات)

  • في الغالب عندما تستخدم sql فإن التعليقات تكون في جدول منفرد و تربط عبر معرف مع التدوينة

  • ولكن عندما تستخدم nosql مثل mongo يمكن أن تضيف مصفوفة من التعليقات داخل التدوينة نفسها

    • و هذه فائدتها تسهيل ربط كل البيانات الجزئية مع الكلية في عملية الجلب و الحفظ .
    • و مضارها كمثال (ربما يكون خاطئ) كيفية جلب جميع الاجزاء الجزئية مثل التعليقات من كل الاجزاء الكلية مثل التدوينات

مختصراً :

  • ما هي الحالات التي من الممكن أن تفيد فيها فعلاً قواعد البيانات مثل mongo ؟

  • و في المقابل هل أصبح إستخدام قواعد بيانات من نوع sql و عمل normalization مفيد ؟ و ما هي أفضل حالات إستخدام هذا النوع من قواعد البيانات ؟


  • طبعاً كثير من المطورين يستخدمون SQL فما هي حالات الاستخدام التي وجدت فيها أن بناء نظام بقاعدة بيانات SQL مقيد أكثر ؟

  • و إن إستخدمت قواعد بيانات من نوع NoSQL ، شاركنا تجربتك ، و ما هي الفوائد التي وجدتها فيها ؟


على الجانب أثناء بحثي وجدت أن PostgreSQL تجمع بين الامرين ، حيث أنها تعتبر كـ SQL ولكن تحتوي على أدوات للتعامل مع JSON لدرجة أن هناك دورة تستخدمها كـ Document Database ، فما رأيكم ؟

يرجى الدخول لحسابك أو تسجيل حساب لتستطيع إضافة تعليق
حساب جديد دخول

التعليقات

عبد الرحمن أحمد أضف ردا

بالنسبة لي مؤخرا عملت جاهدا لفصل عملية التطوير عن الداتابيز حتى لا أصطدم بترقية قواعد البيانات عند الزبون بعد إدخاله بيانات

ولكوني أستخدم Sql Server كمحرك قاعدة متكاملة مع البيئة التي أعمل عليها وهي الدوت نت

وبعد عملية بحث وتجارب ومقارنات خلصت إلى عمل قاعدة بيانات بجدول واحد و حقول ثابتة إحداها XML مستفيداً من دعم سيكوال سيرفر للتعامل مع xml و السماح بعمليات الاستفسارات والبحث وال join

وبهذا أكون حاكيت بعض ميزات NoSQL ألا وهي حفظ الأوبجكت كاملا في خانة وأصبح الجدول الوحيد مخزن لكل أنواع الأوبجكت التي أستخدمها في التطبيق

لأن الداتابيز لم يعد يهمها معرفة خصائص الكائن الذي سيتم حفظه أو استرجاعه

وعملية التحويل والتحويل المعاكس من الكائن إلى قيمة xml أتحكم بها من داخل الكود

بهذا كسبت الكثير من الميزات وهي أن القاعدة شكلها ثابت طوال مدة التطوير ولمختلف أنواع التطبيقات

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

للعلم الكفاءة مقبولة لعدة عشرات آلاف من الأسطر

أما في حال كان التطبيق يتطلب معالجة لكمية كبيرة جدا تزيد عن مائة ألف فيفضل فصل الجدول في جدول منفصل وتتعامل معه بحقول منفصلة لتجاوز زمن معالجة xml

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

شكرأ على مشاركة تجربتك .

ولكوني أستخدم Sql Server كمحرك قاعدة متكاملة مع البيئة التي أعمل عليها وهي الدوت نت

وبعد عملية بحث وتجارب ومقارنات خلصت إلى عمل قاعدة بيانات بجدول واحد و حقول ثابتة إحداها XML مستفيداً من دعم سيكوال سيرفر للتعامل مع xml و السماح بعمليات الاستفسارات والبحث وال join

يعني حولت قاعدة بيانات SQL و تعاملت معها كأنها NoSQL ^_^ رائع

و السماح بعمليات الاستفسارات والبحث وال join

هل يمكنك توضيح هذه الجزئية أكثر ، مع إضافة مثال بسيط ^_^


بالمناسبة قبل فتره قرأت في أحد تعليقاتك أنك بدأت بالتحول إلي PostreSQL ، فما كيف تجربتك معها ؟ ، سؤالي هذا لأن إستخدام الـ JSON API مع PostgreSQL ، يمكن أن يكون تجربة مشابه لما فعلته بـ SQL Server مع XML


للعلم الكفاءة مقبولة لعدة عشرات آلاف من الأسطر

بالنسبة لعملية التحويل ، مثلا ؟


أود التنويه أني ما زلت أستخدم العلاقات وهي علاقة واحد لمتعدد

ماذا عن علاقة متعدد : لمتعدد ؟ هل تستخدمها داخل xml أم تنشئ مجموعة جداول ؟

عبد الرحمن أحمد أضف ردا
  • بالنسبة للبوستجري PostreSQL استخدمته لمرة واحدة في مشروع طلبه مني شخص من مبغضي منتجات مايكروسوفت فطلب مني أن أستغني قدر المستطاع عن منتجاتهم وأستخدم ما يلزم بقدر الاضطرار فقط

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

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

  • الكفاءة ليس بالنسبة للتحويل فقط وإنما للاستفسارات عبر وظائف xml المضمنة في السيرفر بمعنى أن الاستفسار سواء لجداول وحقول مجردة قريب من الاستفسار ضمن عقد ال xml

لكن من أجل أعداد كبيرة الفارق البسيط يتراكم ليصبح فارقا كبيرا

  • بالنسبة لعلاقة متعدد لمتعدد لم أحتاجها إلى الآن لكن لكوني أستطيع حفظ ما أشاء داخل xml فبالإمكان حفظ مصفوفة مفاتيح بدل مفتاح واحد لأسطر أخرى.

لم أقف عند الأكر كثيرا وتركته لحينه حتى لا يقف عقبة.

  • بالنسبة للاستفسار على بيانات xml هذا مثال
NibrasIO أضف ردا

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

هل جربت إستخدام جدول مخصص لعمل العلاقات وربط الجداول ببعضها ؟ كأن يكون الجدول وسيط بين باقي الجداول ؟

هل جربت إستخدام جدول مخصص لعمل العلاقات وربط الجداول ببعضها ؟ كأن يكون الجدول وسيط بين باقي الجداول ؟

نعم و يسمى عند مطوري LARAVEL ، بالنسبة لإستخدام JSON كيف سوف أستفسر عن البيانات التي داخلها إن كنت أستخدم SQL إلا إذا كنت أستخدم postgres أو أخر نسخة من mysql ^_^

NibrasIO أضف ردا

نعم و يسمى عند مطوري LARAVEL

لم أفهم الجملة ^^"

بالنسبة لإستخدام JSON كيف سوف أستفسر عن البيانات التي داخلها

حسب التجربة التي لدي، نفترض أن هناك جدول (أ) وهو متصل مع جدول (ب) وجدول (ج)، في حين أن جدول (ب) متصل مع جدول (د)، وهو بتأكيد قيمة مرتبطة بالجدول (أ) .

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

أي أنك تحتاج في الأول للاتصال وجلب القيمة من السجل في جدول (أ) لتستطيع بإستخدامها الوصول لقيمة في جدول (د) .

أتمنى أن تكون وضحت الفكرة .

حسب علمي، أتوقع أن قواعد البيانات NoSQL التي تعتمد على JSON، يمكنك إنشاء الأمور بشكل مضمن، شيء قريب إلى هذا :

{
    "PostID":1,
    "Title":"test",
    "Content":"text",
    "Comments":[
        {"CommentID":1},
        {"CommentID":2}
    ]
}

لم أفهم الجملة ^^"

إعذرني فقد بدأت بكتابة الجملة و لم أتمها -_- ، مطوري laravel يسمون الجدول الوسيط بـ pivot table .

فسيكون بالسجل المطلوب القيمة الخاصة بـ JSON والتي بها (اسم الجدول، معرفه وقيمته)، فأقوم بإستخدامها لجلب قيمة (د) مباشرة عبر القيمة المخزنة .

فكرة جميلة أتذكر أن هناك نوع من العلاقات تسمى بـ polymorphic و تقوم على مبدأ تسجيل إسم الجدول و رقم الصف لكي يجلب عند الحاجة ^_^

وعليكم السلام ورحمة الله

عند قراءة كلمة nosql سيتوهم القارء انها لا تستخدم اي لغة لجلب البيانات والعكس هو الصحيح

فقواعد بيانات نو سكويل لها لغة وممكن تعمل بها (جداول اذا صح التعبير او ملفات) وتربطهم باستخدام المفاتيح

ايضا تستطيع جلب معلومة محددة من اي ملف ( التعليق الاخير على التدوينة الاحدث مثلا)

كما لديك ميزة عدم الالتزام بشكل محدد لقاعدة البيانات

sami-abdo أضف ردا

عند قراءة كلمة nosql سيتوهم القارء انها لا تستخدم اي لغة لجلب البيانات والعكس هو الصحيح

بعض الناس يوضحها بـ

Not Only SQL

و تعني ليست مجرد SQL

ببساطة محركات قواعد البيانات التي تستخدم الـ SQL لها طريقة معينة لجلب البيانات و تخزينها و هلم جره ، ولكن محركات قواعد البيانات التي لا تعتمد على SQL تتقسم إلي أنواع مختلفة مثل :

  • التي تستخدم طريقة المفتاح و القيمة

  • التي تستخدم طريقة* الوثائق (المتداخلة)*

  • التي تعتمد على الاعمدة

  • و يوجد نوع جديد يسمى بـ قواعد البيانات الرسومي

ببساطة هذه الانواع كل منها يؤدي غرض معين و تختلف في طريقة تخزين و جلب البيانات لذلك سميت بـ 

Not Only SQL

ما شاء الله عليك عارف كثير من التفاصيل الدقيقة

اذكر اني قرات مقال لشخص حاول ان يعرف فرق الاداء بين مايسكويل و مانجودي بي.

في جميع الاستعلامات (القاعدة كانت كبيرة جدا) كان يجد نفس سرعة الاستجابة !

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

في مثال المدونة للحصول على صفحة المقالة

ماي يسكويل سيقوم بعملية بحث في جدول المقالات ثم جدول الكتاب ثم جدول التعليقات (على اقل تقدير)

في حالة نو سيكويل يمكن ان تكون عمليه عرض المقالة في استعلام واحد فقط ( في حال صممت القاعدة بملف واحد) وهنا تكمن السرعة