הדבר הכי חשוב שצריך לדעת לפני שבוחרים דאטהבייס

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

כאשר בוחרים מערכת בסיסי נתונים, חשוב לתת משקל גם לשפת התשאול וליכולותיה (צילום: Dreamstime)

מאת ליאור קינג, ארכיטקט פתרונות בכיר בחברת Couchbase

שפת SQL, שהומצאה בשנות ה-70, חיה ובועטת יותר מתמיד – ועד היום היא נחשבת בעיני רבים לשפה הטובה ביותר לטיפול בנתונים. בסיסי הנתונים הרלציוניים סיפקו לנו שפה פשוטה ונוחה, שלא מצריכה ידע עמוק בתכנות על מנת להשתמש בה. לשם המחשה, ב-StackOverflow שפת SQL נמצאת במקום השני בפופולריות אחרי ג’אווהסקריפט.

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

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

פריחת המערכות הלא רלציוניות

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

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

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

אפשר ליהנות משני העולמות

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

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

ישנן בשוק יותר מ-300 מערכות בסיסי נתונים והבחירה ביניהן תשפיע עמוקות על המוצר שאותו אתם מפתחים. כאשר בוחרים מערכת בסיסי נתונים, מעבר ליכולת הגדילה של המערכת ולביצועים שהיא מספקת, חשוב לתת משקל גם לשפת התשאול וליכולותיה. כמו שאמר הפילוסוף הנודע לודוויג ויטגנשטיין: “מגבלותיה של שפתי מייצגות את מגבלותיו של עולמי”.

הכתבה בחסות Couchbase

Couchbase (Nasdaq:BASE), שהוקמה ב-2010, מפתחת פלטפורמת נתונים NoSQL המבוססת על קוד פתוח.
הפלטפורמה מתאימה ליישומים בהם יש חשיבות רבה לביצועים גבוהים, זמינות מיידית ומבנה נתונים גמיש.
לטכנולוגיה טווח שימוש רחב – הן כשכבת Cache מבוססת Key-Value והן כבסיס נתונים מבוסס מסמכי JSON.
המערכת מציעה שפת תשאול התואמת לחלוטין את SQL ותומכת בטרנזקציות ACID, מנוע חיפוש, מנוע אנליטי, ומנוע Stream Processing.
זאת בנוסף לגרסת מובייל מוקטנת ליישומים מרוחקים המאפשרת סנכרון נתונים אוטומטי. בין לקוחותיה: LinkedIn ,Pfizer ,AT&T ,Tesco, אמדוקס, Viber, מכבי שירותי בריאות, צה"ל ועוד.

כתב אורח

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

הגב

12 תגובות על "הדבר הכי חשוב שצריך לדעת לפני שבוחרים דאטהבייס"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אחד שלא יודע
Guest
יש פה הרבה מאוד מלל וממש מעט מאוד תוכן… קודם כל, NoSQL זה לא רק מסמכי JSON. יש המון סוגים שונים עם שימושים שונים ומטרות שונות (Wide Column, Time series ועוד). דבר שני, הסיבה העיקרית שאי אפשר להשתמש בדאטה בייס רלציוני במערכות מבוזרות וגדולות היא בגלל CAP Theorem, והיה נחמד אם הכותב היה מרחיב את ההסבר על איך מערכות NewSQL מנסות להתמודד עם המגבלה הזו (כמו ש NoSQL לרוב ויתרו על Consistency כדי לספק את שאר הדברים). כשבוחרים באיזה דאטה בייס להשתמש צריך לראות מה המטרה, איזה סוג נתונים יש לנו, איזה קשרים יש בניהם אם בכלל ומה הציפיות שלנו… Read more »
יוניטי מן
Guest

כשתגובה לכתבה ממומנת יותר טובה מהכתבה 3>

Data Eng
Guest

מערכות NewSQL לא פתרו את מגבלת ה- CAP Theorem. הן מוותרות על Availability לטובת Consistency כמו מערכות NoSQL רבות אחרות (כמו מונגו או Neo4J). זאת מכיוון ש-Consistency הוא אלמנט בסיסי בכל מערכת רלציונית ששומרת על ACID (ה-C ב-ACID). ה-NewSQL עדיין לא תופסות נתח שוק משמעותי.

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

הפי
Guest

Consistency
הוא סתם מילה שזרקו בפנים בשביל שיהיה acid ולא aid
זה לא אומר כלום, כי אם המפתח של האפליקציה כתב קוד לא טוב אז איזה Consistency אתה יכול לחפש את זה.
לגבי CAP Theorem, גם הו בעיקר אקדמי תיאורטי ולא בעל משמעות.
אתה יכול לראות גם את זה באינטרנט או בספר של Martin Kleppman בהוצאת אוריילי

אבי
Guest

אני משתמש ב cockroachdb, כלי מטורף , לגמרי SQL אבל גודל בטבעיות לרוחב עם הוספת מכונות. Multi master + ACID + redundancy

איתמר
Guest

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

פולי
Guest

למיקרוסופט יש את קוסמוס שמראה שאפשר לדבר עם NoSQL בעזרת SQL ובעיקר “לא אכפת לי איך זה עובד, רק שיעבוד”

יוסי
Guest

קוסמוס של מיקרוסופט לא מאפשר SQL אמיתי. אי אפשר לעשות JOIN בין מסמכים שונים. ה-JOIN של קוסמוס הוא רק של המסמך עם אלמנטים פנימיים בתוך ה-JSON.

ירון
Guest

הורדתי את קאוצ’בייס לבדיקה. נראית מערכת מאד מעניינת.

קורא ותיק וטכנולוג
Guest
קורא ותיק וטכנולוג

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

יבגני
Guest

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

יקיר
Guest
לכותב הפוסט : (1) מה הקשר בין שפת SQL לג’אווהסקריפט ? חוץ מזה ששתיהן מופיעות ב StackOverflow, אין להן כל דבר במשותף. זה כמו שאני אגיד שיונית לוי ואל פאצ’ינו הן שתי דמויות פופולריות בטלוויזיה (2) “ובמיוחד בסיסי נתונים מבוססי מסמכים”, באמת ? יש כ”כ הרבה סוגים של NoSQL Databases, לפי איזה מדד הגעת למסקנה ש”במיוחד” Document Based פרחו יותר ? (3) מערכות מבוססות מסמכים שומרות את הנתונים שלהן בפורמטים שונים, לא רק JSON, ויקיפדיה היתה מספרת לך את זה.. (4) רוב מערכות ה NoSQL מציעות שפה מוגבלת ביכולות שלה בהשוואה ל-SQL ? סליחה, אבל על מה אתה מדבר ?… Read more »
wpDiscuz

תגיות לכתבה: