מהו NoSQL? מאגרי מידע לעתיד בקנה מידה ענני

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

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

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

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

NoSQL לעומת SQL

ההבדל המהותי בין SQL ל- NoSQL הוא לא כל כך מסובך. לכל אחד מהם יש פילוסופיה שונה לאופן שבו יש לאחסן נתונים ולאחזר אותם.

במסדי נתונים של SQL, לכל הנתונים יש מבנה מובנה. מסד נתונים קונבנציונאלי כמו Microsoft SQL Server, MySQL או Oracle Database משתמש בסכמה - הגדרה רשמית של אופן ההרכב של נתונים המוכנסים למסד הנתונים. למשל, עמודה נתונה בטבלה עשויה להיות מוגבלת למספרים שלמים בלבד. כתוצאה מכך, הנתונים הרשומים בעמודה יהיו בעלי נורמליזציה גבוהה. הסכימה הקשיחה של מסד נתונים של SQL מקלה יחסית על ביצוע צבירות על הנתונים, למשל באמצעות JOINs.

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

  1. מאגרי מסמכים (למשל CouchDB, MongoDB). נתונים מוכנסים מאוחסנים בצורה של מבני JSON חופשיים או "מסמכים", כאשר הנתונים יכולים להיות כל דבר, החל ממספרים שלמים ועד מחרוזות וכלה בטקסט חופשי. אין צורך מובנה לציין אילו שדות יכלול מסמך.
  2. חנויות בעלות ערך מרכזי (למשל רדיס, ריאק). ניתן לגשת לערכים בעלי צורה חופשית - ממספרים שלמים פשוטים או מחרוזות למסמכי JSON מורכבים - באמצעות מקשים.
  3. חנויות עמודות רחבות (למשל HBase, Cassandra). הנתונים נשמרים בעמודות במקום בשורות כמו במערכת SQL רגילה. ניתן לקבץ או לצבור כל מספר עמודות (ולכן סוגים רבים של נתונים) לפי הצורך לשאילתות או תצוגות נתונים.
  4. מאגרי גרפים (למשל Neo4j). הנתונים מיוצגים כרשת או גרף של ישויות והקשרים שלהם, כאשר כל צומת בגרף הוא נתח נתונים חופשי.

אחסון נתונים ללא סכמה שימושי בתרחישים הבאים:

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

שאילתת מסדי נתונים NoSQL

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

לעומת זאת, כל מסד נתונים של NoSQL נוטה להיות תחביר משלו לצורך שאילתות וניהול הנתונים. CouchDB, למשל, משתמש בבקשות בצורה של JSON, שנשלחות באמצעות HTTP, כדי ליצור או לאחזר מסמכים ממסד הנתונים שלה. MongoDB שולח אובייקטים של JSON דרך פרוטוקול בינארי, באמצעות ממשק שורת פקודה או ספריית שפות.

חלק ממוצרי NoSQL יכולים להשתמש בתחביר דמוי SQL לעבודה עם נתונים, אך רק במידה מוגבלת. לדוגמא, לאפצ'י קסנדרה, מאגר חנויות עמודות, יש שפה דמויית SQL משלה, שפת השאילתות קסנדרה או CQL. חלק מתחביר ה- CQL יוצא היישר מחוברת ה- SQL, כמו מילות המפתח SELECT או INSERT. אך אין דרך לבצע JOIN או שאילתת משנה בקאסנדרה, ולכן מילות המפתח הקשורות אינן קיימות ב- CQL.

ארכיטקטורה לא משותפת

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

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

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

מגבלות NoSQL

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

אין סכמה

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

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

עקביות בסופו של דבר

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

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

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

בחלק ממאגרי המידע של NoSQL יש מנגנונים חלקיים לעקיפת הבעיה. למשל, ל- MongoDB יש ערבויות עקביות לפעולות בודדות, אך לא למסד הנתונים כולו. Microsoft Azure CosmosDB מאפשר לך לבחור רמת עקביות לכל בקשה, כך שתוכל לבחור את ההתנהגות המתאימה למקרה השימוש שלך. אך עם NoSQL, צפו לעקביות בסופו של דבר כהתנהגות ברירת המחדל.

נעילת NoSQL

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

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

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

כישורי NoSQL

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

לצורך התייחסות, מדווחת Indeed.com כי נכון לסוף שנת 2017, נפח רשימות המשרות עבור מאגרי SQL קונבנציונליים - MySQL, Microsoft SQL Server, Oracle Database וכן הלאה - נותר גבוה יותר בשלוש השנים האחרונות בהיקף המשרות. עבור MongoDB, Couchbase ו- Cassandra. הביקוש למומחיות NoSQL הולך וגדל, אך זה עדיין חלק מהשוק עבור SQL קונבנציונאלי.

מיזוג SQL ו- NoSQL

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

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

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

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