יסודות עיצוב מסד הנתונים - השוואה בין PostgreSQL, Cassandra ו-MongoDB

שלום חברים. לפני היציאה לחלק השני של חופשת מאי, אנו משתפים אתכם בחומר שתרגמנו לקראת השקת זרם חדש בקורס "DBMS יחסי".

מפתחי יישומים מבלים זמן רב בהשוואה של מסדי נתונים תפעוליים מרובים כדי לבחור את זה המתאים ביותר לעומס העבודה המיועד. הצרכים עשויים לכלול מודל נתונים מפושט, ערבויות עסקאות, ביצועי קריאה/כתיבה, קנה מידה אופקי וסובלנות תקלות. באופן מסורתי, הבחירה מתחילה בקטגוריית מסד הנתונים, SQL או NoSQL, מכיוון שכל קטגוריה מציגה סט ברור של פשרות. ביצועים גבוהים במונחים של חביון נמוך ותפוקה גבוהה נתפסים בדרך כלל כדרישה שאינה ניתנת להחלפה ולכן היא חיונית עבור כל מסד נתונים לדוגמה.

מטרת מאמר זה היא לעזור למפתחי אפליקציות לעשות את הבחירה הנכונה בין SQL ל-NoSQL בהקשר של מודלים של נתוני יישומים. נסתכל על מסד נתונים אחד של SQL, כלומר PostgreSQL, ושני מסדי נתונים NoSQL, Cassandra ו-MongoDB, כדי לכסות את היסודות של עיצוב מסד הנתונים, כגון יצירת טבלאות, איכלוסן, קריאת נתונים מטבלה ומחיקתן. במאמר הבא, נקפיד להסתכל על אינדקסים, עסקאות, JOINs, הנחיות TTL ועיצוב מסד נתונים מבוסס JSON.

מה ההבדל בין SQL ל-NoSQL?

מסדי נתונים של SQL מגבירים את גמישות היישום באמצעות ערבויות עסקאות ACID, כמו גם את היכולת שלהם לבצע שאילתות בנתונים באמצעות JOIN בדרכים בלתי צפויות על גבי מודלים קיימים של מסדי נתונים יחסיים מנורמלים.

בהתחשב בארכיטקטורת המונוליטית/הצומת הבודדת שלהם והשימוש במודל שכפול מאסטר-slave עבור יתירות, מסדי נתונים מסורתיים של SQL חסרים שתי תכונות חשובות - מדרגיות כתיבה ליניארית (כלומר חלוקה אוטומטית על פני מספר צמתים) ואובדן נתונים אוטומטי/אפס. משמעות הדבר היא שכמות הנתונים המתקבלת אינה יכולה לעלות על תפוקת הכתיבה המקסימלית של צומת בודד. בנוסף, יש לקחת בחשבון אובדן נתונים זמני בסבילות לתקלות (בארכיטקטורת לא-כלום). כאן אתה צריך לזכור שההתחייבויות האחרונות עדיין לא באו לידי ביטוי בעותק העבד. קשה להשיג עדכונים שאינם בזמן השבתה גם במסדי נתונים של SQL.

מסדי נתונים של NoSQL מופצים בדרך כלל מטבעם, כלומר. בהם, הנתונים מחולקים למקטעים ומופצים על פני מספר צמתים. הם דורשים דנורמליזציה. המשמעות היא שגם את הנתונים שהוזנו יש להעתיק מספר פעמים כדי להגיב לבקשות הספציפיות שאתה שולח. המטרה הכוללת היא להשיג ביצועים גבוהים על ידי הפחתת מספר הרסיסים הזמינים במהלך הקריאה. זה מרמז ש-NoSQL דורש ממך לעצב את השאילתות שלך, בעוד ש-SQL דורש ממך לעצב את הנתונים שלך.

NoSQL מתמקדת בהשגת ביצועים גבוהים באשכול מבוזר וזהו הרציונל הבסיסי לשינויים רבים בתכנון מסדי נתונים הכוללים אובדן עסקאות ACID, JOINs ואינדקסים משניים גלובליים עקביים.

יש טענה שבעוד שמסדי נתונים של NoSQL מספקים מדרגיות כתיבה ליניארית וסובלנות תקלות גבוהה, אובדן ערבויות עסקאות הופך אותם ללא מתאימים לנתונים קריטיים למשימה.

הטבלה הבאה מראה כיצד מודל נתונים ב-NoSQL שונה מ-SQL.

