עדכון תהליך ה NODEJS לאחר ביצוע עריכה בד"ב MySQL
-
@dovid
הכל בשליטתי, במקרה זו למשל יש שתי מקורות שינוי.
א. בממשק של המזכיר של ישיבה על קברו (פריימוורק YII2 מבוסס PHP). [עשיתי לו אפשרות הוספת שורה חדשה - כמעט ולא בשימוש, עריכת שורה - בשימוש לתיקונים, וחלון יבוא מאקסל ע"י העתק הדבק - שזה מה שהכי שימושי]
ב. בד"ב עצמו ע"י PMA למשל.
רוב השינויים מבוצעים ע"י המזכיר באופציה א, אלא א"כ זה משהו שינוי מרובה לפי קריטיונים וכדומה שאז אני עושה בד"ב.
רק שזה 2 מערכות, זה PHP והמערכת עצמה בנוד.
אז לכאורה אצטרך לעשות API ולהגדיר בYII2 בכל אחד מהשלושה דלעיל שיבצע קריאה לשרת לAPI לתהליך הנוד לביצוע ריענון?
(בשינויים שאני יעשה אוכל לקרוא לזה בצורה ידנית) -
@dovid אמר בעדכון תהליך ה NODEJS לאחר ביצוע עריכה בד"ב MySQL:
אתה צריך "ללכת" למקור השינוי ולדאוג שהוא יפנה לשרת הnode עם דיווח על העדכון במלואו ("הערך X שונה Y לZ").
במקרה שלי, כבר יותר קל לקרוא לפונקציית ריענון מלא מול השרת, כי למשל בייבוא טבלת שאלות לכמה ימים אין סיבה לעדכן כעת הכל, וזה סתם מיותר לשלוח לשרת נוד בנפרד את כל השאלות, ובין כך אני חייב לבנות פונקציית ריענון מהד"ב עבור כל פעם אני מתאחל את השרת לאחר שינויים (קורא הרבה)
-
תראה במריבה בין לעשות בדרך X או בדרך של "איך שיוצא" השני תמיד מנצח בטווח הקצר.
אבל בראיה רחבה אתה חייב להפסיק את החגיגה. אין עדכונים בכמה דרכים וודאי שלא דרך הPMA...
היחיד שצריך לעדכן את הDB זה הנוד, והוא עצמו במקביל מעדכן את עצמו נקודתית בלי טעינה כוללת, אפילו שבטווח הקצר מדובר במשימה טרחנית.
בקשר לYII ןלאקסל, לא יודע מה יש שמה אבל זה המחיר של לעבוד עם כמה זירות (תיתן מידי פעם צאנס לנוד לקחת גם בממשק :), יש מצב שתהנה אפילו שזה לא מגיע מוכן כמו הYII). -
@dovid
לא מכחיש, אולי אני צריך קצת ללמוד את הקטע שבו אני קצת חושש.
הרי תהליך הנוד הוא תהליך שלפעמים מבוצע עליו ריענון, הן בגלל שינויים, והן ע"י הפעלה מחדש או כל סיבה אחרת שיכולה לגרום לתהליך לקרוס ולאתחל את עצמו מחדש.
לכן נתונים אמיתיים אני חייב לשמור בד"ב ולא רק בתהליך, אך היות שאין צורך לבדוק כל פעם מחדש כי התהליך כשהוא רץ הוא רץ ללא הפסקה בשונה מPHP שהייתי חייב הכל הכל הכל לבדוק בכל קריאה, לכן אני כן יכול להסתמך עליו.
אך אני כל פעם מכין את עצמי לקראת אפשרות של ניקוי הנתונים בתהליך שאז אני שולף מהד"ב.
אשמח אם מישהו יוכל לתת לי יותר הבנה וכלים להתמודד בקטע זה.
ואגב לגבי@dovid אמר בעדכון תהליך ה NODEJS לאחר ביצוע עריכה בד"ב MySQL:
היחיד שצריך לעדכן את הDB זה הנוד
אני לא יגיע לזה כ"כ מהר כי כבר יש לי את הממשק עוד לפני שלמדתי nodejs והוא עובד כמו שצריך אז לא כ"כ מהר אגיע להחליף אותו. (ב"ה יש מספיק עבודה..)
-
@חוקר אמר בעדכון תהליך ה NODEJS לאחר ביצוע עריכה בד"ב MySQL:
@dovid
הרי תהליך הנוד הוא תהליך שלפעמים מבוצע עליו ריענון, הן בגלל שינויים, והן ע"י הפעלה מחדש או כל סיבה אחרת שיכולה לגרום לתהליך לקרוס ולאתחל את עצמו מחדש.
לכן נתונים אמיתיים אני חייב לשמור בד"ב ולא רק בתהליך, אך היות שאין צורך לבדוק כל פעם מחדש כי התהליך כשהוא רץ הוא רץ ללא הפסקה בשונה מPHP שהייתי חייב הכל הכל הכל לבדוק בכל קריאה, לכן אני כן יכול להסתמך עליו.
אך אני כל פעם מכין את עצמי לקראת אפשרות של ניקוי הנתונים בתהליך שאז אני שולף מהד"ב.
אשמח אם מישהו יוכל לתת לי יותר הבנה וכלים להתמודד בקטע זה.יש לך כאילו "ערפל" לא כ"כ מובן על נוד. נכון בPHP הכל מתחיל בכל קריאה, אבל בדיוק באותה מידת ברירות צריכה להיות לך הנוד - יש טעינה של האפליקציה, ויש את רגע הקריאה.
אם השאלה היא איך מרעננים מידע במשתנים רבים, הכי טוב זה להחזיק את כולם במשתנה אחד ראשי (אובייקט), ו"להחליף" אותו כשהוא מוכן (ע"י הצבה של החדש).
עוד משהו לשוני (סליחה על הטרחנות): הסיבה ששומרים בDB היא לא בגלל ה"ריענון/קריסה/לא סומכים" שמשמע מהלשון הזאת שזה באג שבדרך להיפתר. כשאתה שואל מישהו שעובד על קובץ וורד למה הוא שומר אותו בדיסק הוא לא יענה לך שמא ייכבה המחשב (אף שזה בדיוק התשובה) אלא כי פשוט יש צורך לשמור את הנתונים ולא רק להחזיק אותם באויר על הRAM הנדיף (אימאלה...).אני לא יגיע לזה כ"כ מהר כי כבר יש לי את הממשק עוד לפני שלמדתי nodejs והוא עובד כמו שצריך אז לא כ"כ מהר אגיע להחליף אותו. (ב"ה יש מספיק עבודה..)
אני לא מחלק פטורים מעבודה...
אתה צריך להחליט מתי נכון בחינתך לעשות את הצעד הזה, אבל עניתי לך מה שורת הדין בתכנון.
במצב הקיים אתה יודע כבר מה התשובה, אתה סה"כ צריך לשלוח נוטיפקציה שתהווה טריגר לטעינה כוללת. -
@dovid אכן את זה כבר למדתי במשך הזמן לאחוז את הכל במשתנה כללי לכל אפליקציה משתנה עצמאי, שמכיל את הכל.
השאלה אם כדאי לרענן בעת הצורך את כל המשתנה או רק אזורים, או רק תתי אזורים.
בא נגיד עשיתי שינוי בטבלת אנשי קשר, האם לרענן את כל האובייקט, או רק את תת האובייקט שמכיל את אנשי הקשר, או רק את האנשי קשר של הפמעיל הספיציפי [במערכות בהם יש מספר מפעילים לתהליך אחד (כגון מצינגים שאנשי הקשר מפוצלים לפי מצינגים)].
השאלה עד כמה כדאי לחסוך משאבים, וסתם האם זה יותר מסודר לעבוד על כל דבר בנפרד במקום ריענון להכל מחדש. -
@חוקר ככלל הייתי קובע שעדכון כללי בד"כ נקי יותר ולא משמעותי בביצועים. זה מאוד תלוי מה המבנה, לפי מה שאתה מתאר נשמע שהמיפוי בין מבנה הנתונים במסד למבנה שזה מוחזק במשתנה הוא לא מובן מאליו - כלומר הוא די שרירותי ו"אנושי" (סביר למדי שבצדק).
במקרה כזה אז כמובן שעבודה טרחנית של עדכון נקודתי טיפלה משפרת בביצועים בהתם לרמה אבל מאוד מבלגנת ומכבידה. -
@dovid אמר בעדכון תהליך ה NODEJS לאחר ביצוע עריכה בד"ב MySQL:
@חוקר ככלל הייתי קובע שעדכון כללי בד"כ נקי יותר ולא משמעותי בביצועים. זה מאוד תלוי מה המבנה, לפי מה שאתה מתאר נשמע שהמיפוי בין מבנה הנתונים במסד למבנה שזה מוחזק במשתנה הוא לא מובן מאליו - כלומר הוא די שרירותי ו"אנושי" (סביר למדי שבצדק).
במקרה כזה אז כמובן שעבודה טרחנית של עדכון נקודתי טיפלה משפרת בביצועים בהתם לרמה אבל מאוד מבלגנת ומכבידה.כעת יש לי מערכת עם טבלה של מעל 10K רשומות של אנשי קשר מפוצלים לפי פרוייקט כל פרוייקט כ 2K.
המספרים אמורים לגדול בכל מפעיל נוסף, גם בזה היית אומר שבכל ריענון לרענן תמיד הכל או כן לחשוש למשאבים מיותרים, ולרענן רק לפרוייקט שבוצע שינוי? -
@חוקר לא חלמתי על כזה סדר גודל. חשבתי מדובר בכמה פרטים קטנים.
אני לא חושב שזה אידאלי להשתמש בנוד כקאש לכאלה סדרי גודל, לכאורה זה כבר פלישה לתחום המסדי נתונים.
כלומר צריך לבדוק בכלל אם mysql מתאים, ייתכן שכדאי לך להחליף או להחזיק במקביל מסד מסוג אחר, שמבוסס יותר על זיכרון. -
@dovid אסביר למה זה כך.
אני כידוע עובד עם ימות המשיח, וכבר נידון כאן כמה פעמים בפורום על הקושי בזה שבכל קריאה הכל מתחיל מהתחלה.
נניח מערכת שאני רוצה לבדוק האם מספר הטלפון המחייג מופיע בטבלת המנויים, אני יכול לבצע בדיקה ישירות מול הד"ב בתחילת השיחה האם הוא מופיע בטבלה, ואז בעצם בכל שלב בשיחה הבדיקה תבוצע מחדש, לכן באתי מכיון הפוך אני מוריד את כל הטבלה בבת אחת לשרת, (מרענן אותה מידי פעם), ואז בכל שלב בשיחה אני בכלל לא בודק מול הד"ב אלא רק מול השרת נוד.
מה עדיף?
