מקודד לשוא|וידויים של מוח מקוון

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

Sharding (בתרגום מילולי שבירה לרסיסים) היא שיטה של חלוקת אופקית במאגר מידע או מנוע חיפוש.

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

במה שונה גישת החלוקה מגישות קימות ?

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

בעקבות המחקר והעבודה של סונדרס וצוותו הוציאו יאהו כלי בדיקות בשם YSLOW כתוסף דפדפן של פיירפוקס. מאז סונדרס עבר לגוגל וגם הם הוציאו כלי דומה בשם PAGE SPEED במהלך שמזכיר קצת את מיקרוסופט (ולא החלקים הטובים שלה)

בהתאם לממצאים של סונדרס וצוותו גובשו הכללים הבאים:

1. צמצום כמות קריאות HTTP ,זאת על ידי שימוש בטכניקות כמו CSS SPRITES ואיחוד קבצי CSS ו JS .

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

3. שימוש נכון בתאריך תפוגה (expiration header) לכל משאב (לא רק לתמונות), במחקר שערכו גילו כי באתרים שונים הרבה משאבים קבועים (עד כ 70%) יכולים להיות עם תאריך תפוגה ארוך יותר. מעבר לתאריכי תפוגה ארוכים מחייב התייחסות ארכיטקטונית לעדכון גרסת משאב מסוים. לדוגמה – תיקון בקוד האתר דורש שינוי קוד ג'אוה סקריפט, מכיוון שאנו השתמשנו בתאריכי תפוגה ארוכים התיקון אף פעם (או עוד הרבה מאוד זמן) יגיע ללקוחות ותיקים הפתרון הוא חתימת גרסאות בשם הקובץ או כתובתו (URL)

4. שימוש ב GZIP (נכתב כחלק מפרוטוקול HTTP) נתמך ברוב הדפדפנים וחוסך כ 70% מהתעבורה אם משתמשים בו על כל המשאבים הטקסטואליים. בחלק גדול מהמקרים GZIP מופעל רק על קבצי HTML ומזניח שלא לצורך משאבי טקסט אחרים כגון CSS ו JS.

5. להעביר את הקישורים לקבציי CSS לראש העמוד. באקספלורר הדף לא מוצג עד שכל קבצי ה CSS נטענו ותוכנם נותח. בפירפוקס התצוגה תתרענן עם פענוח של CSS חדש.

6. להעביר את הקישורים לקבציי JS לתחתית העמוד, טעינת קובץ ג'אוה סקריפט חוסמת כל הורדה אחרת (בכל מצב אחר הדפדפן מבצע הורדות מקביליות) וחוסמת את רענון תצוגת המסך.