SQL ו-NoSQL: מדוע יש צורך בשניהם?

אפליקציות בעולם האמיתי עם מספר גדול של משתמשים, כגון Amazon.com, Netflix, Uber ו-Airbnb, מוטלות על ביצוע משימות מורכבות ורב-פנים. לדוגמה, אפליקציית מסחר אלקטרוני כמו Amazon.com צריכה לאחסן נתונים קלים וקריטיים כמו מידע משתמש, מוצרים, הזמנות, חשבוניות, יחד עם נתונים כבדים ופחות רגישים כמו ביקורות מוצרים, הודעות תמיכה, פעילות משתמשים, ביקורות והמלצות משתמשים. באופן טבעי, יישומים אלה מסתמכים על מסד נתונים SQL אחד לפחות יחד עם מסד נתונים NoSQL אחד לפחות. במערכות חוצות אזוריות וגלובליות, מסד נתונים NoSQL פועל כמטמון מבוזר גיאוגרפי עבור נתונים המאוחסנים במסד נתונים SQL מקור מהימן הפועל באזור מסוים.

כיצד YugaByte DB משלב SQL ו-NoSQL?

נבנה על מנוע אחסון מעורב מונחה יומן, פיצול אוטומטי, שכפול קונצנזוס מבוזר ועסקאות מבוזרות ACID (בהשראת Google Spanner), YugaByte DB הוא מסד הנתונים הראשון בעולם בקוד פתוח התואם בו-זמנית עם NoSQL (Cassandra & Redis) ו SQL (PostgreSQL). כפי שמוצג בטבלה למטה, YCQL, ה-API של YugaByte DB התואם לקסנדרה, מוסיף את המושגים של עסקאות ACID בודדות ומרובות מפתח ואינדקסים משניים גלובליים ל-NoSQL API, ובכך מוביל את עידן מסדי הנתונים של NoSQL טרנזקציות. בנוסף, YCQL, ה-API של YugaByte DB התואם ל-PostgreSQL, מוסיף את המושגים של קנה מידה כתיבה ליניארי וסובלנות תקלות אוטומטית ל-SQL API, ומביא מסדי נתונים מבוזרים של SQL לעולם. מכיוון ש-YugaByte DB הוא טרנזקציוני באופיו, ניתן להשתמש כעת ב-API של NoSQL בהקשר של נתונים קריטיים למשימה.

כפי שנאמר בעבר בכתבה "מכירה את YSQL: SQL מבוזר תואם PostgreSQL API עבור YugaByte DB", הבחירה בין SQL או NoSQL ב-YugaByte DB תלויה לחלוטין במאפיינים של עומס העבודה הבסיסי:

• אם עומס העבודה העיקרי שלך הוא פעולות JOIN מרובות מפתחות, אז בעת בחירת YSQL, הבן שהמפתחות שלך עשויים להיות מופצים על פני מספר צמתים, וכתוצאה מכך זמן השהייה גבוה יותר ו/או תפוקה נמוכה יותר מאשר NoSQL.
• אחרת, בחר באחד משני ממשקי ה-API של NoSQL, תוך זכור שתקבל ביצועים טובים יותר כתוצאה משאילתות המוגשות מצומת אחד בכל פעם. YugaByte DB יכול לשמש כבסיס נתונים תפעולי יחיד עבור יישומים מורכבים בעולם האמיתי שצריכים לנהל עומסי עבודה מרובים בו זמנית.

מעבדת המודלים של הנתונים בסעיף הבא מבוססת על מסדי נתונים תואמי YugaByte DB של PostgreSQL ו- Cassandra API, בניגוד לבסיסי נתונים מקוריים. גישה זו מדגישה את קלות האינטראקציה עם שני ממשקי API שונים (בשתי יציאות שונות) של אותו אשכול מסד נתונים, בניגוד לשימוש באשכולות עצמאיים לחלוטין של שני מסדי נתונים שונים.
בסעיפים הבאים, נסקור את מעבדת מודל הנתונים כדי להמחיש את ההבדלים וחלק מהמשותף של מסדי הנתונים המכוסים.

מעבדת מודל נתונים

התקנת מסד נתונים

בהתחשב בדגש על עיצוב מודל נתונים (ולא בארכיטקטורות פריסה מורכבות), נתקין מסדי נתונים בקונטיינרים של Docker במחשב המקומי ולאחר מכן ניצור איתם אינטראקציה באמצעות מעטפת שורת הפקודה שלהם.

