מה זה NoSQL: מדריך לבסיסי נתונים לא רלציוניים

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

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

במדריך הזה נסביר:

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

מה זה NoSQL

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

ההבדל המרכזי הוא באופן שבו הנתונים נשמרים.

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

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

NoSQL זה לא "בלי SQL"

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

למה נוצר המודל של NoSQL

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

מה זה ACID בקצרה

• אטומיות (Atomicity). פעולה על הנתונים מתבצעת במלואה או לא מתבצעת בכלל. אין מצב ביניים.
• עקביות (Consistency). אחרי כל פעולה הנתונים נשארים תקינים ועומדים בכללים שהוגדרו. כשלקוח מעביר 100 ₪ מחשבון אחד לאחר, היתרה בחשבון הראשון יורדת ב-100 ₪ ובשני עולה באותו סכום. אם הייתה תקלה באמצע, המערכת חוזרת למצב התקין שהיה לפני הפעולה.
• בידוד (Isolation). פעולות שרצות במקביל לא רואות את מצבי הביניים של זו. אם שני לקוחות מנסים לקנות באותו רגע את הפריט האחרון במלאי, רק אחד מהם יצליח, והשני יקבל הודעה שהמוצר אזל.
• עמידות (Durability). אחרי שפעולה הושלמה, השינוי נשמר גם אם השרת קורס שנייה אחר כך.

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

הצמיחה של האינטרנט

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

היתרונות של NoSQL ועקרונות BASE

היתרונות המרכזיים

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

מה זה BASE

את הגישה של NoSQL מתארים לרוב בעקרונות BASE, ניגוד מכוון ל-ACID:

• זמינות בסיסית (Basically Available). המערכת ממשיכה לקבל קריאות וכתיבות גם כשחלק מהשרתים לא זמינים. המחיר: לפעמים תקבלו תשובה שעדיין לא מעודכנת לגמרי.
• מצב גמיש (Soft state). מצב הנתונים יכול להשתנות עם הזמן, גם בלי פעולה חדשה, כי השרתים מסנכרנים ביניהם עדכונים.
• עקביות בסופו של דבר (Eventually consistent). לזמן קצר שרתים שונים יכולים להחזיק גרסאות שונות של אותו נתון, אבל בסוף כולם יגיעו לאותו מצב.

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

משפט CAP

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

איך עובד בסיס נתונים NoSQL: דוגמה מחנות אונליין

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

הגישה הרלציונית

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

עכשיו מנהלת המוצר מבקשת להוסיף לכל מוצר רשימת ביקורות של לקוחות עם דירוג. בגישה הרלציונית צריך:

1. לתכנן איך הנתונים החדשים ישתלבו בסכמה;

2. ליצור טבלת ביקורות חדשה;

3. לקשר אותה לטבלת המוצרים במפתח זר;

4. לעדכן את הקוד שכותב וקורא את הביקורות.

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

הגישה מבוססת המסמכים

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

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

מה המחיר

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

סוגי בסיסי נתונים NoSQL

מאגרי מפתח-ערך (Key-Value)

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

מאגרים כאלה מהירים מאוד ומתאימים לשמירת סשנים של משתמשים, עגלות קניות, מטמון (cache) של עמודים ותוצאות, מונים והגבלת קצב בקשות. דוגמאות: Redis ו-Valkey, הגרסה הקוד-פתוח שנוצרה ממנו, ו-Amazon DynamoDB, שתומך גם במודל מסמכים.

בסיסי נתונים מבוססי מסמכים (Document)

כאן כל רשומה היא מסמך בפורמט JSON או בפורמט קרוב, עם מבנה גמיש ושדות מקוננים. זה הסוג הנפוץ ביותר של NoSQL באפליקציות ובאתרים. הוא מתאים לקטלוגי מוצרים, לפרופילי משתמשים, לתוכן ולאפליקציות מובייל. דוגמאות: MongoDB, Google Cloud Firestore (חלק מ-Firebase) ו-Couchbase.

בסיסי נתונים של עמודות רחבות (Wide-Column)

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

המערכות האלה בנויות לכמויות עצומות של כתיבות ולפיזור על פני הרבה שרתים, ולכן משמשות לנתוני חיישנים, ליומני אירועים ולהיסטוריית פעולות. דוגמאות: Apache Cassandra, ScyllaDB ו-Apache HBase. אל תבלבלו אותן עם בסיסי נתונים אנליטיים עמודתיים כמו ClickHouse או Google BigQuery: גם הם שומרים נתונים לפי עמודות, אבל עובדים ב-SQL ומיועדים לדוחות ולניתוח נתונים.

בסיסי נתונים גרפיים (Graph)

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

