ב-2010, FourSquare הפסיקה לעבוד 11 שעות. לא היה DDoS, לא היה bug - MongoDB, ה-database שלהם, הפסיקה להגיב. הבעיה: growing data set גרם ל-MongoDB לעשות "index thrashing" - ה-indexes כבר לא נכנסו ל-RAM ועשו disk I/O כל הזמן. הם לא תכננו sharding מראש. הם חזרו לעבוד אחרי 11 שעות down, ומיד אחרי - מיגרו ל-sharded setup שנמנע בדיוק מהבעיה הזו.
Database Sharding הוא הפתרון כש-database אחד לא מסוגל להכיל את כל ה-data. במקום table אחת גדולה, מחלקים את ה-data בין כמה databases ("shards"), כל אחת רצה על server נפרד. יחד הם מרכיבים את ה-dataset השלם.
ב-2012, Pinterest גדלה מ-0 ל-48 מיליון users תוך שנתיים. הם מיגרו ל-sharded MySQL בתוך כמה חודשים תחת load - אחת מה-migrations הכי documented באינטרנט. הם חילקו את ה-data של pins לפי user_id, כך שכל query על pins של user מסוים נוחת על shard אחד בלבד. ה-migration כלל כתיבת sharding library ב-Python, ו-backfill של data בלי downtime - פרויקט של חודשים שהם documenting ב-engineering blog שלהם לפרטי פרטים.
הסיפור של FourSquare הוא textbook case של מה שקורה כשgrowth מפתיע infrastructure. ב-2010, FourSquare הייתה ב-hypergrowth - עברה מ-1 מיליון users ל-10 מיליון בפחות משנה. ה-MongoDB instance שרץ על server יחיד לא יכול היה לטעון את כל ה-working set ל-RAM. בכל query, ה-database היה צריך לעשות disk seek כדי לטעון index pages - ו-disk seeks אקראיים על HDD לוקחים 10ms+. כשה-database בנקודת קריסה, query שהיה לוקחת 2ms ב-RAM לוקח 500ms מ-disk. Timeout cascade. הכל קרס. 11 שעות downtime.
מה שPinterest עשה נכון: הם לא עברו לsharding בלחץ - הם תכננו אותו כשראו ב-metrics שהם מתקרבים ל-limit. ב-log-post שלהם מ-2012, הם מתארים שתי בחירות שעשו לפני migration: להגדיר shard key שיהיה stable (user_id שלא ישתנה), ולכתוב sharding library שתוכל לעבוד במקביל על ה-old schema וה-new schema בזמן migration. כל row עבר מ-migration ב-thread נפרד, בעוד שה-production traffic ממשיך לזרום. מיגרציה תחת load זה art form - ו-Pinterest עשתה אותו נכון.