מסד נתונים YugaByte DB תואם PostgreSQL & Cassandra

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

גישה לשורת הפקודה

בואו נתחבר לבסיסי הנתונים באמצעות מעטפת שורת הפקודה עבור ממשקי ה-API המתאימים.

PostgreSQL

psql היא מעטפת שורת פקודה לאינטראקציה עם PostgreSQL. לנוחות השימוש, YugaByte DB מגיע עם psql ממש בתיקיית bin.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

קסנדרה

cqlsh היא מעטפת שורת פקודה לאינטראקציה עם Cassandra ומסדי הנתונים התואמים שלה באמצעות CQL (Cassandra Query Language). לנוחות השימוש, YugaByte DB מגיע עם cqlsh בקטלוג bin.
שימו לב ש-CQL נוצר בהשראת SQL ויש לה מושגים דומים של טבלאות, שורות, עמודות ואינדקסים. עם זאת, כשפת NoSQL, היא מוסיפה סט מסוים של מגבלות, שאת רובן נעסוק גם במאמרים אחרים.

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

MongoDB

מונגו היא מעטפת שורת פקודה לאינטראקציה עם MongoDB. ניתן למצוא אותו בספריית bin של התקנת MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

יצירת טבלה

כעת אנו יכולים ליצור אינטראקציה עם מסד הנתונים כדי לבצע פעולות שונות באמצעות שורת הפקודה. נתחיל ביצירת טבלה המאחסנת מידע על שירים שנכתבו על ידי אמנים שונים. השירים האלה עשויים להיות חלק מאלבום. כמו כן, תכונות אופציונליות לשיר הן שנת יציאה, מחיר, ז'אנר ודירוג. עלינו לקחת בחשבון תכונות נוספות שעשויות להידרש בעתיד דרך השדה "תגים". זה יכול לאחסן נתונים מובנים למחצה בצורה של צמדי מפתח-ערך.

PostgreSQL

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. אחד ההבדלים העיקריים הוא היעדר אילוצי תקינות (למשל NOT NULL), אבל זה באחריות האפליקציה, לא מסד הנתונים של NoSQL. המפתח הראשי מורכב ממפתח מחיצה (עמודת האמן בדוגמה למטה) ומקבוצה של עמודות אשכולות (עמודת 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 מארגן נתונים לתוך מסדי נתונים (Database) (בדומה ל-Keyspace ב-Cassandra), שם יש Collections (בדומה לטבלאות) המכילים מסמכים (בדומה לשורות בטבלה). ב-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 ב- Cassandra נראה מאוד דומה לזה שב-PostgreSQL. עם זאת, יש הבדל אחד גדול בסמנטיקה. בקסנדרה INSERT הוא למעשה ניתוח UPSERT, כאשר הערכים האחרונים מתווספים לשורה אם השורה כבר קיימת.

הזנת נתונים דומה ל-PostgreSQL INSERT מעל

.

MongoDB

למרות ש-MongoDB הוא מסד נתונים NoSQL כמו קסנדרה, אין לפעולת ההכנסה שלו שום דבר במשותף עם ההתנהגות הסמנטית של קסנדרה. ב- MongoDB לְהַכנִיס() אין הזדמנויות UPSERT, מה שהופך אותו לדומה ל-PostgreSQL. הוספת נתוני ברירת מחדל ללא _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 שדיברנו עליה קודם לכן. רצון זה מוביל לכל הפחתה אפשרית בכל אינטראקציה צולבת טבלאות ומפתחות. זה יכול להכניס עיכוב גדול בתקשורת בין הצמתים בעת מענה לבקשה ולכן עדיף להימנע באופן כללי. לדוגמה, קסנדרה דורשת ששאילתות יהיו מוגבלות למפעילים מסוימים (בלבד =, IN, <, >, =>, <=) על מפתחות מחיצה, למעט כאשר מבקשים אינדקס משני (רק האופרטור = מותר כאן).

PostgreSQL

להלן שלוש דוגמאות לשאילתות שניתן לבצע בקלות על ידי מסד נתונים של 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 המפורטות לעיל, רק הראשונה תעבוד ללא שינוי בקסנדרה, מכיוון שהאופרטור 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/
 } 
);

קריאת כל שורות הטבלה

