התוכנה הראשית של פרויקט MBM אמורה לאסוף ולטפל בהמון נתונים. כמה זה המון? תלוי במשתמש: במקרים קיצוניים, הכמות יכולה להגיע לכמאה מגהבייט ביום. כל הנתונים מגיעים בפורמט קבוע ומובנה. נשמע כמו מקרה קלאסי לשימוש במסד נתונים, נכון? אך לאחר בדיקת הנושא לעומק החלטתי לוותר על הרעיון ולעבוד ישירות עם קבצים גולמיים, שינוהלו על ידי התוכנה עצמה. מה עומד מאחורי ההחלטה המוזרה הזו?
השיקול הראשון, וזה שימשוך מן הסתם הכי הרבה אש, הוא שאני לא רגיל לעבוד עם מסדי נתונים, ולדעתי פרויקט רגיש ומורכב כל כך הוא לא ההזדמנות המתאימה לחקור טכנולוגיות חדשות (חדשות עבורי, בכל אופן). אם אני יכול לפתור את הבעיה בעזרת הכלים המוכרים לי, ובלי להסתבך יותר מדי, מוטב. יהיו מספיק הזדמנויות אחרות, ועם פחות סיכון, לשחק במסדי נתונים וללמוד אותם.
השיקול השני היה שהכלים המוצעים לא מצאו חן בעיניי – גם מסדי הנתונים עצמם וגם הרכיבים שאמורים לאפשר לי לנהל אותם דרך דלפי. חלקם היו בתשלום ניכר, שאני לא רוצה להפיל על הלקוח ובוודאי שלא לממן מכיסי. חלקם היו בקוד פתוח שלא עודכן זמן רב, ושיש לו רשימת באגים פתוחה. חלקם הושמצו על ידי אנשים ששאלתי, מסיבות שנשמעו לגיטימיות. למעשה, כל אופציה עוררה חוסר נוחות מסוים – ובמה זה עדיף על חוסר הנוחות שבוויתור על מסדי נתונים בכלל?
השיקול השלישי והחשוב מכולם הופיע רק אחרי שחקרתי את אופציות מסדי הנתונים לעומק. עד לאותו רגע לא הטלתי ספק בתפיסה של "הרבה נתונים => מסד נתונים", אך כשהתאכזבתי מהאפשרויות שעמדו לפניי ובדקתי שוב מה בדיוק התוכנה אמורה לעשות עם הנתונים, הבנתי שדווקא קובצי CSV פשוטים יכולים לספק את כל הדרישות. הנה העיקריות שבהן:
- הנתונים שדרושים לעבודה השוטפת של התוכנה שמורים בזיכרון RAM. השמירה בקבצים היא רק לצורך גיבוי ו"היסטוריה".
- נתון שנשמר לעולם לא ישתנה. למעשה, האחסון הוא לא יותר מאשר ארכיון – אין אפילו צורך במיון או סינון כלשהם.
- אחזור נתונים מאוחסנים נעשה רק לעתים רחוקות, למטרות נקודתיות, ורק ב"גושים": פילוחים, גם אם יידרשו, יהיו מהסוג הבסיסי ביותר.
- הארכיון אינו אמור לעבוד בזמן אמת מול שום גורם נוסף.
- בתכנון התוכנה יש חשיבות גדולה למהירות ופשטות.
כמו כן, גם אם חושבים על אופציות עתידיות שלא הוגדרו במפרט ועל האפשרות שמישהו יצטרך, מכל סיבה שהיא, להעביר את הנתונים שנאספו למסד נתונים "רציני", הרי שפורמט ה-CSV (טקסט פשוט, שורה לכל רשומה, עם פסיקים להפרדה בין השדות) אמור להיות נוח דיו לעיבוד.
וכך קרה שתוכנה שעיקר משימתה הוא לטפל בנתונים תיבנה ללא מסד נתונים – לפחות לא במשמעות המקובלת של הביטוי.
יצא לך להסתכל על SQLITE? הוא די נחמד בשביל אפליקציות שבדיוק יש להן צרכים צנועים יחסית. פשוטה מצד אחד וסקלבילית מצד שני.
כן, גם זו היתה אחת מהאפשרויות…
היי עידו,
בלוג מושקע עם רעיונות מעניינים, כל הכבוד! לצערי (כנראה?!) גם אני סולד ממסדי נתונים. פתרון מעניין שמצאתי לאיסוף נתונים נומרים בדרישות דומות מאוד לדרישות שלך, היא שמירת הדלטאות ביחס לנתון מסויים שמשתנה מידי זמן קבוע.
למשל: פעם בשעה נשמר נתון מלא, וכל עשר דקות לאחריו נשמרים רק ערכי השינויים מהנתון המסויים.
בצורה זו הצלחתי להקטין את נפח השמירה משמעותית ולאפשר דינאמיות.
שים לב שהשיטה הזאת אפשרית לטווח נתונים מוגדר.
בהצלחה!
נדמה לי שקוראים לזה Incremental Backup. זו אכן שיטה מעולה לחסוך במקום אחסון כשמתקיימים תנאים מסוימים – ולרוע המזל, הם דווקא לא מתקיימים במלואם במקרה שלי. למשל, אני עובד בפורמט CSV כדי שאם אי פעם בעתיד מישהו ירצה לייבא את המידע לתוכנה אחרת, הוא יכול לעשות זאת בקלות. אם אגבה בשיטה של נקודות ציון ושינויים, אצטרך לפרק את השמירה לשני קבצים בעלי מבנה שונה (מבנה של נקודת ציון מלאה ומבנה של מידע-על-שינוי), והקריאה מהם תחייב עיבוד לא טריוויאלי…
היי עידו, לדעתי לא צריך לחשוש מלעבוד עם מסדי נתונים רק בגלל שלא יצא לך להכיר… א. אחרת איך יצא לך להכיר? 🙂 ב. מסדי נתונים נועדו לבצע עבודה של שמירת מידע, בין אם בזיכרון ובין אם על הדיסק. הם נועדו לאפשר הכנסה קלה ושליפה קלה של מידע. יש בהם המון חוכמה וידע… לא משנה כמה תתאמץ, כנראה שמסדי נתונים יעשו עבודה טובה ממך בשמירת המידע. אז למה להמציא את הגלגל? ג. יש מסדי נתונים מכל מיני סוגים ומינים. חלק מתמחים בשמירת מידע בדיסק וחלק ב- RAM. חלק עובדים עם SQL (כמו mysql) וחלק ללא (תקרא על noSQL). חלק חינמים… לקרוא עוד »
אין לי שום דבר נגד מסדי נתונים או למידה שלהם – אני פשוט מעדיף לא ללמוד את זה דווקא על בשרו של פרויקט קריטי. גם ככה מדובר במערכת מסובכת למדי, ולהכניס לתוכה דברים שאני עדיין לא מכיר תוך כדי התקדמות נראה לי חסר אחריות ומקור להמון בעיות פוטנציאליות. אני צריך לשמור כמות מסוימת של נתונים ב-RAM בכל מקרה, ואני צריך גישה מהירה אליהם. עם כל הכבוד למתכנני מסדי הנתונים, ואין ספק שיש שם מתכנתים מוכשרים פי אלף ממני, פשוט לא ייתכן שקריאה וכתיבה למסד חיצוני תהיה מהירה או פשוטה יותר מאשר, לצורך העניין, רשימות מקושרות בסיסיות שאני מתחזק בקוד. השם… לקרוא עוד »
היי עידו ,
יש הרבה מערכות מסחריות אפילו
ששומרות נתונית במבנה של קבצים שטוחים.
אפשר לדמיין את זה כקובץ טקסט ענקי – עם שדות מובנים כבר בתוכו
עם החומרה של ימינו זה עובד מהר מאוד.
כך שאני לא צופה בעיות ואני חושב שהגישה שלך נכונה בעניין.
בהצלחה !
שמעון.
היי עידו, אחלה בלוג, אחלה כתבות (בעיתונים ברשת וכו'). מאוד נהנה לקרוא. לגבי התוכנה. אני לא מתכנת, גם לא חובב, אבל אני עובד מספיק עם מחשבים ותוכנות ובנוסף אני עוסק לא מעט בלקוחות שצריכים איסוף נתונים וכו'. לטעמי הבעיה במידע ארכיוני ואיסוף מידע היא שבסוף מישהו ירצה לגשת אליו וירצה שזה יהיה נוח. הבעיה השניה היא שבמוקדם או במאוחר, כפי שקורה בעולם המחשבים, הארכיון הזה יהיה פתוח או יתוקשר גם מעבר למשתמש הראשוני. אני מסכים איתך, גם לטעמי רוב מסדי הנתונים חסרים את הצרכים הספציפיים שדווקא אמצעים פשוטים יותר (כגון קבצי CSV) עונים עליהם טוב יותר בעזרת מעט חשיבה ושימוש… לקרוא עוד »
תודה חגי,
במקרה הספציפי הזה, אם מישהו ירצה לגשת לנתונים שנאספו כמסד נתונים "רגיל", זה כבר יהיה כל כך רחוק מהייעוד המקורי של התוכנה, שאני אעדיף לפתח את זה כמוצר נפרד – מקסימום עם אופציית המרה של נתונים היסטוריים לפורמט החדש…