מדריך ל-NoSQL למפתחים

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

למה אנחנו צריכים פתאום מסד נתונים חדש?

אולי תתפלא לשאול: מה רע בבסיסי נתונים יחסיים? הנקודה היא שהם עבדו ממש טוב במשך שנים רבות, אבל עכשיו יש בעיה שהם כבר לא יכולים להתמודד איתה. על פי כמה תחזיות, בשנת 2018 האנושות תייצר 50,000 גיגה-בייט של נתונים בשנייה. זוהי כמות עצומה של נתונים! האחסון והטיפול בו מהווים אתגר הנדסי רציני. מה שגרוע עוד יותר הוא שהנפח הזה גדל כל הזמן. כפי שמתברר, מסדי נתונים יחסיים אינם מתאימים לעבודה עם כמויות נתונים גדולים באמת. הם נועדו לפעול על מכונה אחת, ואם תרצו לטפל בעוד בקשות, אז האפשרות היחידה היא לקנות מחשב עם יותר זיכרון RAM ומעבד חזק יותר. לרוע המזל, מספר השאילתות שמכונה אחת יכולה לטפל בה מוגבל, ועבור עבודה מבוזרת על פני מספר מכונות אנו זקוקים לטכנולוגיית מסד נתונים שונה. כמובן, חלק מהקוראים יצחקקו בנקודה זו ויגידו שיש שתי שיטות בשימוש נרחב לשימוש במספר מכונות במקרה של מסד נתונים יחסי: שכפול וריסוק. זה נכון, אבל השיטות האלה לא מספיקות כדי להתמודד עם המשימות שלנו. שכפול קריאה היא טכניקה שבה כל עדכון מסד נתונים מופץ למכונות אחרות שיכולות לטפל רק בבקשות קריאה. במקרה זה, כל השינויים מבוצעים על ידי שרת אחד, הנקרא צומת המאסטר, בעוד ששרתים אחרים, הנקראים רפליקות קריאה, שומרים רק עותקים של הנתונים. המשתמש יכול לקרוא מכל אחת מהמכונות, אך לשנות את הנתונים רק דרך צומת המאסטר. זוהי שיטה נוחה ופופולרית מאוד, אך היא מאפשרת רק לעבד בקשות קריאה נוספות ואינה פותרת בשום אופן את בעיית עיבוד נפחי הנתונים הנדרשים. Sharding היא גישה פופולרית נוספת המשתמשת במספר מופעים של מסד נתונים יחסי. כל אחד מהם מטפל בפעולות כתיבה וקריאה עבור חלק מהנתונים. אם מסד נתונים מאחסן מידע על לקוחות, למשל, באמצעות פיצול, מכונה אחת יכולה לטפל בכל הבקשות של לקוחות ששמותיהם מתחילים ב-A, מכונה אחרת יכולה לאחסן את כל הנתונים ללקוחות ששמם מתחיל ב-B, וכן הלאה. למרות שפיצול מאפשר לך להקליט נתונים נוספים, ניהול מסד נתונים כזה הוא סיוט אמיתי: עליך ליישר את הנתונים בין מכונות ולשנות את קנה המידה של האשכול בשני הכיוונים לפי הצורך. למרות שזה נראה פשוט בתיאוריה, לעשות את זה נכון זה די מאתגר.

האם ניתן לשפר מסדי נתונים יחסיים?

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

1. החזר את הנתונים המקומיים שלך, גם אם הם לא העדכניים ביותר. במקרה זה, העדפה לזמינות (כדי להחזיר לפחות כמה נתונים, אפילו מיושנים).
2. שגיאת החזרה. במקרה זה, העדפת עקביות: הלקוח לא יקבל נתונים מיושנים, אך הוא לא יקבל נתונים כלל.

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

איך מסדי נתונים של NoSQL מאזנים עקביות וזמינות?