קריאת כל השורות היא פשוט מקרה מיוחד של דפוס השאילתה שבדקנו קודם לכן.

PostgreSQL

SELECT * 
FROM Music;

קסנדרה

בדומה לדוגמא של PostgreSQL לעיל.

MongoDB

db.music.find( {} );

עריכת נתונים בטבלה

PostgreSQL

PostgreSQL מספק הוראות UPDATE כדי לשנות נתונים. אין לה הזדמנויות UPSERT, כך שהמשפט הזה ייכשל אם השורה כבר לא נמצאת במסד הנתונים.

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

קסנדרה

לקסנדרה יש UPDATE דומה ל-PostgreSQL. UPDATE בעל אותה סמנטיקה UPSERT, דומה INSERT.

בדומה לדוגמא של PostgreSQL לעיל.

MongoDB
מבצע עדכון () ב- MongoDB יכול לעדכן לחלוטין מסמך קיים או לעדכן רק שדות מסוימים. כברירת מחדל, הוא מעדכן רק מסמך אחד עם סמנטיקה מושבתת UPSERT. עדכון מספר מסמכים והתנהגות דומה UPSERT ניתן להחיל על ידי הגדרת דגלים נוספים עבור הפעולה. לדוגמה, בדוגמה למטה, הז'אנר של אמן ספציפי מתעדכן בהתאם לשיר שלו.

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

הסרת נתונים מטבלה

PostgreSQL

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"
    }
);

מחיקת טבלה

PostgreSQL

DROP TABLE Music;

קסנדרה

בדומה לדוגמא של PostgreSQL לעיל.

MongoDB

db.music.drop();

מסקנה

הוויכוח על הבחירה בין SQL ל-NoSQL משתולל כבר יותר מ-10 שנים. יש שני היבטים עיקריים לוויכוח הזה: ארכיטקטורת מנוע מסד הנתונים (SQL מונוליטי, טרנזקציונלי לעומת NoSQL מבוזר, לא טרנזקציונלי) וגישת עיצוב מסד נתונים (מודלים של הנתונים שלך ב-SQL לעומת מודלים של השאילתות שלך ב-NoSQL).

עם מסד נתונים עסקאות מבוזר כמו YugaByte DB, ניתן להפסיק בקלות את הוויכוח על ארכיטקטורת מסד הנתונים. ככל שנפחי הנתונים הופכים גדולים יותר ממה שניתן לכתוב לצומת בודד, ארכיטקטורה מבוזרת במלואה התומכת במדרגיות כתיבה ליניארית עם ריסוק/איזון מחדש אוטומטיים.

חוץ מזה, כפי שנאמר באחת הכתבות Google Cloud,ארכיטקטורות עסקיות, עקביות מאוד, משמשות כיום יותר כדי לספק זריזות פיתוח טובה יותר מאשר ארכיטקטורות לא עסקיות, בסופו של דבר עקביות.

אם נחזור לדיון בעיצוב מסד הנתונים, זה הוגן לומר ששתי גישות העיצוב (SQL ו-NoSQL) נחוצות עבור כל יישום מורכב בעולם האמיתי. גישת "מודל הנתונים" של SQL מאפשרת למפתחים לעמוד ביתר קלות בדרישות העסקיות המשתנות, בעוד שגישת "מודל השאילתות" של NoSQL מאפשרת לאותם מפתחים לפעול על כמויות גדולות של נתונים עם חביון נמוך ותפוקה גבוהה. מסיבה זו, YugaByte DB מספקת ממשקי API של SQL ו-NoSQL בליבה משותפת, במקום לקדם אחת מהגישות. בנוסף, על ידי מתן תאימות לשפות מסד נתונים פופולריות כולל PostgreSQL ו- Cassandra, YugaByte DB מבטיח שמפתחים לא יצטרכו ללמוד שפה אחרת כדי לעבוד עם מנוע מסד נתונים מבוזר ועקבי במיוחד.

במאמר זה, בדקנו כיצד יסודות עיצוב מסד הנתונים שונים בין PostgreSQL, Cassandra ו- MongoDB. במאמרים עתידיים, נצלול למושגי עיצוב מתקדמים כגון אינדקסים, טרנזקציות, JOINs, הנחיות TTL ומסמכי JSON.

אנו מאחלים לכם מנוחה נהדרת בסוף השבוע ומזמינים אתכם סמינר מקוון חינם, שיתקיים ב-14 במאי.

מקור: www.habr.com