המשפט הזה מהסיפור על זנדסק תפס את תשומת לבי:

Eventually, they looked to Bloom Filters, further combined with Count-Min Sketch data structures, which together offered an effective way of supporting multi-field filter queries.

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

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

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