מעבר ל- NoSQL: המקרה עבור SQL מבוזר

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

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

ההתקפה על SQL

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

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

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

הבטחות NoSQL קיימות והבטחות שבורות

מסדי נתונים של NoSQL התרחבו בהרבה, הרבה יותר טוב ממסדי הנתונים של Oracle, DB2 או SQL Server, שכולם מבוססים על עיצוב בן 40 שנה. עם זאת, לכל סוג של מסד נתונים NoSQL היו מגבלות חדשות:

  • חנויות ערך מפתח: אין בדיקה פשוטה יותר מ- db.get (מפתח). עם זאת, לא ניתן לבנות בצורה כזו חלק ניכר ממקרי הנתונים והשימוש בעולם. יתר על כן, אנחנו באמת מדברים על אסטרטגיית מטמון. חיפוש המפתח הראשי הוא מהיר בכל בסיס נתונים; זה רק מה שיש בזיכרון שחשוב. במקרה הטוב, אלה מתרחבים כמו מפת חשיש. עם זאת, אם אתה צריך לעשות 30 נסיעות בסיס נתונים כדי לחבר את הנתונים שלך מחדש או לבצע כל סוג של שאילתה מסובכת - זה לא יעבוד. אלה מיושמים לעתים קרובות יותר כמטמון מול מאגרי מידע אחרים. (דוגמה: Redis.)
  • מאגרי מסמכים: אלה השיגו את הפופולריות שלהם מכיוון שהם משתמשים ב- JSON ואובייקטים קלים לסידור ל- JSON. לגרסאות הראשונות של מאגרי המידע הללו לא היה צירוף, ולכניסה של כל ה"ישות "שלך למסמך ענק אחד היו חסרונות משלה. ללא ערבויות עסקאות, היו לך גם בעיות שלמות הנתונים. כיום, כמה מאגרי מסמכים תומכים בצורה פחות חזקה של עסקאות, אך אין זו אותה ערבות שרוב האנשים רגילים אליה. כמו כן, גם לשאילתות פשוטות אלה לעיתים קרובות איטיים במונחים של זמן אחזור - גם אם הם משתנים בצורה טובה יותר במונחים של לאורך. (דוגמאות: MongoDB, Amazon DocumentDB.)
  • חנויות עמודות: אלה מהירות כמו חנויות בעלות ערך מפתח לחיפושים והן יכולות לאחסן מבני נתונים מסובכים יותר. עם זאת, לעשות משהו שנראה כמו צירוף על פני שלוש טבלאות (בשפה RDBMS) או שלושה אוספים (בשפה MongoDB) כואב במקרה הטוב. אלה ממש נהדרים לנתוני סדרות זמן (תן לי את כל מה שקרה בין השעות 13: 00-14: 00).

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

תקני מסדי נתונים עדיין חשובים

אחד הדברים שהפכו את מאגרי המידע הדומיננטיים לדומיננטיים היה שיש להם מערכת אקולוגית משותפת של כלים. ראשית, היה SQL. למרות שדיאלקטים יכולים להיות שונים - כמפתח או מנתח אם עברת מ- SQL Server 6.5 ל- Oracle 7, ייתכן שיהיה עליך לתקן את השאילתות שלך ולהשתמש ב- "(+)" לצירופים חיצוניים - אבל דברים פשוטים עבדו ודברים קשים היו קלים למדי לתרגם.

שנית, היה לך ODBC, ובהמשך, JDBC, בין היתר. כמעט כל כלי שיכול להתחבר ל- RDBMS אחד (אלא אם כן הוא נועד במיוחד לניהול RDBMS זה) יכול להתחבר לכל RDBMS אחר. יש המון אנשים שמתחברים ל- RDBMS מדי יום, ומוצצים את הנתונים ל- Excel על מנת לנתח אותם. אני לא מתייחס לטבלאו או לאף אחד ממאות כלים אחרים; אני מדבר על "ספינת האם", אקסל.

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

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

GraphQL ועליית ניהול המדינה

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

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

מרבית יישומי GraphQL עובדים עם כלי מיפוי התייחסות-עצמים כמו Sequelize או TypeORM. במקום לדלוף את דאגת ניהול המדינה לאורך כל הקוד שלך, יישום ו- API של GraphQL מובנה היטב יכתוב ויחזיר את הנתונים הרלוונטיים כאשר השינויים מתרחשים בגרף האובייקטים שלך. למי, ברמת היישום, אכפת כיצד הנתונים נשמרים, באמת?

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

הזן NewSQL או SQL מבוזר

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

כך שהנחת היסוד של "אחסון חפצים" במערכת יחסית הייתה שגויה. מה אם הבעיה העיקרית במאגרי מידע התייחסותיים הייתה הקצה האחורי ולא הקצה הקדמי? זה הרעיון שמאחורי מה שמכונה מאגרי מידע "מבוזרים SQL" מה שמכונה "NewSQL" או יותר נכון. הרעיון הוא לשלב למידות אחסון NoSQL ורעיון ה- Spanner של גוגל עם קוד פתוח של קוד פתוח, RDBMS כמו PostgreSQL או MySQL / MariaDB.

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

בינתיים, כל המערכת האקולוגית של SQL עדיין פועלת! אתה יכול לעשות זאת מבלי לבנות מחדש את כל תשתית ה- IT שלך. למרות שאולי אינך משחק "לקרוע ולהחליף" את ה- RDBMS המסורתי שלך, רוב החברות אינן מנסות להשתמש יותר ב- Oracle. והכי חשוב, אתה עדיין יכול להשתמש ב- SQL ובכל הכלים שלך בענן וגם ברחבי העולם.