أساسيات نمذجة البيانات - PostgreSQL vs. Cassandra vs. MongoDB

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

يهدف هذا المنشور إلى مساعدة مطوري التطبيقات على فهم اختيار SQL مقابل NoSQL في سياق احتياجات نمذجة البيانات للتطبيق. نحن نستخدم قاعدة بيانات SQL واحدة ، وهي PostgreSQL ، وقواعد بيانات NoSQL ، وهما Cassandra و MongoDB ، كأمثلة لشرح أساسيات نمذجة البيانات ، مثل إنشاء الجداول وإدراج البيانات وإجراء عمليات المسح وحذف البيانات. في منشور لاحق ، سوف نغطي موضوعات متقدمة مثل الفهارس والمعاملات والانضمامات وتوجيهات وقت العيش (TTL) ونمذجة بيانات المستندات المستندة إلى JSON.

كيف يختلف الناشرون من SQL في نمذجة البيانات؟

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

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

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

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

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

يوضح الجدول التالي كيف تختلف نماذج بيانات NoSQL عن نماذج SQL.

SQL مقابل NoSQL - اختلافات نمذجة البيانات الرئيسية

مزود و NoSQL: لماذا تحتاج كلاهما؟

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

كيف تجمع YugaByte DB SQL و NoSQL معًا في قاعدة بيانات مشتركة؟

تم بناء YugaByte DB على قاعدة فريدة من نوعها من محرك تخزين الدمج المهيكل ، والمشاركة التلقائية ، وتكرار الإجماع لكل حصة ، ومعاملات ACID الموزعة (مستوحاة من Google Spanner) ، وتعد YugaByte DB أول قاعدة بيانات مفتوحة المصدر في العالم ، وهي NoSQL (Cassandra & Redis) متوافق) و SQL (متوافق مع PostgreSQL) في نفس الوقت. كما هو موضح في الجدول أدناه ، يضيف YCQL ، واجهة برمجة التطبيقات المتوافقة مع Cassandra من YugaByte DB فكرة معاملات ACID أحادية المفتاح ومتعددة المفاتيح والفهارس الثانوية العالمية إلى NoSQL APIs وبالتالي تستهل حقبة Transactional NoSQL. بالإضافة إلى ذلك ، يضيف YSQL ، واجهة برمجة تطبيقات PostgreSQL المتوافقة مع YugaByte DB لمفاهيم تحجيم الكتابة الخطية والتسامح التلقائي مع الخطأ في واجهة برمجة تطبيقات SQL ، وبذلك تجلب عالم SQL الموزع. نظرًا لأن YugaByte DB معاملات في الأساس ، يمكن استخدام واجهات برمجة التطبيقات (API) لـ NoSQL الآن في سياق البيانات المهمة.

YugaByte DB - SQL و NoSQL على قاعدة بيانات واحدة أساسية

كما هو موضح سابقًا في تقديم YSQL: واجهة برمجة تطبيقات SQL الموزعة المتوافقة مع PostgreSQL لـ YugaByte DB ، يعتمد اختيار SQL مقابل NoSQL في YugaByte DB تمامًا على خصائص عبء العمل الأكبر.

  • إذا كان عبء العمل الأكبر هو عمليات متعددة المفاتيح باستخدام JOINS ، فاختر YSQL على أن يكون مفهوما أنه قد يتم توزيع المفاتيح الخاصة بك عبر عقد متعددة مما يؤدي إلى زمن انتقال أعلى و / أو إنتاجية أقل من NoSQL.
  • بخلاف ذلك ، اختر أحد واجهات برمجة تطبيقات NoSQL مع فهم أنك ستحصل على مزايا أداء أعلى ناتجة عن الاستعلامات التي يتم تقديمها أساسًا من عقدة واحدة في كل مرة. يمكن أن تعمل YugaByte DB كقاعدة بيانات تشغيلية موحدة لتطبيقات العالم الواقعي المعقدة التي عادةً ما تكون لها أعباء عمل متعددة لإدارة في نفس الوقت.

يعتمد مختبر نمذجة البيانات في القسم التالي على واجهات برمجة التطبيقات المتوافقة مع PostgreSQL و Cassandra في YugaByte DB بدلاً من قواعد البيانات الأصلية. هذا النهج يسلط الضوء على بساطة التفاعل مع اثنين من واجهات برمجة التطبيقات المختلفة (على اثنين من المنافذ المختلفة) من نفس كتلة قاعدة البيانات بدلا من استخدام مجموعات مستقلة تماما من قواعد البيانات المختلفة.

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

مختبر نمذجة البيانات

تثبيت قواعد البيانات

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

YugaByte DB ، قاعدة بيانات متوافقة بوستجرس وكاساندرا

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
عامل ميناء سحب yugabytedb / yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

