יסודות דוגמנות נתונים - PostgreSQL לעומת קסנדרה מול MongoDB

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

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

כיצד NoSQL נבדל מ- SQL במידול נתונים?

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

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

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

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

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

הטבלה שלהלן מפרטת כיצד דוגמנות הנתונים של NoSQL שונה מזו של SQL.

SQL לעומת NoSQL - הבדלי דוגמנות נתונים חשובים

SQL ו- NoSQL: מדוע אתה זקוק לשניהם?

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

כיצד YugaByte DB מפגיש SQL ו- NoSQL יחד עם בסיס נתונים משותף?

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

YugaByte DB - SQL ו- NoSQL בליבת מסד נתונים יחידה

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

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

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

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

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

התקן מאגרי נתונים

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

YugaByte DB, בסיס נתונים תואם PostgreSQL ו- Cassandra

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
הדוקר מושך yugabytedb / yugabyte
./yb-docker-ctl create - אפשר_postgres

MongoDB

הפעלת docker - שם my-mongo -d mongo: האחרונה

גישה באמצעות מעטפת שורת הפקודה

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

PostgreSQL

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

הדוקר מבצע - זה yb-postgres-n1 / home / yugabyte / postgres / bin / psql -p 5433 -U postgres

קסנדרה

cqlsh הוא מעטפת שורת פקודה לאינטראקציה עם קסנדרה ובסיסי הנתונים התואמים שלה באמצעות CQL (שפת שאילתה Cassandra). כדי להקל על השימוש, YugaByte DB נשלח עם גרסת cqlsh בספריית הפח שלה.

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

הדוקר מבצע - זה yb-tserver-n1 / home / yugabyte / bin / cqlsh

MongoDB

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

הדוקר מוציא את זה
תקליטור סל
מונגו

צור טבלה

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

PostgreSQL

צור מוסיקה של שולחן (
    האמן VARCHAR (20) לא אפס,
    SongTitle VARCHAR (30) לא אפס,
    AlbumTitle VARCHAR (25),
    שנה INT,
    מחיר לצוף,
    ז'אנר VARCHAR (10),
    ביקורת על צף,
    תגיות טקסט,
    מפתח ראשוני (אמן, שיר קטן)
);

קסנדרה

צור טבלה בקסנדרה דומה מאוד לזה של PostgreSQL. הבדל אחד גדול הוא היעדר מגבלות יושרה (כגון NOT NULL) שהוא באחריות האפליקציה ולא מסד הנתונים בעולם NoSQL. המפתח הראשי מורכב ממפתח החלוקה (עמודת האמן בדוגמה למטה) וקבוצת עמודות אשכול (העמודה SongTitle בדוגמה למטה). מקש המחיצה קובע באיזו מחיצה / שריד יש למקם את השורה ועמודות האשכול מציינות כיצד יש לארגן את הנתונים בתוך שרד נתון.

צור מפת מפתח myapp;
השתמש ב- myapp;
צור מוסיקה של שולחן (
    אמן טקסט,
    SongTitle TEXT,
    אלבום כותרת TEXT,
    שנה INT,
    מחיר לצוף,
    ז'אנר טקסט,
    ביקורת על צף,
    תגיות טקסט,
    מפתח ראשוני (אמן, שיר קטן)
);

MongoDB

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

השתמש ב- myNewDatabase;

קבל מידע על טבלה

PostgreSQL

מוזיקה
טבלה "public.music"
    טור | סוג | איסוף | ניתן לאפס | ברירת מחדל
-------------- + ----------------------- + ----------- + ---------- + --------
 אמן | תווים משתנים (20) | | לא null |
 שיר השיר | תווים משתנים (30) | | לא null |
 כותרת האלבום | תווים משתנים (25) | | |
 שנה | מספר שלם | | |
 מחיר | דיוק כפול | | |
 ז'אנר | תווים משתנים (10) | | |
 ביקורת | דיוק כפול | | |
 תגיות | טקסט | | |
אינדקסים:
    "music_pkey" מפתח ראשוני, btree (אמן, כותרת השיר)

קסנדרה

תאר מוסיקה של שולחן;
צור טבלה myapp.music (
    טקסט אמן,
    טקסט של כותרת השיר,
    טקסט כותרת אלבום,
    שנה ב ',
    מחיר לצוף,
    טקסט ז'אנר,
    תגיות טקסט,
    מפתח ראשוני (אומן, כותרת השיר)
) עם הזמנה לסידור מאת (כותרת השיר ASC)
    AND default_time_to_live = 0
    ועסקאות = {'enabled': 'false'};

