ABA


"האם mysql היא thread safe מהבחינה שאפשר לשלוף ולעדכן?"
גירסת הדפסה        
קבוצות דיון בניית אתרים נושא #15692 מנהל    סגן המנהל    מפקח   Winner    צל"ש   מומחה  
אשכול מספר 15692
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   20:41   09.05.10   
אל הפורום  
  האם mysql היא thread safe מהבחינה שאפשר לשלוף ולעדכן?  
 
ערכתי לאחרונה בתאריך 09.05.10 בשעה 20:45 בברכה, Deuce
 
לא מצאתי רפרנס מספיק טוב באינטרנט לשאלה הבאה:
האם אני יכול להיות בטוח שלא יווצר מצב שאני אעדכן את הטבלה ובאותו זמן מישהו ישלוף ממנה מידע? מבדיקה שערכתי בעצמי, נראה שלא (מבדיקה שערכתי בעצמי) - אבל אני רוצה לוודא.






                                שתף        
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

  האשכול     מחבר     תאריך כתיבה     מספר  
  לא יודע תשובה טכנית code_blue  10.05.10 14:47 1
     מכתב Deuce  10.05.10 15:19 2
         אני לא מבין איך זה רלוונטי ליל קיץ 10.05.10 15:56 3
             זה סופר רלוונטי. Deuce  11.05.10 00:27 5
                 המידע בן כה לא יהיה רלוונטי ליל קיץ 11.05.10 01:43 7
                     אני אמקד עוד קצת את השאלה. Deuce  11.05.10 01:57 8
         בפעולת SELECT עד כמה שאני יודע יש נעילת רשומות. Ice Cold  10.05.10 16:56 4
             אם אני מבין נכון, Deuce  11.05.10 00:36 6
                 אוקיי, מצאתי :) Ice Cold  11.05.10 10:32 9
                     מעולה, המון תודה ! Deuce  11.05.10 18:04 10

       
code_blue  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 5.7.06
21280 הודעות, 7 פידבק
   14:47   10.05.10   
אל הפורום  
  1. לא יודע תשובה טכנית  
בתגובה להודעה מספר 0
 
   אבל לדעתי בזמן עבודה של המסד נתונים יכול להווצר מצב שמי שביקש את העדכון באותו חלקיק שנייה ומישהו עדכן , אז התוצאה לא תיהיה המעודכנת

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

גם מסדי נתונים יוצרים מעין CACHE בזכרון של המחשב


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   15:19   10.05.10   
אל הפורום  
  2. מכתב  
בתגובה להודעה מספר 1
 
אין לי בעייה אם פיספסתי את המידע המעודכן בחצי שנייה או משהו כזה, אלא האם ממש באותו זמן יכולה להתרחש שליפה ועדכון, ואז העדכון יהיה פגום.

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

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

בכל מקרה תודה






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ליל קיץ לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 14.2.10
10048 הודעות, 7 פידבק
   15:56   10.05.10   
אל הפורום  
  3. אני לא מבין איך זה רלוונטי  
בתגובה להודעה מספר 2
 
   בוא ונניח ואתה צודק, והדטאבייס קודם כל מבצע את כל ה SELECT ורק אז מבצע את העידכון .

המידע שתקבל ב SELECT עדיין לא יהיה עדכני (תא אחד ישן).


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   00:27   11.05.10   
אל הפורום  
  5. זה סופר רלוונטי.  
בתגובה להודעה מספר 3
 
קודם כל יש עניין של Fairness שבד"כ מתקיים, ז"א אם אני אבקש משמעותית לפני אז אני אקבל את התוצאה לפני. חוץ מזה, אתה לא יודע מה המטרה שלי.

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

הדרישה שאתה קודם כל צריך לדרוש מהתוכנה שלך זה שלא יהיה מצבים כאלה.






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ליל קיץ לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 14.2.10
10048 הודעות, 7 פידבק
   01:43   11.05.10   
אל הפורום  
  7. המידע בן כה לא יהיה רלוונטי  
בתגובה להודעה מספר 5
 
   3 מצבים קיימים -

1. בוצע עידכון לפני שליפה והDB במצב סטטי - מן הסתם המידע עדכני.

2. מתבצע עידכון לאחר השליפה (לאחר קבלת הנתונים) - המידע לא עדכני.

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

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   01:57   11.05.10   
אל הפורום  
  8. אני אמקד עוד קצת את השאלה.  
בתגובה להודעה מספר 7
 
נניח יש לי שורה שיש בה 8 שדות.

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

במידה וא' וב' לא מתקיימים לי, זה מספיק טוב לי ולפי מה שבדקתי, כך המצב.






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Ice Cold  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 3.8.02
28041 הודעות, 19 פידבק
   16:56   10.05.10   
אל הפורום  
  4. בפעולת SELECT עד כמה שאני יודע יש נעילת רשומות.  
בתגובה להודעה מספר 2
 
ואז ב-UPDATE אפשר להשתמש ב-DELAYED INSERT כי לחכות שהרשומ התכבר לא תהיה נעולה...

מתוך האתר של mysql:


When a client uses INSERT DELAYED, it gets an okay from the server at once, and the row is queued to be inserted when the table is not in use by any other thread.

לינק:

http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   00:36   11.05.10   
אל הפורום  
  6. אם אני מבין נכון,  
בתגובה להודעה מספר 4
 
המשמעות של DELAYED INSERT היא פר שורה כלשהי, כלומר עוד בהתחלה רשום שזה למצבים בהם קליינט לא רוצה לחכות לפעולת INSERT להסתיים.

לצרכים שלי אני פשוט צריך לוודא שלא יהיה מצב שהפעולות תתבצענה בו זמנית. לא איכפת לי לחכות בשקט לסיום פעולת ה-INSERT במידה והיא מבוצעת - זה מה שאני רוצה למעשה שיקרה. לא איכפת לי להתחשב בשורות ספציפיות או משהו כזה.

אני חושב שזאת הנחה שסביר להניח (בהנתן אופי ה-DB) וגם הרצתי בדיקה דיי חותכת. אבל בכל זאת, אעדיף לראות מקור רשמי.







                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Ice Cold  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 3.8.02
28041 הודעות, 19 פידבק
   10:32   11.05.10   
אל הפורום  
  9. אוקיי, מצאתי :)  
בתגובה להודעה מספר 6
 
http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html

הם מסבירים שם על כל ה-LOCKS ורשום בפירוש שהם נותנים עדיפות ל-WRITE מאשר ל-READ. ז"א שאם יש כמה INSERT או UPDATE ב-QUEUE, וגם כמה READ, קודם העדכונים מתבצעים ואז המידע נשלף, מן הסתם הכי מעודכן.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   18:04   11.05.10   
אל הפורום  
  10. מעולה, המון תודה !  
בתגובה להודעה מספר 9
 
בידיוק מה שחיפשתי






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

תגובה מהירה  למכתב מספר: 
 
___________________________________________________________________

___________________________________________________________________
למנהלים:  נעל | תייק בארכיון | מחק | העבר לפורום אחר | מחק תגובות | עגן אשכול
       



© כל הזכויות שמורות ל-רוטר.נט בע"מ rotter.net