تشغيل عامل ميناء - اسم my-mongo -d mongo: الأحدث

الوصول باستخدام Command Line Shell

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

كيو

psql عبارة عن shell سطر أوامر للتفاعل مع PostgreSQL. لسهولة الاستخدام ، يأتي YugaByte DB مع إصدار من psql في دليل bin الخاص به.

عامل ميناء exec -it yb-postgres-n1 / home / yugabyte / postgres / bin / psql -p 5433 -U postgres

كاساندرا

cqlsh عبارة عن shell لسطر الأوامر للتفاعل مع Cassandra وقواعد البيانات المتوافقة من خلال CQL (لغة استعلام Cassandra). لسهولة الاستخدام ، يأتي YugaByte DB مع إصدار من cqlsh في دليل bin الخاص به.

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

عامل ميناء exec -it yb-tserver-n1 / home / yugabyte / bin / cqlsh

MongoDB

mongo عبارة عن shell لسطر الأوامر للتفاعل مع MongoDB. يمكن العثور عليه في دليل bin لتثبيت MongoDB.

عامل ميناء exec - في بلدي مونغو باش
بن مؤتمر نزع السلاح
مونغو

إنشاء جدول

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

كيو

إنشاء جدول الموسيقى (
    الفنان فاركار (20) ليس باطل ،
    SongTitle VARCHAR (30) غير فارغ ،
    AlbumTitle VARCHAR (25) ،
    سنة الباحث ،
    سعر تعويم ،
    النوع فاركار (10) ،
    الناقدة تعويم ،
    العلامات النص ،
    PRIMARY KEY (فنان ، عنوان أغنية)
)؛

كاساندرا

إنشاء جدول في Cassandra يشبه جدًا جدول PostgreSQL. أحد الاختلافات الكبيرة هو عدم وجود قيود تكامل (مثل NOT NULL) والتي هي مسؤولية التطبيق وليس قاعدة البيانات في عالم NoSQL. يتكون المفتاح الأساسي من مفتاح القسم (عمود Artist في المثال أدناه) ومجموعة من أعمدة التجميع (عمود SongTitle في المثال أدناه). يحدد مفتاح القسم القسم / الشظية الذي يجب وضع الصف فيه وتحدد أعمدة التجميع كيفية تنظيم البيانات داخل شظية معينة.

إنشاء KEYSPACE myapp؛
استخدام myapp.
إنشاء جدول الموسيقى (
    نص الفنان ،
    SongTitle TEXT ،
    AlbumTitle TEXT ،
    سنة الباحث ،
    سعر تعويم ،
    نوع النص ،
    الناقدة تعويم ،
    العلامات النص ،
    PRIMARY KEY (فنان ، عنوان أغنية)
)؛

MongoDB

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

استخدام myNewDatabase ؛

الحصول على معلومات حول الجدول

كيو

\ د الموسيقى
الجدول "public.music"
    العمود | اكتب | الترتيب | لاغى | افتراضي
-------------- + ----------------------- + ----------- + ---------- + --------
 فنان | حرف متباين (20) | | ليس فارغا |
 عنوان الأغنية | حرف متباين (30) | | ليس فارغا |
 عنوان الالبوم | حرف متباين (25) | | |
 السنة | عدد صحيح | | |
 السعر | الدقة المزدوجة | | |
 النوع | حرف متباين (10) | | |
 انتقاد | الدقة المزدوجة | | |
 العلامات | نص | | |
مؤشرات:
    "music_pkey" PRIMARY KEY ، بتري (فنان ، عنوان أغنية)

كاساندرا

وصف الموسيقى الجدول.
إنشاء الجدول myapp.music (
    نص الفنان ،
    نص عنوان الأغنية ،
    نص عنوان الألبوم ،
    السنة كثافة العمليات ،
    سعر تعويم ،
    نص النوع ،
    نص العلامات ،
    PRIMARY KEY (فنان ، عنوان الأغنية)
) مع ترتيب المجموعات حسب (songtitle ASC)
    AND default_time_to_live = 0
    معاملات AND = {'ممكّنة': 'false'}؛

MongoDB

استخدام myNewDatabase ؛
عرض المجموعات.

إدراج البيانات في جدول

كيو

إدراج في الموسيقى
    (فنان ، SongTitle ، AlbumTitle ،
    السنة ، السعر ، النوع ، نقد ،
    الكلمات)
القيم(
    "لا أحد تعرفه" ، "اتصل بي اليوم" ، "مشهور إلى حد ما" ،
    2015 ، 2.14 ، "البلد" ، 7.8 ،
    '{"الملحنين": ["Smith" ، "Jones" ، "Davis"] ، "LengthInSeconds": 214}'
)؛
إدراج في الموسيقى
    (فنان ، SongTitle ، AlbumTitle ،
    السعر ، النوع ، نقد)
