מניעת race condition ב-DB
-
@dovid אמר במניעת race condition ב-DB:
סתם ככה אשמח לדעת מה הרקע של הצורך.
אין באמת צורך כל כך חשוב, אבל אני שמח לדעת את הפתרון בלי קשר.
מדובר בטבלה של כסף שנכנס לארגון (תרומות), לצרכי תצוגה אנחנו רוצים לתת לכל charge מספר ידידותי במקום לזהות אותו על ידי ה-PK. לצורך תצוגה אנחנו מעדיפים שהמספרים של ה-charges של כל ארגון יהיו עוקפים. אנחנו רוצים גם שהמספרים יהיו קבועים, כלומר גם אם נמחק תרומה מאיזה סיבה זה לא אמור לשנות את כל המספרים.
האם זה סיבה מספקת להכריח נעילה על ה-DB לכל הכנסת תרומה? אני לא יודע... נחיה ונראה... -
פתרון ברמת האפליקציה:
אתה צריך כנראה לעשות שרת בעל מופע אחד שיהיה אחראי להוציא קבלות/מספרי תרומות.
תהיה רשימה שתחזיק את כל הבקשות, ובאמצעות לולאה תיקח כל פעם בקשה אחת ותטפל בה.
כך לא יהיו לעולם התנגשויות. (וכמובן תשתמש בהצעה של תת שאילתה).
אני הייתי מיישם את זה ככה.אפשר להקצות את כל השרת רק לזה, אם אתה רוצה למנוע מצבים של עומס (כי זה תהליך אחד שעושה את כל הקבלות).
שאר הפתרונות שיש כאן הם ברמת הDB, ומשתנים ממנוע אחד למשנהו ואפילו מגירסה לגירסה.
-
פתרון ברמת האפליקציה:
אתה צריך כנראה לעשות שרת בעל מופע אחד שיהיה אחראי להוציא קבלות/מספרי תרומות.
תהיה רשימה שתחזיק את כל הבקשות, ובאמצעות לולאה תיקח כל פעם בקשה אחת ותטפל בה.
כך לא יהיו לעולם התנגשויות. (וכמובן תשתמש בהצעה של תת שאילתה).
אני הייתי מיישם את זה ככה.אפשר להקצות את כל השרת רק לזה, אם אתה רוצה למנוע מצבים של עומס (כי זה תהליך אחד שעושה את כל הקבלות).
שאר הפתרונות שיש כאן הם ברמת הDB, ומשתנים ממנוע אחד למשנהו ואפילו מגירסה לגירסה.
@מנצפך תודה, הפתרון שלך דומה מאוד לפתרון 3 שהצעתי, רק שאני הצעתי להשתמש בשירות מובנה של ה-DB ואתה מציע לממש את זה בעצמי.
אני רואה יתרונות במימוש עצמי של השירות, אבל לעומת זה אני רואה חסרונות גם כן, ובפרט בפרוייקט בגודל זה (כלומר קטן מאוד כרגע) לא נראה לי ששוה לי ההשקעה.
לעצם הפתרון, אחרי מחשבה אני תופס שלכאורה זה הפתרון הכי זול (מבחינת נעילות) שקיים. הנעילה תהיה רק על הפעולה שחייבת נעילה.
-
@מנצפך תודה, הפתרון שלך דומה מאוד לפתרון 3 שהצעתי, רק שאני הצעתי להשתמש בשירות מובנה של ה-DB ואתה מציע לממש את זה בעצמי.
אני רואה יתרונות במימוש עצמי של השירות, אבל לעומת זה אני רואה חסרונות גם כן, ובפרט בפרוייקט בגודל זה (כלומר קטן מאוד כרגע) לא נראה לי ששוה לי ההשקעה.
לעצם הפתרון, אחרי מחשבה אני תופס שלכאורה זה הפתרון הכי זול (מבחינת נעילות) שקיים. הנעילה תהיה רק על הפעולה שחייבת נעילה.
-
@yossiz אמר במניעת race condition ב-DB:
בל לעומת זה אני רואה חסרונות גם כן, ובפרט בפרוייקט בגודל זה (כלומר קטן מאוד כרגע) לא נראה לי ששוה לי ההשקעה.
איזה חסרונות קיימים בנעילה בקוד?
(באיזה שפה הקוד כתוב?) -
@yossiz אמר במניעת race condition ב-DB:
בל לעומת זה אני רואה חסרונות גם כן, ובפרט בפרוייקט בגודל זה (כלומר קטן מאוד כרגע) לא נראה לי ששוה לי ההשקעה.
איזה חסרונות קיימים בנעילה בקוד?
(באיזה שפה הקוד כתוב?)@nigun אני לא בטוח שיש שום חסרונות בנעילה בקוד. (עריכה: עיין מה שכתב דוד למעלה)
זה nodejs.מה ש@מנצפך מציע הוא (אולי הרבה) יותר זול מנעילה בקוד.
אבל מצד שני יש חסרון שכאשר מדובר בעשרות אלפי ארגונים וצריך לשמור מספר לכל אחד זה יתפוס משאבים. וגם, צריך לכתוב את זה בצורה נכונה שהמספרים תמיד יהיו מסונכרנים עם מה שיש ב-DB. (אני לא אומר שזה קשה, רק זה עוד חחתיכת קוד שצריך לוודא שהוא פועל נכון).
אגב, @מנצפך חושב מאוד גדול... מכיון שכרגע הגישה ל-DB אצלי הוא רק על ידי תהליך אחד אין צורך בשרת נפרד שיעשה את זה, אלא אפשר לעשות את זה בתוך התהליך. -
@nigun בנעילה בקוד יש שתי בעיות:
א. בתחזוקת הקוד לעולם צריך לזכור את האחריות הזאת
ב. צריך לוודא שאין מצב של ריצה מקבילה של מופעים, אסור שהתוכנה תרוץ פעמיים. -
@dovid אמר במניעת race condition ב-DB:
ב. צריך לוודא שאין מצב של ריצה מקבילה של מופעים, אסור שהתוכנה תרוץ פעמיים.
מה הבעיה? ריצה מקבילה של מספר מופעים באותו אפליקציה או ריצה של מספר אפליקציות?
-
@nigun הנעילה מגינה מפני מספר מופעים באותו תהליך, אבל אם יש מספר מופעים של התהליך לא תעזור הנעילה.
אבל זה לא לגמרי נכון כי זה תלוי איך עושים את הנעילה. -
@yossiz
לא יודע איך עובד נעילה בנוד
אבל לכאורה כל עוד לכל התהליכים יש גישה לאותו מרחב בזיכרון
אז הנעילה עובדת על כולם
אולי בנוד זה עובד אחרת (אולי לכן יש ישום של נעילה מתוך רדיס)