Sharding במסדי נתונים מוסבר¶
בשלב מסוים בחיים של מוצר מצליח, מסד הנתונים שלכם פשוט נגמר. לא נגמר במובן שהוא מתמלא לגמרי, אלא שהוא מגיע לגבול שבו שרת אחד, כמה שחזק שיהיה, לא מסוגל לשרת את כמות הבקשות והנתונים שמגיעים אליו. אחת התשובות הנפוצות לבעיה הזאת נקראת Sharding, וזו גם אחת ההחלטות הארכיטקטוניות שהכי קל לפשל בהן.
מה זה בעצם Sharding¶
Sharding, בעברית לפעמים "פיצול אופקי", הוא פיצול מסד הנתונים שלכם למספר חלקים נפרדים, שנקראים shards, כשכל אחד מהם מכיל רק חלק מהנתונים ורץ על שרת נפרד משלו. לדוגמה, אם יש לכם מיליון משתמשים, אפשר לפצל כך שמשתמשים עם ID בין 1 ל-500,000 יושבים על שרת אחד, והשאר על שרת שני. כל שרת מכיל טבלה מלאה עם המבנה המלא, אבל רק חלק מהשורות.
זה שונה מהותית מרפליקציה, שבה כל שרת מכיל עותק מלא של כל הנתונים כדי לחלק את עומס הקריאה. ב-sharding כל שרת מכיל רק פלח מהנתונים, מה שמאפשר גם לחלק את עומס הכתיבה, לא רק קריאה - זו הסיבה שהוא נדרש כשגם כתיבה לבדה כבר עמוסה מדי לשרת יחיד.
איך בוחרים מה הולך לאיזה shard¶
ההחלטה הזאת נקראת בחירת מפתח ה-sharding, וזו ההחלטה שהכי הרבה מערכות נופלות עליה. אפשרות נפוצה היא לפצל לפי טווח - כמו הדוגמה עם ה-ID למעלה - אבל זה יכול ליצור עומס לא שווה אם משתמשים חדשים כותבים הרבה יותר מוותיקים, מה שגורם ל-shard האחרון להתמלא הרבה יותר מהר. אפשרות אחרת היא hashing - מריצים פונקציית גיבוב על מפתח כמו ה-ID ומחליטים לפי התוצאה לאיזה shard זה הולך, מה שמפזר עומס בצורה אחידה יותר, אבל הופך שאילתות טווח, כמו "כל המשתמשים שנרשמו החודש", לקשות הרבה יותר.
הבעיה האמיתית - שאילתות שחוצות shards¶
זה החלק שהופך sharding למסוכן. כל עוד שאילתה צריכה נתונים משrd אחד בלבד, הכל פשוט. אבל מה קורה כשצריך לחבר נתונים משני shards שונים - למשל, למצוא את כל ההזמנות של משתמש מסוים, כשההזמנות עצמן יושבות ב-shard לפי מספר הזמנה ולא לפי משתמש? פתאום אין דרך פשוטה לבצע JOIN בין הטבלאות, כי הן פיזית על שרתים שונים. זה בדיוק המקום שבו עיצוב לא זהיר של מפתח ה-sharding יכול להפוך שאילתה פשוטה לסיוט הנדסי.
אז מתי בכלל צריך את זה¶
התשובה הכנה - כמעט אף פעם לא בהתחלה, ורוב הפרויקטים לעולם לא יגיעו לשם. מסד נתונים מודרני על שרת חזק אחד יכול לשרת מיליוני משתמשים בלי בעיה, במיוחד אם משלבים אותו נכון עם caching ואינדקסים טובים. Sharding מוסיף מורכבות תפעולית עצומה - כל migration, כל שאילתה, וכל backup צריך לקחת בחשבון שהנתונים מפוזרים - ולכן זה כלי שכדאי לשלוף רק כשבאמת נגמרו האפשרויות הפשוטות יותר, לא כי זה נשמע מרשים בקורות חיים.
מה זה אומר לכם כמתכנתים¶
גם אם לעולם לא תצטרכו לממש sharding בעצמכם, להבין את הרעיון חשוב כי הוא מופיע כל הזמן בשאלות ראיונות system design, ובקבלת החלטות על עיצוב סכימת מסד נתונים מההתחלה. לדעת שמפתח ה-sharding משפיע על כל שאילתה עתידית זה בדיוק סוג החשיבה שמבדיל מתכנת ג'וניור ממי שכבר חושב כמו ארכיטקט.
בקורס ארכיטקטורת תוכנה שלנו אנחנו מפרקים בדיוק את סוג ההחלטות האלה - מתי sharding נחוץ באמת, מתי זה מוקדם מדי, ואיך בונים מערכות שיכולות לגדול בלי לתכנן מראש לכל תרחיש קיצון.
מתכננים סכימת מסד נתונים ולא בטוחים אם היא תחזיק מעמד בהיקף גדול? שאלו את הקהילה, לרוב שווה עוד זוג עיניים.