ריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו
-
בשונה מהפוסט הזה, יש לי נתונים כגון סטטיסטיקות שאני לא מעוניין לבצע עדכון בשרת על כל עדכון בד"ב כי זה משתנה מאוד הרבה פעמים, למשל בישיבה על קברו לאחר המענה אני משמיע למאזין/מציג לצופה את מספר ההשתפויות ביום זה במסלול הנוכחי.
עד היום הייתי מבצע שאילתת sum מול הד"ב (mysql) על התאריך והמסלול המבוקש, זהו בזבוז משאבים, (בהתחשב בכך שזה בין 15K ל 25K פעמיים ביום)
אני רוצה לשנות את זה.
ברעיון הייתי יכול לבצע משתנה בשרת (node) שמכיל את הנתון מפוצל לי מסלולים, ובכל השתתפות להעלות את המונה, ולאפס אותו כל יום בחמש לפנות בוקר (או להשאיר וכל יום יווצר מחדש לתאריך החדש להיום).
אני חושש מה יקרה באם אני יבצע שינוי בשרת וירענן את התהליך, ואז המשתנה מתאפס, או באם אבצע שינוי ידני (חריג) בטבלת ההשתפות.
לכן אני עדיין מעוניין לבצע ריענון נתונים מול השרת, אבל למעט בו, לבצע שילוב.
זאת אומרת נניח כל 3-5 דקות לבצע ריענון, ואז המונה מעלה שוב את התוצאות לפי ההשתתפות, עד לריענון הבא.
בישיבה על קברו ניתן לומר שאני יכול לבצע רינון 24/6 כל 3-5 דקות כי הוא משתנה 24/6. אבל בחלק מהמערכות אין לי עניין לרענן כל הזמן, רק באם יש תנועה, ולכן חשבתי על כיון בדומה למה ש @yossiz כתב כאן
https://tchumim.com/post/76384
ולבצע בדיקה באם הנתון מיושן מכמה דקות אז לרענן את הנתון לפני ההשמעה
האם יש למישהו רעיון או כיון יותר טוב -
כמו באשכול השכן, גם פה השאלה היא מה מקור המידע, כלומר מאיפה הDB יודע על השינוי.
אם זה תחת שליטתך, אז המושג ריענון לא רלוונטי, אתה פשוט צריך לדעכן ישירות את המשתנה במקביל לעדכון של הDB.
בעת טעינת האפליקציה אתה עושה SUM ושם את זה במשתנה, אז בכל מקרה אתה תמיד מעודכן עם אפס דליי וללא שום דרישות ביצועים.
האם יש צורך לעשות את כל זה זה תלוי מאוד בסיטואציה. השאלה היא מה זה הSUM הזה בכלל. זה לפי קריטריונים? הקריטריונים מהויים אינדקס במסד הנתונים? כמה זמן לוקח התשובה מבחינת המסד? ואם זה מורכב, איך זה מוחזק בNODE? -
@dovid אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
כמו באשכול השכן, גם פה השאלה היא מה מקור המידע, כלומר מאיפה הDB יודע על השינוי.
אם זה תחת שליטתך, אז המושג ריענון לא רלוונטי, אתה פשוט צריך לדעכן ישירות את המשתנה במקביל לעדכון של הDB.
בעת טעינת האפליקציה אתה עושה SUM ושם את זה במשתנה, אז בכל מקרה אתה תמיד מעודכן עם אפס דליי וללא שום דרישות ביצועים.
האם יש צורך לעשות את כל זה זה תלוי מאוד בסיטואציה. השאלה היא מה זה הSUM הזה בכלל. זה לפי קריטריונים? הקריטריונים מהויים אינדקס במסד הנתונים? כמה זמן לוקח התשובה מבחינת המסד? ואם זה מורכב, איך זה מוחזק בNODE?אם אלמד טוב יותר לסמוך על nodejs מבחינת מתי יקרה בריענון ואתחול ומה יקרה, אולי כל זה אכן מיותר.
בעיקרון הכל מגיע מתוך אותו תהליך בנוד.
עם כי כן יצא לי לאחרונה שחלק השתנה ע"י שרת PHP, למשל באלול הוספתי בישיבה על קברו מסלול אמירת פרקי תהילים, שאותו שילבתי בתוך התפריט הראשי שעדיין היה מבוסס PHP מלפני המעבר לנוד. -
למעשה יש לי כאן התלבטות ואשמח אם יש למישהו כיון לייעץ לי.
הרי בדר"כ שמירת הנתונים האמתיים מתבצעת בד"ב (mysql בענייננו).
יש לי כעת פרוייקט שיש בו טבלת של הרשמה מסויימת, שכל הזמן נרשמים שם אנשים, ייתכן לכל אחד כ 30 שורות, אבל אין כפילויות, כל שורה היא במסלול אחר.
הקטע הוא שאני צריך בתוכנה של הניהול שיוצגו פילוחים בזמן אמת, לפי כארבע קטגוריות, כגון עיר המנוי, מצב אישי של המנוי וכו', והכל מפולח לפי מסלול ולפי סוג ההרשמה אותו בחר וכו'.
השאלה היא כך, השרת הוא נוד, ולמען האמת ניתן לעשות את כל הפילוחים בשאילתאות SQL שמבוצעות ע"י השרת ברגע האמת של הבקשה ומחזיר אותם לממשק הלקוח (זה מבוסס API), רק שהריענון מבוצע כל שניה, וייתכנו כמה חלונות פתוחים בו זמנית שזה יצטבר להמון בקשות.
מצד שני ניתן לבצע את הפילוחים בנוד (יותר מסובך) ואז אין כזה בזבוז משאבים, וזה אומר שמלבד שמירת כל רישום בד"ב אני שומר אותו גם באובייקט בשרת, אבל אז אתמודד במה קורה בעת שאני יבצע שינוי בשרת ואאתחל אותו, האם ומה לשאוב מהד"ב לצורך שימוש בנתונים בשרת.
ייתכן והשאלה לא כ"כ ברורה למען האמת, כי גם אני קצת מבולבל עדיין בנושא, בכל מקרה אם מישהו הבין חלקי דברים ויש לו מה להוסיף, אשמח. -
@dovid אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
אני חושב שכל עוד שמשנתך לא סדורה תעבוד מול הmysql.
כמובן תוודא שהכל יעיל שמה מבחינת האינדקסים וכדומה.בא נגיד ואני יוצא עם 300 בקשות ב 60 שניות שבכל בקשה אני מבצע שאילתה כדוגמת (דוגמה לקוחה מנסיון בישיבה על קברו בטבלת העונים)
SELECT COUNT(`id`), `status`, `kod_mosad`, `maslul`, `date`, `goral` FROM `users_limud` WHERE `date` > 20191022 GROUP BY `status`, `kod_mosad`, `maslul`, `date`, `goral`(עשיתי סינון תאריך כי יש בטבלה מעל 4.5M ולא רציתי סתם להעמיס).
זה נתן לי
האם זה מוגזם? -
@dovid אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
לא הבנתי, 300 הבקשות הם עם קריטריון אחר מאשר התאריך, לא ככה?
הדוגמה שהבאתי לא כ"כ נכונה לפרוייקט הנוכחי שאינו מפולח לפי תאריך אלא הייתי קורא לזה שלבים, כל נרשם אמור לעבור כ 20 שלבים, ובכל שלב שורה נוספת בטבלה.
(עיקר הרישום יבוצע בסביבות כשעה מפתיחת המערכת, שבו יירשמו כאלף אנשים 20 שלבים)
300 הבקשות הם כל הזמן אותו דבר, פילוח מלא של כל המידע נכון לשניה זו, רק שהיות וזה פתוח מכמה מקומות כתבתי כ 300 בקשות, 60 בקשות בדקה, כל שניה בקשה אחת מ5 מקורות. -
@חוקר אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
300 הבקשות הם כל הזמן אותו דבר, פילוח מלא של כל המידע נכון לשניה זו, רק שהיות וזה פתוח מכמה מקומות כתבתי כ 300 בקשות, 60 בקשות בדקה, כל שניה בקשה אחת מ5 מקורות.
אז עושים רק שאילתה אחת ומחזירים את התשובה לכולם כל עוד לא עברה שניה מאז.
-
@dovid אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
@חוקר אמר בריענון נתונים מתוך הד"ב לאחר משך זמן כלשהו:
300 הבקשות הם כל הזמן אותו דבר, פילוח מלא של כל המידע נכון לשניה זו, רק שהיות וזה פתוח מכמה מקומות כתבתי כ 300 בקשות, 60 בקשות בדקה, כל שניה בקשה אחת מ5 מקורות.
אז עושים רק שאילתה אחת ומחזירים את התשובה לכולם כל עוד לא עברה שניה מאז.
אכן זה הכיוון שגם אני התחלתי לחשוב תוך כדי כתיבת השורות בשאלה, (עצם הכתיבה עזרה לי להגיע להבנה זו), אבל היות וכבר כתבתי רציתי לראות האם יש לעוד מישהו מה לעזור.