MongoDB

השתמש ב- myNewDatabase;
אוספי תצוגה;

הכנס נתונים לטבלה

PostgreSQL

הכנס למוזיקה
    (אמן, שיר כותרת, אלבום כותרת,
    שנה, מחיר, ז'אנר, ביקורת דירוג,
    תגיות)
ערכים (
    'אף אחד שאתה לא מכיר', 'התקשר אלי היום', 'מפורסם משהו',
    2015, 2.14, 'מדינה', 7.8,
    '{"מלחינים": ["סמית", "ג'ונס", "דייוויס"], "LengthInSeconds": 214}'
);
הכנס למוזיקה
    (אמן, שיר כותרת, אלבום כותרת,
    מחיר, ז'אנר, ביקורת דעת)
ערכים (
    'אף אחד שאתה לא מכיר', 'מקום הכלב שלי', 'היי עכשיו',
    1.98, 'מדינה', 8.4
);
הכנס למוזיקה
    (אמן, שיר כותרת, אלבום כותרת,
    מחיר, ז'אנר)
ערכים (
    'להקת האקמה', 'תראה החוצה, עולם', 'באק מתחיל כאן',
    0.99, 'רוק'
);
הכנס למוזיקה
    (אמן, שיר כותרת, אלבום כותרת,
    מחיר, ז'אנר,
    תגיות)
ערכים (
    'להקת האקמה', 'עדיין מאוהבת', 'הבאק מתחיל כאן',
    2.47, 'רוק',
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotation": כבד} '
);

קסנדרה

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

זהה להצהרות PostgreSQL INSERT לעיל.

MongoDB

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

db.music.insert ({
אמן: "אף אחד שאתה לא מכיר",
   שיר כותרת: "התקשר אלי היום",
    albumTitle: "משהו מפורסם",
    שנה: 2015,
    מחיר: 2.14,
    ז'אנר: "מדינה",
    תגיות: {
מלחינים: ["סמית", "ג'ונס", "דייויס"],
אורך בשניות: 214
}
   }
);
db.music.insert ({
    אמן: "אף אחד שאתה לא מכיר",
    שיר כותרת: "ספוט הכלב שלי",
    albumTitle: "היי עכשיו",
    מחיר: 1.98,
    ז'אנר: "מדינה",
    ביקורת תגובה: 8.4
   }
);
db.music.insert ({
    אמן: "להקת האקמה",
    שיר כותרת: "תסתכל, עולם",
    albumTitle: "באק מתחיל כאן",
    מחיר: 0.99,
    ז'אנר: "רוק"
   }
);
db.music.insert ({
    אמן: "להקת האקמה",
    songTitle: "עדיין מאוהב",
    albumTitle: "באק מתחיל כאן",
    מחיר: 2.47,
    ז'אנר: "רוק",
    תגיות: {
        radioStations הפעלה: ["KHCR", "KBQX", "WTNR", "WJJH"],
        תאריכי הופעות: {
            סיאטל: "20150625",
            קליבלנד: "20150630"
        },
        סיבוב: "כבד"
}
    }
);

שאילתת טבלה

אפשר לטעון שההבדל המשמעותי ביותר בין SQL ל- NoSQL מבחינת שאילתות דוגמנות הוא בשימוש בסעיפי FROM ו- WHERE. SQL מאפשרת לסעיף FROM לכלול טבלאות מרובות וסעיף WHERE להיות מורכב שרירותי (כולל JOINs על פני טבלאות). עם זאת, NoSQL נוטה לשים מגבלה קשה על סעיף ה- FROM ולציין רק טבלה אחת ואת הסעיף WHERE כדי שתציין תמיד את המפתח הראשי. הסיבה לכך היא מיקוד הביצועים הגבוה של NoSQL עליו שוחחנו קודם לכן, שמטרתה לצמצם כל אינטראקציה בין השולחן ובין המפתח בין הצלבים. אינטראקציה כזו עשויה להכניס תקשורת חוצה צומת גבוהה עם זמן אחוי לזמן התגובה של השאילתה, ולכן היא נמנעת בצורה הטובה ביותר לחלוטין. למשל קסנדרה דורשת להגביל את השאילתות על ידי מפעילים (רק =, IN, <,>, =>, <= מותר) על מקשי החלוקה למעט בעת שאילתת אינדקס משני (כאשר רק = מפעיל מותר).

PostgreSQL

להלן 3 סוגים של שאילתות שניתן להגיש בקלות באמצעות בסיס נתונים של SQL.

  • החזירו את כל השירים של אמן
  • החזר את כל השירים של אמן, התואם את החלק הראשון של הכותרת
  • החזירו את כל השירים של אמן, עם כותרת מסוימת בכותרת, אך רק אם המחיר נמוך מ- 1.00
בחר * ממוזיקה
איפה אמן = 'אף אחד שאתה לא מכיר';
בחר * ממוזיקה
איפה אמן = 'אף אחד שאתה לא מכיר' וגם כותרת השיר אוהב 'התקשר%';
בחר * ממוזיקה
איפה אמן = 'אף אחד שאתה לא מכיר' וגם כותרת השיר אוהב '% היום%'
ומחיר> 1.00;

קסנדרה

מבין שאילתות PostgreSQL המפורטות לעיל, רק הראשונה תעבוד עם קסנדרה ללא שינוי מכיוון שמפעיל LIKE אינו מורשה בעמודות אשכולות כגון SongTitle. רק = ומפעילי IN מותרים במקרה זה.

בחר * ממוזיקה
איפה אמן = 'אף אחד שאתה לא מכיר';
בחר * ממוזיקה
איפה אמן = 'אף אחד שאתה לא מכיר' וטקסט כניסה ('התקשר אלי היום', 'נקודת הכלב שלי')
ומחיר> 1.00;

MongoDB

כפי שמוצג בדוגמאות הקודמות, השיטה העיקרית לשאילתת MongoDB היא שיטת db.collection.find (). שיטה זו מוסמכת על ידי שם האוסף (מוסיקה בדוגמה למטה) לשאילתה באופן מפורש מאוד ולכן שאילתת בין אוספים אינה מותרת במפורש.

db.music.find ({
  אמן: "אף אחד שאתה לא מכיר"
 }
);
db.music.find ({
  אמן: "אף אחד שאתה לא מכיר",
  שיר כותרת: / התקשר /
 }
);

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

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

PostgreSQL

בחר *
ממוזיקה;

קסנדרה

זהה להצהרת PostgreSQL SELECT שלמעלה.

MongoDB

db.music.find ({});

שנה נתונים בטבלה

PostgreSQL

PostgreSQL מספק את הצהרת ה- UPDATE לשינוי נתונים. זה לא מאפשר שום אפשרות להעלות ולכן ההצהרה תיכשל אם השורה כבר לא קיימת בבסיס הנתונים.

עדכון מוזיקה
SET ז'אנר = 'דיסקו'
איפה אמן = 'להקת האקמה' ו- SongTitle = 'עדיין מאוהב';

קסנדרה

לקסנדרה יש גם הצהרת UPDATE הדומה ל- PostgreSQL. UPDATE גם סמנטיקה עלית זהה לזו של הצהרת ה- INSERT.

זהה להצהרת PostgreSQL UPDATE לעיל.

MongoDB

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

db.music.update (
  {"artist": "להקת האקמה"},
  {
    סט $: {
      "ז'אנר": "דיסקו"
    }
  },
  {"multi": true, "upsert": true}
);

מחק נתונים מטבלה

PostgreSQL

מחק ממוזיקה
איפה אמן = 'להקת האקמה' ו- SongTitle = 'תסתכל, עולם';

קסנדרה

זהה להצהרת PostgreSQL DELETE שלמעלה.

MongoDB

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

db.music.deleteMany ({
        אמן: "להקת האקמה"
    }
);

הסר טבלה

PostgreSQL

DROP TABLE מוסיקה;

קסנדרה

זהה להצהרת ה- PostgreSQL DROP TABLE לעיל;

MongoDB

db.music.drop ();

סיכום

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

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

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

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

מה הלאה?

  • השווה את YugaByte DB למסדי נתונים כמו Amazon DynamoDB, Cassandra, MongoDB ו- Azure Cosmos DB.
  • התחל לעבוד עם YugaByte DB ב- macOS, Linux, Docker ו- Kubernetes.
  • צרו קשר למידע נוסף על רישוי, תמחור או תזמון סקירה טכנית.

פורסם במקור בבלוג מסד הנתונים YugaByte.