Database Sharding - Horizontal Partitioning
Instagram, 2013. אחד מהengineers שם, Mike Krieger, תיאר את הבעיה: "PostgreSQL Single Primary הגיע לcapacity. לא בwrite throughput, אלא ב-dataset size - פשוט יותר מדי photos ב-single disk." הפתרון: Sharding לפי user_id. כל shard מחזיק subset של users. query על user הולך לshard שלו.
Pinterest ב-2012 עשתה אותו מהלך - Sharded MySQL עם virtual shards. כל "virtual shard" ממוסמף לshard פיזי. הוספת shards חדשים = remapping של virtual shards, לא migration של data פיזי.
Sharding הוא הכלי שמגיע אחרי שניסיתם הכל אחר: connection pooling, read replicas, query optimization, better hardware. הוא מורכב, מביא limitations קשות, ואת רוב הבעיות שהוא פותר PostgreSQL יחיד עם vertical scaling ו-read replicas יכול לפתור עד scale גדול מאוד.
כדי להבין מתי sharding נחוץ, צריך להבין מה הlimits של single PostgreSQL instance. ב-2024, high-end server עם 96 cores, 2TB RAM, ו-NVMe SSDs יכול להריץ PostgreSQL ב-100,000+ writes לשנייה ו-1,000,000+ reads לשנייה. כשמדובר ב-dataset size - כמה TB ניתן לנהל? PostgreSQL מסוגל לנהל tens of TB על single server. כלומר: רוב הsector של סטארטאפים ל-unicorn לא יצטרך sharding. Uber, Spotify, ו-Netflix הגיעו לsingle-server limits כי הם הגיעו לscale שאין הרבה חברות שם.
הbenchmark הפרקטי: אם PostgreSQL primary עם הbest hardware שאפשר לקנות, עם read replicas ל-read scaling, עם query optimization ו-connection pooling - עדיין hit limits: אז שארדינג. אם לא - אל תוסיפו complexity.
כמה שמאפשר לvirtualize את הconcept: כשחברה מתחילה, ה-database הוא VM קטן ב-cloud עם 4 cores ו-8GB RAM. זה מספיק לhundreds of users. אחרי funding, upgrade ל-16 cores, 64GB RAM - זה מספיק ל-tens of thousands. אחרי Series A, 96 cores, 1TB RAM, NVMe RAID - מספיק למיליונים. רק אחרי שה-vertical scaling עצמה hit limits - שארדינג. רוב הstartups לא יגיעו לstep האחרון, אבל מתכנני מוצר צריכים לדעת שהפתרון קיים לstep הזה.