אולי נראה לך שאם תבחר במסד נתונים NoSQL, תמיד תקבל כמה נתונים מיושנים או שגיאה במקרה של כשל כלשהו. בפועל, זמינות ועקביות אינן בשום אופן האפשרויות היחידות הקיימות. יש מגוון רחב של אפשרויות לבחירה. לבסיסי נתונים יחסיים אין את האפשרויות האלה, אבל NoSQL מאפשר לך לשלוט בביצוע שאילתות בצורה דומה. כך או אחרת, הם מאפשרים לך להגדיר שני פרמטרים בעת ביצוע פעולות כתיבה או קריאה במסד נתונים של NoSQL: W - כמה מכונות באשכול חייבות לאשר שמירת נתונים בעת ביצוע פעולת כתיבה . ככל שמספר המכונות בהן אתה כותב את הנתונים שלך גדול יותר, כך יהיה קל יותר לקרוא את הנתונים העדכניים ביותר בפעולת הקריאה הבאה, אך גם זה ייקח יותר זמן. R - מכמה מכונות תרצה לקרוא נתונים . במערכת מבוזרת, הפצת נתונים לכל המכונות באשכול עשויה להימשך זמן מה, כך שלשרתים מסוימים יהיו הנתונים העדכניים ביותר בעוד שאחרים יפגרו. ככל שמספר המכונות שמהן נקראים נתונים גדול יותר, כך גדלים הסיכויים לקרוא נתונים נוכחיים. בואו נסתכל על דוגמה מעשית. אם יש לך חמישה מחשבים באשכול שלך, ואתה מחליט לכתוב נתונים רק לאחד, ואז לקרוא נתונים ממחשב אחד שנבחר באקראי, אז יש סיכוי של 80% שתקרא נתונים מיושנים. מצד שני, זה ישתמש במינימום משאבים. אז אם נתונים מדור קודם מסתדרים לך, זו אופציה לא כל כך גרועה. במקרה זה, הפרמטרים W ו-R שווים ל-1. מצד שני, אם אתה כותב נתונים לכל חמשת המכונות במסד נתונים של NoSQL, אתה יכול לקרוא נתונים מכל מכונה ולהיות מובטח לקבל נתונים מעודכנים בכל פעם. ביצוע אותה פעולה במספר גדול יותר של מכונות ייקח זמן רב יותר, אך אם חשובים לכם נתונים עדכניים, אז תוכלו לבחור באפשרות זו. במקרה זה, W = R = 5. מהו המספר המינימלי של קריאה וכתיבה הנדרש לעקביות מסד הנתונים? הנה נוסחה פשוטה: R + W ≥ N + 1 , כאשר N הוא מספר המכונות באשכול. משמעות הדבר היא שעם חמישה שרתים, אתה יכול לבחור R = 2 ו-W = 4, או R = 3 ו-W = 3, או R = 4 ו-W = 2. במקרה זה, זה לא משנה לאילו מכונות הנתונים נכתב, הקריאה תמיד תתבצע ממכונה אחת לפחות עם נתונים עדכניים. לבסיסי נתונים אחרים, כגון DynamoDB, יש הגבלות שונות ומאפשרים רק כתיבה עקבית. כל פיסת נתונים מאוחסנת בשלושה שרתים, וכאשר כל מידע נכתב, הוא נכתב לשניים משלושת המכונות. אבל בעת קריאת נתונים, אתה יכול לבחור אחת משתי אפשרויות:

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

למה יש כל כך הרבה מסדי נתונים של NoSQL?

אם אתם עוקבים אחר החדשות האחרונות בתחום פיתוח התוכנה, בוודאי שמעתם על מסדי נתונים רבים ושונים של NoSQL, כמו MongoDB, DynamoDB, Cassandra, Redis ועוד רבים אחרים. אתה אולי תוהה: למה אנחנו צריכים כל כך הרבה מסדי נתונים מסוג NoSQL שונים? הסיבה פשוטה: שמסדי נתונים שונים של NoSQL נועדו לפתור בעיות שונות. זו הסיבה שמספר מסדי הנתונים המתחרים כל כך גדול. מסדי נתונים של NoSQL מתחלקים לארבע קטגוריות עיקריות:

מסדי נתונים מוכווני מסמכים

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

מסדי נתונים של מפתח/ערך

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

מסדי נתונים של גרפים

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

מאגרי מידע עמודים

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

באיזה מסד נתונים כדאי לבחור?

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

איך אתה אמור ללמוד את כל זה?

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

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


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


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


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

בשנת 2018 עם NoSQL

מסדי נתונים של NoSQL הם תחום עצום וצומח במהירות. הם מאפשרים לך לאחסן ולעבד כמויות נתונים בלתי נתפסות בעבר, אבל זה כרוך בעלות. לבסיסי נתונים אלה אין הרבה מהתכונות שאתה מכיר במסדי נתונים יחסיים, ויכול להיות קשה להגדיר את עצמך להשתמש בהם. אבל ברגע שאתה מבין אותם, אתה יכול ליצור מסדי נתונים מבוזרים ניתנים להרחבה שיכולים להתמודד עם כמויות מדהימות של בקשות קריאה וכתיבה, מה שיכול להיות חשוב ביותר ככל שנוצרים כמויות גדולות יותר ויותר של נתונים. מקורי: https://simpleprogrammer.com/guide-nosql-software-developers/