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

למה בסיס נתונים רגיל מתקשה

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

מה מסד נתוני זמן עושה אחרת

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

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

החלטות שצריך לקבל מראש

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

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

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

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

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