SQL مقابل NoSQL تخزين علائقي
SQL مقابل NoSQL تخزين علائقي افتراضيًا
SQL مقابل NoSQL تخزين علائقي افتراضيًا
كان مفهوم قواعد بيانات NoSQL موجودًا منذ فترة ، ولكن لا يزال هناك عدد غير قليل من سوء الفهم فيما يتعلق بموضوع قواعد بيانات SQL مقابل NoSQL العلائقية.
في هذا المنشور SQL مقابل NoSQL تخزين علائقي ، أود توضيح المفاهيم الخاطئة الأكثر شيوعًا ومناقشة حالات الاستخدام الأساسية لكل منها.
هل قواعد بيانات NoSQL غير مخططة حقًا؟
ملاحظة سريعة قبل أن نبدأ: يشير مفهوم NoSQL إلى 4 أنواع مختلفة من قواعد البيانات:
في هذا المنشور ، أتحدث عن قواعد البيانات الموجهة للمستندات بشكل أساسي.
أشير إليهم على أنهم NoSQL من أجل الإيجاز ولكن ضع في اعتبارك أن المصطلح نفسه له نطاق أوسع.
حسنًا ، هل قواعد بيانات NoSQL غير مخططة حقًا؟ لنأخذ مثالا.
لنفترض أن لدينا مجموعة مستندات باسم العملاء مع وجود البيانات التالية بالداخل:
{ Id: 1, Name: "John Doe" },
{ Id: 2, Name: "Bob Smith" }
نظرًا لطبيعة مخطط المجموعة ، لا شيء يمنعنا من إضافة مستند آخر ، مثل هذا:
{ Id: 1, Name: "John Doe" },
{ Id: 2, Name: "Bob Smith" },
{ Id: 3, FirstName: "Alice", LastName: "Christopher" }
الآن ، لنفترض أن لدينا طريقة تبحث عن العملاء الذين أعطوا اسمًا معينًا:
public class CustomerRepository
{
public IReadOnlyList<Customer> Find(string name)
{
return _collection.Find(x => x.Name == name).ToList();
}
}
ماذا سيحدث إذا أضفنا أليس كريستوفر إلى المجموعة بالطريقة التي فعلناها سابقًا؟
هل ستجدها طريقة البحث؟
بالتأكيد لا. تعتمد فئة المستودع ضمنيًا على مخطط المجموعة وتتطلب من كل العملاء امتلاك خاصية الاسم ليتم اكتشافها.
في هذا السيناريو ، يتعين علينا تعديل طريقة البحث بحيث تبدأ في البحث عن خصائص الاسم والاسم الأول / اسم العائلة.
في حين أن قواعد بيانات NoSQL غير مخطط من الناحية الفنية مما يعني أنها تسمح لنا بتخزين المستندات بأي شكل نريده ، فإن فكرة المخطط نفسها لا تختفي من نموذج المجال الخاص بنا.
تقوم قواعد بيانات المخططات فقط بتحويل مسؤولية الحفاظ على المخطط إلينا نحن المطورين.
يعني استخدام تخزين NoSQL الانتقال من هياكل البيانات المحددة بوضوح إلى الهياكل الضمنية.
وهذه خطوة كبيرة إلى الوراء عما لدينا في قواعد البيانات العلائقية ، لأنه ، كما نعلم ، يجب أن نحاول دائمًا جعل الافتراضات الضمنية في التعليمات البرمجية صريحة.
وبالطبع ، لا تنتمي فكرة البيانات غير المخططة إلى قواعد بيانات NoSQL حصريًا.
يمكننا أن نفعل الشيء نفسه في قواعد البيانات العلائقية التقليدية.
على سبيل المثال ، يمكن للمرء إجراء تسلسل لكائن العميل بالكامل إلى مستند XML أو JSON ووضعه في جدول MSSQL / Oracle / MySQL.
هذا من شأنه أن يجعل مخططات تخزين العميل غير منطقية أيضًا.
كما قد تتخيل ، فإن قرارات التصميم هذه موضع استياء في عالم قواعد البيانات العلائقية بسبب قلة الوضوح.
تعد عمليات تخزين SQL للمخطط الصريح بمثابة مساعد رائع عندما يتعلق الأمر بتعريف هياكل البيانات.
يساعد المطورين على التأكد من تناسق شكل البيانات التي يعملون معها عبر قاعدة البيانات بأكملها.
هل عمليات ترحيل المخطط أسهل مع قواعد بيانات NoSQL؟
هناك عبارة أخرى مقبولة على نطاق واسع وهي أن عمليات ترحيل المخطط أسهل مع قواعد بيانات NoSQL. هل هم؟
في المثال أعلاه ، كيف سنتعامل مع إصداري بيانات العميل؟ سنحتاج إلى تقديم إصدار المخطط:
{ Id: 1, Name: "John Doe", Version: 1 },
{ Id: 2, Name: "Bob Smith", Version: 1 },
{ Id: 3, FirstName: "Alice", LastName: "Christopher", Version: 2 }
هذا يعني أنه يوجد في أي وقت نسختين على الأقل من فئة العملاء وعلينا التعامل مع كلاهما في نموذج المجال الخاص بنا يدويًا:
public class Customer
{
public int Id { get; private set; }
public string Name { get; private set; }
public string FirstName { get; private set; }
public string LastName { get; private set; }
public int Version { get; private set; }
/* Other members */
}
public class CustomerProcessor
{
public void Process(Customer customer)
{
; string lastName
if (customer.Version == 1)
{
*/; lastName = /* Get the last name out of customer.Name somehow
}
elseif (customer.Version == 2)
{
; lastName = customer.LastName
}
else
{
(); throw new InvalidOperationException
}
/* Work with lastName here */
}
}
الوضع هنا هو نفسه في الأساس.
لا تساعدنا قواعد بيانات NoSQL في عمليات ترحيل المخطط ، فهي تنقل الالتزام بأدائه إلينا نحن المطورين.
مع التخزين غير العلائقي ، يتعين علينا القيام بما يلي:
- قم بتغيير الكود الخاص بنا بحيث يتعامل مع كلا الإصدارين من المخطط
- أنشئ وظيفة في الخلفية تبحث عن مستندات من الإصدارات القديمة وتحولها إلى الإصدار الجديد ، واحدة تلو الأخرى.
الآن ، قارن هذا مع عمليات الترحيل الصريحة “إطلاق النار والنسيان” التي يمكننا استخدامها في قاعدة بيانات SQL.
كل ما يتعين علينا القيام به هناك هو كتابة نص برمجي واحد يمكنه التعامل مع جميع عمليات ترحيل البيانات مرة واحدة.
يميل منطق الترحيل في المخازن العلائقية إلى عدم التسلل إلى نموذج المجال مما يساعد على إبقاء الأخير نظيفًا وبسيطًا.
عمليات ترحيل المخططات في قواعد بيانات NoSQL ليست أسهل.
على العكس من ذلك ، فهي أكثر صعوبة في التنفيذ والمحافظة عليها مقارنة بتخزين SQL.
الفوائد الأخرى لقواعد بيانات SQL التقليدية
هناك نوعان من الفوائد الأخرى التي توفرها قواعد بيانات SQL التقليدية لنا.
لا توجد نظائر لها في معظم قواعد البيانات ذات التوجه المستند إلى المستندات.
الأول هو تكامل البيانات (المرجعية).
تساعدنا هذه الميزة في التحقق من أننا لا نشير إلى صفوف غير موجودة ، وبالتالي الحفاظ على اتساق البيانات في المقام الأول.
على سبيل المثال ، يمكننا إنشاء قيد مفتاح خارجي في جدول عملائنا ، وبالتالي التأكد من أن جميع عملائنا ينتمون إلى إحدى البلدان المحددة مسبقًا:
تعمل قاعدة البيانات العلائقية هنا باعتبارها الوصي الأخير ، إذا جاز التعبير.
هذا يعني أننا ما زلنا بحاجة إلى استخدام التحقق المناسب في رمز التطبيق بأنفسنا ولكن إذا فقدنا شيئًا ما ، فلن يؤدي ذلك إلى تلف البيانات.
ستعلمنا قاعدة البيانات بعدم الاتساق من خلال رفض المعاملة غير الصحيحة.
في مخازن NoSQL ، علينا – مرة أخرى – التعامل مع مثل هذه المواقف يدويًا.
من الممارسات الشائعة إنشاء وظيفة في الخلفية للكشف عن البيانات غير المتسقة ومحاولة تسوية النزاعات بعد حدوثها.
المعاملات الذرية عبر جداول و / أو صفوف مختلفة هي الفائدة الأخرى.
إنها ليست مهمة مثل تلك التي ناقشناها سابقًا لأن تخزين NoSQL المصمم جيدًا نادرًا ما يتطلب تغيير مستندات متعددة في وقت واحد.
لكن مع ذلك ، إنها ميزة جيدة في كثير من الحالات. تدعم قواعد بيانات NoSQL عادةً العمليات الذرية ضمن مستند واحد فقط.
فلماذا تكلف نفسك عناء اختيار تخزين بيانات NoSQL؟
على الرغم من كل المزايا التي تتمتع بها قواعد البيانات العلائقية ، إلا أنها تفتقر إلى قاعدتين مهمتين:
قابلية التوسع والأداء. وهذه هي الأسباب الوحيدة التي تجعل المرء يفكر في اختيار NoSQL.
ليس لأن قاعدة بيانات NoSQL غير مخطط لها (فهي ليست كذلك في الأساس) ، ولا لأنها تجعل عمليات ترحيل المخطط أسهل (فهي ليست كذلك).
قابلية التوسع. والأداء.
قواعد البيانات العلائقية هي رافعات لجميع المهن.
أنها توفر وظائف ثرية خارج منطقة الجزاء. كما أنها تعمل بشكل جيد مع أي نوع من البرامج.
المشكلة الوحيدة في تخزين SQL هي أنه عندما تتخطى بياناتك مثيل قاعدة بيانات واحدة ، لم يعد بإمكانك الاعتماد على النموذج العلائقي.
إذا كانت هذه هي الحالة ، فيجب عليك إعادة النظر في التطبيق الخاص بك ومحاولة استيعاب تخزين NoSQL – الذي يناسب احتياجات برنامجك أكثر من غيرها:
ولكن حتى في هذه الحالة ، لا يعني ذلك أنه يجب عليك التخلي عن قاعدة بيانات SQL تمامًا.
يمكنك استخدام تخزين NoSQL لجزء من نظامك لا يتناسب مع النموذج العلائقي وإبقاء الباقي في مكانه.
هذه الممارسة تسمى ثبات متعدد اللغات.
كل ما قيل أعلاه لا يعني أنه لا يمكنك توسيع نطاق قاعدة بيانات علائقية. يمكنك (إلى حد ما). لكن هذا يعني أنك ستحتاج إلى التخلي عن المزايا التي يوفرها ، مثل تكامل البيانات. أيضًا ، لا توفر قواعد بيانات SQL مثل هذه الوظائف خارج الصندوق ، لذلك غالبًا ما يكون من الصعب القيام بذلك. في معظم الحالات ، من الأفضل اختيار قاعدة بيانات NoSQL لأغراض قابلية التوسع.
SQL مقابل NoSQL: الخلاصة
في معظم الحالات ، تعد NoSQL خيارًا قسريًا. إنها أداة تريد تأجيل استخدامها قدر الإمكان لأنها تنقل الكثير من الأعباء عليك كمبرمج.
قواعد البيانات العلائقية أكثر ودية ، فهي توفر إمكانيات غنية خارج الصندوق:
- مخطط صريح
- سهولة الهجرة
- تكامل البيانات
- المعاملات الذرية عبر عدة جداول / صفوف
إذا كان تطبيقك لا يتوقع متطلبات قابلية التوسع المتميزة في أي مستقبل قريب ، فمن الأفضل دائمًا اختيار وحدة تخزين علائقية.
والسبب هو أن قواعد البيانات غير العلائقية تتطلب تكاليف صيانة ثابتة (وكبيرة جدًا) مقارنة بالقواعد العلائقية.
فقط إذا كنت متأكدًا من احتواء نظامك على أكثر من عشرات أو مئات الملايين من الصفوف في جدول واحد ، يجب أن تفكر في استخدام NoSQL.
وحتى في هذه الحالة ، حاول استخراج الأجزاء التي لا تتناسب مع قاعدة البيانات العلائقية إلى التخزين غير العلائقي.
من شأن ذلك أن يساعد في تقليل النفقات العامة للصيانة.
في النهاية تعرفنا في هذه المقالة بعنوان SQL مقابل NoSQL تخزين علائقي
علي بعض المفاهيم والمقارنات وأيضا المزايا والعيوب
للمزيد من المقالات المشابهة واالتعمق أكثر في معرفة لغة البرمجة SQL اقرأ في مدونتنا twiintech
ولطلب الخدمة الاحترافية تواصل معنا