SQL לעומת NoSQL – באיזה מה כדאי להשתמש לפרויקט הבא שלך?

אחת השאלות הנפוצות ביותר – באיזה בסיס נתונים עלי להשתמש …


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

ההבדל השכיח ביותר בין שני מערכות מסדי נתונים אלה (DB) הוא ש- SQL הוא יחסי ו- NoSQL הוא לא יחסי.

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

מבנה בסיס נתונים

בואו נדבר על מבנה.

SQL

SQL למסד הנתונים יש מבנה סכימה מוגדר.

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

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

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

ב- DB שלנו יכול להיות לנו טבלת משתמשים, המובנית להלן,

לוח משתמשים
—————————————————-
id | שם | אימייל
—————————————————–
1 אידריס [מוגן בדוא”ל]

כמו כן, נוכל לקבל שולחן הזמנות

לוח הזמנות
———————————————————————————
id | user_id | מספר הזמנה
———————————————————————————
1 1 20000001

User_id בטבלת ההזמנות, מקל על המפה של כל הזמנה בטבלת ההזמנות למשתמש אליו הוא שייך. במקרה של מערכת יחסים אחת לאחת, אנו יכולים לקבל את ה- order_id גם על לוח ה- user אם נחליט להשיג את המשתמש לפי מזהה ההזמנה הקשור אליו..

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

לוח משתמשים
————————————————————————————-
id | שם | אימייל
————————————————————————————-
1 אידריס [מוגן בדוא”ל]

וטבלת ההזמנות תהיה

לוח הזמנות
———————————————————
id | מספר הזמנה
———————————————————
1 2000001

ואז טבלת Pivot תחזיק את שני המזהים כמפתחות זרים.

לוח user_orders_
——————————————————————————
id | order_id | תעודת זהות של המשתמש
——————————————————————————
1 1 1

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

NoSQL

NoSQL בסיסי נתונים נבנו כך שיהיו גמישים יותר מ- SQL DB, גם להכיל כמויות גדולות יותר של נתונים.

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

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

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

ניתן להגדיר אוסף משתמשים כ-,

{id: 1, שם: ‘idris’, אימייל: ‘[מוגן בדוא”ל]‘}

ואפשר להגדיר את אוסף ההזמנות כ-,

{id: 1, order_nummer: 2000001, user_id: 1}

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

{id: 1, order_number: 200001, user {id: 1, name: ‘idris’, email: ‘[מוגן בדוא”ל]‘}}

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

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

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

קנה מידה

בואו ונבדוק כיצד קנה המידה עובד.

SQL

לא ניתן לקנה מידה של SQL DB אופקית אלא רק אנכית. מה זה אומר אפילו?

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

קנה מידה אופקי

קנה מידה אנכי


NoSQL

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

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

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

מה זה שרשור?

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

דוגמאות למסד נתונים

SQL

  • MySQL – בסיס נתונים פופולרי מאוד בקוד פתוח. עם זאת, ניתן להשתמש בקלות במסד הנתונים הרצוי עבור מפתחי PHP רבים עם Node.js, C #, C ++, Java, Perl, Ruby ו- Python..
  • MSSQL – Microsoft SQL מספקת יציבות רבה מכיוון שהפיתוח שלה ישירות ממיקרוסופט, המציעות גם תמיכה מסוימת מבחינת התאוששות מאסון..
  • MariaDB – זה נבנה על ידי MySQL על ידי יצרני MySQL מתוך כוונה לשמור על MariaDB כגרסת חינם לנצח..
  • PostgresSQL – בסיס נתונים פופולרי מאוד בקוד פתוח. גאה בעצמו כמסד הנתונים של הקוד הפתוח המתקדם ביותר בעולם
  • Oracle – בדרך כלל זה מותאם לפתרונות הארגוניים של אורקל עם מגבלות מסוימות על הגרסה החינמית שלה.

NoSQL

  • MongoDB – ככל הנראה ה- NoSQL DB הידוע ביותר, הנפוץ בקרב מפתחי יישומים שעובדים עם מחסנית MERN (MongoDB, Express, React, Node) או MEAN stack (MongoDB, Express, Angular, Node).
  • Firebase – הוצג בשנת 2011 ונרכש על ידי גוגל בשנת 2014, נמצא בשימוש נרחב על ידי מפתחי יישומי אינטרנט וניידים.
  • Apache Couch DB – מסמך DB מבוסס NoSQL המסמך המאחסן נתונים כ- JSON.
  • Redis: זהו NoSQL DB, ככל הנראה הידוע ביותר בשימוש באחסון נתונים עם זמן אופציונלי לחיות. זה ידוע גם בזכות המהירות שלו.

סיכום

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

תגיות:

  • מאגר מידע

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map