7. להימנע מביטויי CSS (ממשק שנתמך רק באקספלורר (גרסה 5 ומעלה) ומאפשר הפעלת ג'אוה סקריפט מתוך CSS) ביטויי ה CSS מחושבים בצורה מחזורית בכמויות מאוד גדולות ומאטים את פעילות הדפדפן.

8. שימוש בסקריפטים חיצוניים (שימוש בתגי SCRIPT ו LINK לטעינת משאבים חיצוניים) ובכך אחזור משאבים והאצת הטעינה על ידי שימוש במטמון הדפדפן.

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

10. שימוש בכלי ניקוי קוד (minification)  להורדת הערות רווחים וקיצור קוד.

11. הימנעות מ REDIRECT אם בקריאות שרת כגון 301 ו 302 או שימוש בקוד HTML META או על ידי ג'אוה סקירפט ככל מקרה תהיה טעינה כפולה הראשונה של הדף המפנה ורק לאחר מכן כתובת היעד.

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

13. הגדרות ETAGS , תגיות יישות (ETags) הן מנגנון אשר שרתי אינטרנט ודפדפנים משתמשים כדי לקבוע אם רכיב בזיכרון המטמון של הדפדפן תואם אחד בשרת המקור (ישות יכולה להיות תמונות, סקריפטים, CSS, וכו ') .התגיות נוספו לספק מנגנון אימות גמיש יותר מאשר תאריך התפוגה.

14. הכנסת AJAX לזיכרון המטמון, בהרבה מקרים הקריאות הינם פרסונליות והאינסטינקט הראשוני הוא לא לשמור את המידע במטמון. אך למרות שהמידע אישי לא תמיד הוא משתנה לעתים קרובות. מומלץ להשתמש באותה טכניקה שמתוארת בסעיף 3.

יש כמה אפשרויות להתמודדות עם בעיות שמוצגות על ידי CAP.  הפשוטות הן:

ויתור על סבילות חלוקה
אם אתה רוצה לרוץ בלי מחיצות אתה צריך לעצור אותן מלקרות. דרך אחת לעשות זאת היא לשים הכל (כל מה שקשור ליחידה אחת או טרנזאקציה) במחשב אחד, או ביחידה אטומית אחת כמו מתלה (rack). זה לא  100% בטוח כי עדיין יכולים להופיע כשלים, אבל יש  פחות סיכוי לקבל תופעות לוואי שנובעות מחלוקה. לשיטה זו יש מגבלת גדילה משמעותיות.

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

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

קפיצת בסיס (BASE Jump)
הרעיון של להיות עקבי בסופו של דבר נתמך באמצעות מה שנקרא BASE ו(Basically Available, Soft-state, Eventually consistent) ראשי התיבות קצת מאולצים אבל עדיין שימושים.

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

משפט CAP מתאר מערכת בעלת עם מבנה נתונים או מצב זיכרון (state) העונים על המאפיינים הבאים:

1. עקביות (Consistency) – כל לקוח של המערכת מקבל את אותם נתונים גם אם התבצעו עדכונים במקביל.
2. זמינות (Availability) – המערכת משרתת את כל בקשה של לקוחותיה.
3. סבילות חלוקה (Partition tolarance) – ניתן לפצל את מבנה הנתונים או מצב הזיכרון על פני מספר שרתים, או במילים אחרות לפצל את השירות על פני כמה צמתים ברשת.

הטענה היא שבתכנון ובניית מערכת ניתן לבחור רק שני מאפיינים מהשלושה .

להלן ההוכחה  (מקור ג'וליאן בראון)

התרשים מראה מערכת מחולקת אשר מכילה שני צמתים ברשת , N1 ו N2. שניהם חולקים פיסת מידע V (כמה עותקים לספר במלאי), עם הערך V0. על הצומת N1 רץ אלגוריתם שנקרא A ואנו יוצאים מנקודת הנחה שהוא צפוי, חסר באגים, ומהימן.על הצומת N2 רץ אלגוריתם דומה שנקרא B . בניסוי A כותב ערכים חדשים של V ו-B קורא ערכים של V.

התמונה למעלה מתארת תרחיש רגיל (המערכת עובדת כשורה) ,והפעולות הבאות יקרו:
1. Aכותב ערך חדש ל V (נקרא לו V1)
2. הודעה M עוברת מ N1 ל N2 ומעדכנת את העותק של V
3. כל קריאה של B תחזיר את הערך החדש V1

התמונה הזו מתארת טעות, הודעת העדכון (M) לא עברה. מכאן שבשלב 3 קריאה ל B תחזיר ערך לא עדכני.

קריאה ל A ו B יחזירו תוצאות שונות אני מקווה שכאן הבעיה כבר מובנת, נגדיל את קנה המידה לכמה מאות פעולות וזה הופך לבעיה גדולה. אם M הוא הודעה אסינכרונית אז לN1 אין דרך לדעת אם N2 קיבל את ההודעה. אפילו עם מסירה מובטחת של M , אין ל N1 דרך לדעת אם הודעה מתעכבת או שמשהו כשל בN2. הפיכת M לסינכרונית לא עוזרת כי התייחסות לסנכרון כפעולה אטומית יגרום לעקבת (latency בהעדר תרגום מתאים) וזה מפר את עקרון הזמינות. ההוכחה, באמצעות וריאציה,מראה כי אפילו במודל סינכרוני חלקי לא ניתן להבטיח אטומיות.

אז מה CAP אומר לנו ? שאם אנחנו רוצים ש A ו-B יהיו בעלי זמינות גבוהה (כלומר לעבוד עם עקבת מינימלית) ואנחנו רוצים שהצמתים N1 עד *N (כאשר * יכול להיות מאות או אפילו אלפים) יהיו בעלי סבילות חלוקה (שידעו להתמודד עם אבדון הודעות, הודעות שלא נשלחו, תקלות חומרה ותקלות תוכנה) אז לפעמים אנחנו הולכים לקבל מקרים שבהם הצמתים לא מסונכרנים וצומת אחד חושב כי V הוא V0 (עותק של ספר אחד) וצמתים אחרים יחשבו כי V הוא V1 (לא אותו עותק).