القيم(
    "لا أحد تعرفه" ، "كلبي بقعة" ، "مرحبًا الآن" ،
    1.98 ، "البلد" ، 8.4
)؛
إدراج في الموسيقى
    (فنان ، SongTitle ، AlbumTitle ،
    السعر ، النوع)
القيم(
    "فرقة Acme" ، "Look Out ، World" ، "The Buck يبدأ هنا" ،
    0.99 ، "روك"
)؛
إدراج في الموسيقى
    (فنان ، SongTitle ، AlbumTitle ،
    السعر ، النوع ،
    الكلمات)
القيم(
    "فرقة Acme" ، "Still in Love" ، "The Buck يبدأ هنا" ،
    2.47 ، "روك" ،
    '{"radioStationsPlaying": ["KHCR"، "KBQX"، "WTNR"، "WJJH"]، "tourDates": {"Seattle": "20150625"، "Cleveland": "20150630"}، "rotation": الثقيلة}
)؛

كاساندرا

تشبه عبارات Cassandra INSERT إلى حد كبير عبارات PostgreSQL بشكل عام. ومع ذلك ، هناك فرق كبير واحد في دلالات. INSERT هي في الواقع عملية مقلقة في كاساندرا حيث يتم تحديث الصف بأحدث القيم في حالة وجود الصف بالفعل.

نفس عبارات PostgreSQL INSERT أعلاه.

MongoDB

على الرغم من أن MongoDB هو أيضًا قاعدة بيانات NoSQL مماثلة لكاساندرا ، فإن عملية الإدراج لا تحتوي على نفس السلوك الدلالي مثل كاساندرا. لا يوجد في MongoDB insert () أي احتمال كبير مما يجعله يشبه PostgreSQL سلوك الإدراج الافتراضي بدون تحديد _ids سيؤدي إلى مستند جديد يضاف إلى المجموعة.

db.music.insert ({
الفنان: "لا أحد تعرفه" ،
   songTitle: "Call Me Today" ،
    albumTitle: "مشهور إلى حد ما" ،
    السنة: 2015 ،
    السعر: 2.14 ،
    النوع: "البلد" ،
    العلامات: {
الملحنين: ["سميث" ، "جونز" ، "ديفيس"] ،
الطولالثانية: 214
}
   }
)؛
db.music.insert ({
    الفنان: "لا أحد تعرفه" ،
    songTitle: "My Dog Spot" ،
    albumTitle: "Hey Now" ،
    السعر: 1.98 ،
    النوع: "البلد" ،
    الناقد: 8.4
   }
)؛
db.music.insert ({
    الفنان: "فرقة Acme" ،
    songTitle: "انظروا ، العالم" ،
    albumTitle: "The Buck يبدأ هنا" ،
    السعر: 0.99
    النوع: "روك"
   }
)؛
db.music.insert ({
    الفنان: "فرقة Acme" ،
    songTitle: "Still In Love" ،
    albumTitle: "The Buck يبدأ هنا" ،
    السعر: 2.47 ،
    النوع: "روك" ،
    العلامات: {
        radioStationsPlaying: ["KHCR" ، "KBQX" ، "WTNR" ، "WJJH"] ،
        مواعيد الجولة: {
            سياتل: "20150625" ،
            كليفلاند: "20150630"
        }،
        الدوران: "ثقيل"
}
    }
)؛

الاستعلام عن جدول

يمكن القول إن الاختلاف الأكثر أهمية بين SQL و NoSQL من حيث استعلامات النمذجة هو استخدام جمل FROM و WHERE. يسمح SQL جملة FROM لتضمين جداول متعددة و جملة WHERE أن يكون التعقيد التعسفي (بما في ذلك JOINs عبر الجداول). ومع ذلك ، يميل NoSQL إلى وضع قيود صارمة على جملة FROM لتحديد جدول واحد فقط وتحديد جملة WHERE دائمًا بتحديد المفتاح الأساسي. ويرجع ذلك إلى تركيز NoSQL على الأداء العالي الذي ناقشناه سابقًا والذي يهدف إلى تقليل أي تفاعل عبر الجداول وعبر المفاتيح. قد يؤدي هذا التفاعل إلى تقديم اتصال عبر عقدة زمن انتقال عالٍ في وقت استجابة الاستعلام ومن الأفضل تجنبه تمامًا. مثلا تتطلب Cassandra تقييد الاستعلامات من قِبل العوامل (فقط = ، IN ، <،> ، => ، <= مسموح بها) على مفاتيح القسم باستثناء عند الاستعلام عن فهرس ثانوي (حيث يُسمح فقط = عامل التشغيل).

كيو

فيما يلي 3 أنواع من الاستعلامات التي يمكن تقديمها بسهولة بواسطة قاعدة بيانات SQL.

  • إرجاع جميع الأغاني من قبل فنان
  • إرجاع جميع الأغاني من قبل فنان ، مطابقة الجزء الأول من العنوان
  • قم بإرجاع جميع الأغاني لفنان ، مع كلمة معينة في العنوان ولكن فقط إذا كان السعر أقل من 1.00
اختر * من الموسيقى
أين الفنان = "لا أحد تعرفه" ؛
اختر * من الموسيقى
WHERE Artist = 'No One You Know' و SongTitle LIKE 'Call٪'؛
اختر * من الموسيقى
أين الفنان = "لا أحد تعرفه" و SongTitle LIKE '٪ Today٪'
و السعر> 1.00؛

كاساندرا

من بين طلبات PostgreSQL المدرجة أعلاه ، لن يعمل سوى أول واحد مع Cassandra غير المعدلة لأن مشغل LIKE غير مسموح به على أعمدة التجميع مثل SongTitle. يُسمح فقط لمشغلي = و IN في هذه الحالة.

اختر * من الموسيقى
أين الفنان = "لا أحد تعرفه" ؛
اختر * من الموسيقى
أين الفنان = "لا أحد تعرفه" و SongTitle IN ("اتصل بي اليوم" ، "My Dog Spot")
و السعر> 1.00؛

MongoDB

كما هو موضح في الأمثلة السابقة ، الطريقة الأساسية للاستعلام عن MongoDB هي الطريقة db.collection.find (). هذه الطريقة مؤهلة من خلال اسم المجموعة (الموسيقى في المثال أدناه) ليتم الاستعلام عنها بشكل صريح جدًا ، لذا يُسمح بالاستعلام عبر المجموعات بشكل صريح.

db.music.find ({
  فنان: "لا أحد تعرفه"
 }
)؛
db.music.find ({
  الفنان: "لا أحد تعرفه" ،
  عنوان الأغنية: / Call /
 }
)؛

قراءة جميع الصفوف من الجدول

تعد قراءة جميع الصفوف مجرد حالة خاصة لنمط الاستعلام العام الذي لاحظناه سابقًا.

كيو

تحديد *
من الموسيقى

كاساندرا

نفس العبارة PostgreSQL SELECT أعلاه.

MongoDB

db.music.find ({}) ؛

تعديل البيانات في جدول

كيو

يوفر PostgreSQL عبارة UPDATE لتعديل البيانات. لا يسمح بأي احتمال مغاير ، لذلك ستفشل العبارة إذا كان الصف غير موجود في قاعدة البيانات بالفعل.

تحديث الموسيقى
SET النوع = 'ديسكو'
أين الفنان = "فرقة Acme" و SongTitle = "ما زلت في الحب" ؛

كاساندرا

يحتوي Cassandra أيضًا على عبارة UPDATE مماثلة لـ PostgreSQL. UPDATE أيضا دلالات مغازلة نفس تلك العبارة INSERT.

مثل بيان تحديث PostgreSQL أعلاه.

MongoDB

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

db.music.update (
  {"فنان": "The Acme Band"} ،
  {
    مجموعة $: {
      "النوع": "ديسكو"
    }
  }،
  {"multi": true ، "upert": true}
)؛

حذف البيانات من جدول

كيو

حذف من الموسيقى
أين الفنان = "فرقة Acme" و SongTitle = "ابحث عن العالم" ؛

كاساندرا

تمامًا مثل عبارة حذف حذف PostgreSQL أعلاه.

MongoDB

لدى MongoDB نوعان من العمليات للتعامل مع عمليات حذف المستندات - deleteOne () / deleteMany () و remove (). كلاهما يحذف المستند (المستندات) لكن له نتائج إرجاع مختلفة

db.music.deleteMany ({
        فنان: "فرقة Acme"
    }
)؛

إزالة الجدول

كيو

إسقاط الموسيقى الجدول.

كاساندرا

نفس العبارة PostgreSQL DROP TABLE أعلاه ؛

MongoDB

db.music.drop ()؛

ملخص

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

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

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

ساعدنا هذا المنشور في فهم كيفية اختلاف أساسيات نمذجة البيانات بين PostgreSQL و Cassandra و MongoDB. في المنشورات التالية في هذه السلسلة ، سننتقل إلى مفاهيم نمذجة البيانات المتقدمة مثل الفهارس والمعاملات و JOINs وتوجيهات TTL ومستندات JSON.

ماذا بعد؟

  • قارن YugaByte DB بقواعد البيانات مثل Amazon DynamoDB و Cassandra و MongoDB و Azure Cosmos DB.
  • ابدأ مع YugaByte DB على أنظمة macOS و Linux و Docker و Kubernetes.
  • اتصل بنا لمعرفة المزيد حول الترخيص أو التسعير أو لجدولة النظرة العامة الفنية.

نشر في الأصل في مدونة قاعدة بيانات YugaByte.