ההחלטה השקטה שקובעת אם המערכת תחזיק מעמד

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

קודם כול: להבין שיש כאן כמה סוגי נתונים שונים

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

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

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

רלציוני, NoSQL או Time-Series — למה כל אחד טוב

מסד רלציוני (PostgreSQL, MySQL) הוא הבחירה הטבעית לנתוני משתמשים, הרשאות ומטא-דאטה: טרנזקציות, אכיפת קשרים בין טבלאות ושפת שאילתות שכל מפתח מכיר. מסדי מסמכים (NoSQL) נוחים כשהסכֵמה משתנה הרבה — למשל קונפיגורציות שונות בין דגמי מכשירים. ולטלמטריה עצמה קיימת קטגוריה ייעודית: מסדי Time-Series שנבנו לדחיסת מיליוני מדידות ולשאילתות לפי חלונות זמן. הרחבנו על הקטגוריה הזו במאמר על אחסון נתוני חיישנים ו-Time-Series Database.

ארבע שאלות שמכריעות את הבחירה

  • מה קצב הכתיבה הצפוי? מכפילים את מספר המכשירים בתדירות הדגימה. מתחת לכמה עשרות רשומות בשנייה — גם PostgreSQL עם הרחבת Time-Series יעמוד בזה; בקצבים גבוהים צריך פתרון ייעודי.
  • אילו שאילתות המוצר באמת צריך? דשבורד שמציג ממוצע שעתי דורש אגרגציות מהירות; חיפוש חופשי בהיסטוריה דורש אינדוקס אחר לגמרי. מתכננים לפי המסכים, לא להפך.
  • כמה זמן שומרים נתונים? מדיניות Retention — נתונים גולמיים לחודש, ממוצעים לשנים — חוסכת עשרות אחוזים מעלות האחסון, וחלק מהמסדים אוכפים אותה אוטומטית.
  • מי מתחזק את זה? שירות מנוהל בענן עולה יותר לכאורה, אבל חוסך משרת DevOps. את התמונה המלאה של עלות תשתית ענן למוצר מחובר כדאי לחשב מראש.

הארכיטקטורה שעובדת בפועל: שילוב ולא כפייה

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

ומה עם פרטיות ורגולציה?

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

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.