SQL או NoSQL? זאת השאלה

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

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

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

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

"בידוד" צריך לוודא שעסקות המתבצעות בו זמנית יניבו את אותה התוצאה אם הן מבוצעות ברציפות.

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

דנילו פוצ'יה, אוונגליסט טכני ב-AWS

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

התפוצצות המידע

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

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

יתרונות ה-NoSQL

מסדי נתונים Non-relational לא פועלים על פי סכמה מקיפה כמו מסדי נתונים SQL. בדרך כלל, "Hash key" משמש להבאת ערכים מסוימים, כגון אוסף של עמודות או JSON מובנה למחצה XML, או מסמכים אחרים עם מאפיינים נלווים. עם NoSQL (המכונה גם "Not Only SQL") ניתן לאחסן נתונים לא מובנים בלי סכמת טבלאות קבועה, מה שמתאים לסוגי נתונים בהם לקשר בין הנתונים אין תפקיד משמעותי. כאשר יישום בעיקר מאנדקס ומבקש נתונים ולא צריך למזגם או לדרוש טרנזקציות מורכבות, NoSQL הוא הבחירה הברורה.

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

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

הכותב הינו אוונגליסט טכני ב-AWS.