أساسيات تصميم قاعدة البيانات - مقارنة بوستجرس ، كاساندرا ، و مونغودب

مرحبا اصدقاء قبل المغادرة إلى الجزء الثاني من عطلات مايو ، نطلعكم على المواد التي قمنا بترجمتها عشية إطلاق دفق جديد بمعدل "Relational DBMS" .



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

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

ما هو الفرق بين SQL و NoSQL؟

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

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

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

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

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

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



مزود و 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 (بوستجرس). كما هو موضح في الجدول أدناه ، فإن YSQL ، واجهة برمجة تطبيقات YugaByte DB API المتوافقة مع Cassand ، تضيف مفاهيم معاملات ACID الفردية والمتعددة المفاتيح والفهارس الثانوية العالمية إلى NoSQL APIs ، مما يفتح عصر قواعد بيانات NoSQL للمعاملات. بالإضافة إلى ذلك ، YSQL ، واجهة برمجة تطبيقات YugaByte DB API المتوافقة مع PostgreSQL ، تضيف فكرة تحجيم السجلات الخطية والتسامح التلقائي للأخطاء إلى واجهة برمجة تطبيقات SQL ، حيث تقدم قواعد بيانات SQL الموزعة إلى العالم. نظرًا لأن قاعدة بيانات YugaByte DB هي معاملات بشكل أساسي ، يمكن الآن استخدام واجهة برمجة تطبيقات NoSQL في سياق البيانات المهمة.



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

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

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

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

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

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

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

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

mkdir ~/yugabyte && cd ~/yugabyte wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl docker pull yugabytedb/yugabyte ./yb-docker-ctl create --enable_postgres 

MongoDB

 docker run --name my-mongo -d mongo:latest 

وصول سطر الأوامر

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

كيو

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

 docker 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 ، فإنه يضيف مجموعة معينة من القيود ، والتي سنتناولها أيضًا في مقالات أخرى.

 docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh 

MongoDB

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

 docker exec -it my-mongo bash cd bin mongo 

إنشاء الجدول

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

كيو

 CREATE TABLE Music ( Artist VARCHAR(20) NOT NULL, SongTitle VARCHAR(30) NOT NULL, AlbumTitle VARCHAR(25), Year INT, Price FLOAT, Genre VARCHAR(10), CriticRating FLOAT, Tags TEXT, PRIMARY KEY(Artist, SongTitle) ); 

كاساندرا

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

 CREATE KEYSPACE myapp; USE myapp; CREATE TABLE Music ( Artist TEXT, SongTitle TEXT, AlbumTitle TEXT, Year INT, Price FLOAT, Genre TEXT, CriticRating FLOAT, Tags TEXT, PRIMARY KEY(Artist, SongTitle) ); 

MongoDB

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

 use myNewDatabase; 

استرجاع معلومات جدول PostgreSQL

 \d Music Table "public.music" Column | Type | Collation | Nullable | Default --------------+-----------------------+-----------+----------+-------- artist | character varying(20) | | not null | songtitle | character varying(30) | | not null | albumtitle | character varying(25) | | | year | integer | | | price | double precision | | | genre | character varying(10) | | | criticrating | double precision | | | tags | text | | | Indexes: "music_pkey" PRIMARY KEY, btree (artist, songtitle) 

كاساندرا

 DESCRIBE TABLE MUSIC; CREATE TABLE myapp.music ( artist text, songtitle text, albumtitle text, year int, price float, genre text, tags text, PRIMARY KEY (artist, songtitle) ) WITH CLUSTERING ORDER BY (songtitle ASC) AND default_time_to_live = 0 AND transactions = {'enabled': 'false'}; 

MongoDB

 use myNewDatabase; show collections; 

نشر البيانات إلى جدول PostgreSQL

 INSERT INTO Music (Artist, SongTitle, AlbumTitle, Year, Price, Genre, CriticRating, Tags) VALUES( 'No One You Know', 'Call Me Today', 'Somewhat Famous', 2015, 2.14, 'Country', 7.8, '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}' ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre, CriticRating) VALUES( 'No One You Know', 'My Dog Spot', 'Hey Now', 1.98, 'Country', 8.4 ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre) VALUES( 'The Acme Band', 'Look Out, World', 'The Buck Starts Here', 0.99, 'Rock' ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre, Tags) VALUES( 'The Acme Band', 'Still In Love', 'The Buck Starts Here', 2.47, 'Rock', '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}' ); 

كاساندرا

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

إدخال البيانات يشبه PostgreSQL INSERT أعلاه

MongoDB

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

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

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

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

كيو

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

• طباعة جميع أغاني الفنان.
• اطبع جميع أغاني الفنان التي تطابق الجزء الأول من الاسم ؛
• أدرج جميع أغاني الفنان التي لها كلمة محددة في العنوان وسعرها أقل من 1.00.

 SELECT * FROM Music WHERE Artist='No One You Know'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%' AND Price > 1.00; 

كاساندرا

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

 SELECT * FROM Music WHERE Artist='No One You Know'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot') AND Price > 1.00; 

MongoDB

كما هو موضح في الأمثلة السابقة ، تتمثل الطريقة الرئيسية لإنشاء استعلامات في MongoDB في db.collection.find () . تحتوي هذه الطريقة بشكل صريح على اسم المجموعة ( music في المثال أدناه) ، وبالتالي فإن طلب العديد من المجموعات محظور.

 db.music.find( { artist: "No One You Know" } ); db.music.find( { artist: "No One You Know", songTitle: /Call/ } ); 

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

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

كيو

 SELECT * FROM Music; 

كاساندرا

على غرار المثال في PostgreSQL أعلاه.

MongoDB

 db.music.find( {} ); 

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

كيو

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

 UPDATE Music SET Genre = 'Disco' WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love'; 

كاساندرا

يحتوي Cassandra على UPDATE مشابه لـ PostgreSQL. يحتوي UPDATE على نفس دلالات UPSERT INSERT .

على غرار المثال في PostgreSQL أعلاه.

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

 db.music.update( {"artist": "The Acme Band"}, { $set: { "genre": "Disco" } }, {"multi": true, "upsert": true} ); 

إزالة البيانات من الجدول

كيو

 DELETE FROM Music WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World'; 

كاساندرا

على غرار المثال في PostgreSQL أعلاه.

MongoDB

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

 db.music.deleteMany( { artist: "The Acme Band" } ); 

حذف الجدول

كيو

 DROP TABLE Music; 

كاساندرا

على غرار المثال في PostgreSQL أعلاه.

MongoDB

 db.music.drop(); 

استنتاج

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

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

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

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

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

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