כשמטמון גדל בכיוון הלא נכון

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

הם קיימים כדי שמסלול הספירה לא יצטרך לשאול את מסד הנתונים ארבע שאלות שכמעט תמיד התשובה להן היא “לא”. האם המונה הזה מחריג את הביקורים העצמיים של בעליו? עוקב אחר לחיצות יוצאות? עוקב אחר נתיבים באתר? טוען את עצמו מחדש? ביותר מ־99% מהמונים כל תשובה היא לא, וזול יותר לבדוק קובץ שמחזיק את קומץ המספרים שבהם התשובה כן מאשר ארבע שאילתות עם אינדקס.

זה זול יותר. וזה גם סוג של זול שיכול להתהפך.

מה נמדד

אותה שאלה — “האם המונה הזה ברשימה?” — שנשאלה בשתי דרכים, בשישה גדלים של רשימה. דרך הקובץ: לקרוא אותו, לפענח את ה־JSON ולחפש את המספר. דרך מסד הנתונים: פקודה מוכנה אחת מול עמודה עם אינדקס. אלפיים חזרות לכל אחת, חמישה סבבים, ונלקח החציון.

בגודל של היום הקובץ מנצח פי שמונה: 0.0202 אלפיות השנייה מול 0.1630. באלף מספרים הם שווים. בעשרת אלפים הקובץ עולה פי שנים עשר, ובמאה אלף הוא עולה פי 135, כי אז מדובר ב־578 קילובתים שצריך לקרוא ולנתח בכל צפייה.

הקו של מסד הנתונים אינו זז. 0.16 אלפיות השנייה בשתי שורות ו־0.16 אלפיות השנייה במאה אלף: לזה נועד אינדקס, וקל לשכוח כמה עבודה מסתתרת מאחורי המראה המשעמם של הקו הזה.

החלק הלא נוח

נקודת החצייה היא אי שם בין 100 ל־1,000 מספרים. בשירות הזה יש 2,218 מונים שהיו פעילים בשלושים הימים האחרונים.

לכן אילו תכונת ההחרגה הייתה מצליחה — אילו כל מי שיש לו מונה היה מפעיל “לא לספור את הביקורים העצמיים שלי” — הקובץ היה מחזיק 2,218 מספרים, שוקל 11 קילובתים ועולה 0.43 אלפיות השנייה לצפייה במקום 0.02. ב־18,423 הצפיות של אתמול, אלה שמונה שניות עבודה ביום כדי להימנע משאילתה שהייתה אורכת שלוש.

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

למה הוא עדיין שם

כי הוא נכון היום, ו“נכון היום” הוא נימוק לגיטימי למשהו, כל עוד מישהו כתב מתי זה מפסיק להיות נכון.

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

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

הדפוס הכללי

זה אינו טיעון נגד שמירת מטמון בקובץ. זה טיעון בעד הידיעה באיזה כיוון מטמון גדל.

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

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