גרפים מתאימים למנועי המלצות, לזיהוי הונאות, למפות של קשרים בין לקוחות, ספקים ומוצרים ולגרפי ידע. דוגמאות: Neo4j ו-Amazon Neptune.

בסיסי נתונים וקטוריים (Vector)

הסוג הצעיר ביותר, שצמח יחד עם הבינה המלאכותית. הוא שומר את המשמעות של טקסטים, תמונות ומסמכים כרשימות של מספרים, שנקראות וקטורים, ומחפש לפי דמיון במשמעות ולא לפי מילים מדויקות. ככה צ'אטבוט מוצא בתוך מאות מסמכים של העסק את הקטע שעונה על השאלה של הלקוח, גם אם הלקוח ניסח אותה במילים אחרות. זה הלב של שיטת RAG, שבה בינה מלאכותית עונה על סמך הידע של העסק. דוגמאות: Pinecone, Qdrant ו-Weaviate, וגם תוסף pgvector ל-PostgreSQL וחיפוש וקטורי ב-MongoDB Atlas.

SQL או NoSQL: איך בוחרים

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

מתי לבחור בסיס נתונים רלציוני

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

מתי לשקול NoSQL

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

הגישה הנפוצה היום: שילוב

הרבה מערכות משלבות כמה סוגים, גישה שנקראת polyglot persistence. למשל, חנות אונליין שומרת הזמנות ותשלומים ב-PostgreSQL או ב-MySQL, מחזיקה סשנים ועגלות ב-Redis, ומפעילה צ'אטבוט עם בסיס נתונים וקטורי. כל כלי עושה את מה שהוא טוב בו. אבל כל מערכת נוספת היא עוד משהו שצריך לתחזק, לגבות ולאבטח, ולכן לא כדאי להוסיף כלים בלי צורך אמיתי.

איפה תפגשו NoSQL באתר ובעסק שלכם

גם אם לא תכתבו אף פעם שאילתה, סביר שאתם כבר משתמשים ב-NoSQL בלי לדעת.

אפליקציות ופלטפורמות no-code

Firebase של Google, עם Firestore, הוא בסיס נפוץ לאפליקציות מובייל ולאפליקציות ווב, כי הוא מספק בסיס נתונים, הרשמת משתמשים וסנכרון בזמן אמת בשירות אחד. גם הרבה כלים מעולם ה-no-code וה-low-code שומרים את הנתונים במבנה גמיש מאחורי הקלעים.

אתרים, מטמון וביצועים

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

צ'אטבוטים ובינה מלאכותית

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

אוטומציות ואינטגרציות

ב-n8n יש חיבורים מובנים ל-MongoDB, ל-Redis ולבסיסי נתונים וקטוריים, ולכן אפשר לבנות תהליכים כמו: ליד מטופס באתר נשמר כמסמך, מועשר בנתונים, נשלח ל-CRM ומפעיל הודעת וואטסאפ. כשאין חיבור מובנה, מתחברים דרך REST API.

פרטיות ואבטחת מידע

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

טעויות נפוצות בעבודה עם NoSQL

בוחרים NoSQL כי זה "מודרני"

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

"אין סכמה" הופך ל"אין סדר"

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

מעצבים את הנתונים כמו טבלאות

העברה של סכמה רלציונית כמו שהיא ל-NoSQL מייצרת את החסרונות של שני העולמות. ב-NoSQL מתכננים את המבנה לפי הבקשות שהאפליקציה תבצע הכי הרבה.

שומרים כסף ומלאי בלי טרנזקציות

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

מתעלמים מהעלויות בענן

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

שוכחים גיבויים ויציאה

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

איך RJL Studio עוזרת לבחור ולחבר את בסיס הנתונים הנכון

ב-RJL Studio אנחנו מתכננים את מבנה הנתונים כבר בשלב האפיון, כדי שהאתר, האפליקציה והאוטומציות יעבדו מהר ויגדלו בלי לבנות הכול מחדש. אנחנו בונים אתרים עם CMS מתוכנן, מחברים אותם ל-CRM, למערכות תשלום ולבסיסי נתונים חיצוניים, ומקימים צ'אטבוטים שעונים על סמך הידע של העסק, עם בסיס נתונים וקטורי במקום הנכון ולא בכל מקום.

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

שאלות נפוצות על NoSQL

מה ההבדל העיקרי בין SQL ל-NoSQL?

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

האם NoSQL מהיר יותר מ-SQL?

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

האם עסק קטן צריך NoSQL?

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

מה זה MongoDB?

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

אפשר להשתמש ב-SQL וב-NoSQL באותו פרויקט?

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