שיטות מומלצות להעלאה בכמות גדולה

בדף הזה מפורטות הנחיות לטעינה יעילה של כמויות גדולות של נתונים ב-Spanner.

יש כמה אפשרויות לטעינת נתונים בכמות גדולה ל-Spanner:

• הוספת שורות באמצעות שפת טיפול בנתונים (DML)
• הוספת שורות באמצעות מוטציות.
• ייבוא נתונים באמצעות מחבר Dataflow.
• ייבוא מסד נתונים באמצעות קובצי Avro
• ייבוא נתונים בפורמט CSV.

אפשר גם להוסיף שורות באמצעות Google Cloud CLI, אבל לא מומלץ להשתמש ב-CLI של gcloud לטעינה בכמות גדולה.

הנחיות לשיפור הביצועים של טעינה בכמות גדולה

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

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

חלוקת הנתונים לפי מפתח ראשי

מערכת Spanner מחלקת אוטומטית טבלאות לטווחים קטנים יותר. המפתח הראשי של שורה קובע את המיקום שבו היא מחולקת למחיצות.

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

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

מומלץ שמספר המחיצות יהיה פי 10 ממספר הצמתים במופע Spanner. כדי להקצות שורות למחיצות:

• ממיינים את הנתונים לפי המפתח הראשי.
• מחלקים את הנתונים ל-10 * (מספר הצמתים) מחיצות נפרדות בגודל שווה.
• ליצור ולהקצות לכל מחיצה משימת עובד נפרדת. יצירת משימות העובד מתבצעת באפליקציה. זו לא תכונה של Spanner.

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

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

דוגמה

יש לכם הגדרה אזורית עם 3 צמתים. יש לכם 90,000 שורות בטבלה לא משולבת. המפתחות הראשיים בטווח הטבלה הם מ-1 עד 90,000.

• שורות: 90,000 שורות
• צמתים: 3
• מחיצות: 10 * 3 = 30
• שורות בכל מחיצה: 90,000 חלקי 30 שווה 3,000.

המחיצה הראשונה כוללת את טווח המפתחות 1 עד 3000. המחיצה השנייה כוללת את טווח המפתחות 3001 עד 6000. המחיצה ה-30 כוללת את טווח המפתחות 87001 עד 90000. (לא מומלץ להשתמש במפתחות עוקבים בטבלה גדולה. הדוגמה הזו היא להמחשה בלבד.)

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

טעינה בכמות גדולה ללא חלוקה למחיצות

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

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

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

איך להימנע מעומס יתר

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

ביצוע commit של מוטציות בגודל של 1MB עד 5MB בכל פעם

כל פעולת כתיבה ל-Spanner כוללת תקורה מסוימת, בין אם פעולת הכתיבה גדולה או קטנה. כדי למקסם את קצב העברת הנתונים, צריך למקסם את כמות הנתונים שמאוחסנת בכל פעולת כתיבה. ככל שהכתיבה גדולה יותר, כך יחס התקורה לכל כתיבה נמוך יותר. טכניקה טובה היא לשנות מאות שורות בכל פעולת commit. כשכותבים שורות גדולות יחסית, גודל של 1MB עד 5MB בדרך כלל מספק את הביצועים הכי טובים. כשכותבים ערכים קטנים או ערכים שמקבלים אינדקס, בדרך כלל מומלץ לכתוב לכל היותר כמה מאות שורות בהתחייבות אחת. בנוסף לגודל הקומיט ולמספר השורות, חשוב לדעת שיש מגבלה של 80,000 מוטציות לכל קומיט. כדי לקבוע את הביצועים האופטימליים, צריך לבדוק ולמדוד את קצב העברת הנתונים.

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

הנחיות לגבי אינדקסים משניים

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

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

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

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

שימוש ב-INTERLEAVE IN במהלך טעינה בכמות גדולה

בסכימות עם הרבה הפניות של הורה-צאצא בטבלאות, תמיד צריך לטעון את ההורה לפני הצאצאים כדי להבטיח את שלמות ההפניות. התיאום הזה יכול להיות מסובך, במיוחד אם יש כמה רמות בהיררכיה. המורכבות הזו גם מקשה מאוד על ביצוע פעולות בקבוצות ועל הרצת פעולות במקביל, ויכולה להשפיע באופן משמעותי על זמן הטעינה הכולל של נתונים בכמות גדולה. ב-Spanner, הקשרים האלה נאכפים באמצעות INTERLEAVE IN PARENT, או מפתחות זרים. פרטים נוספים מופיעים בCREATE TABLEמאמרי העזרה.

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

עם זאת, כשמטעינים נתונים בכמות גדולה לטבלאות INTERLEAVE IN PARENT, מומלץ ליצור את כל הטבלאות באמצעות סמנטיקה של INTERLEAVE IN. כך השורות משולבות פיזית, אבל לא נאכפת שלמות רפרנציאלית. כך תוכלו ליהנות מיתרונות הביצועים של המיקום, אבל לא תצטרכו להזמין מראש. עכשיו אפשר להוסיף שורות צאצא לפני שורות ההורה המתאימות, ולכן Spanner יכול לכתוב לכל הטבלאות במקביל.

אחרי שכל הטבלאות נטענות, אפשר להעביר את הטבלאות המשולבות כדי להתחיל לאכוף את קשר ההורה-צאצא באמצעות ההצהרה ALTER TABLE t1 SET INTERLEAVE IN PARENT t2. הפעולה הזו מאמתת את השלמות הרפרנציאלית, ונכשלת אם יש שורות צאצא יתומות. אם האימות נכשל, אפשר להשתמש בשאילתה הבאה כדי לזהות שורות הורה חסרות.

      SELECT pk1, pk2 FROM child
      EXCEPT DISTINCT
      SELECT pk1, pk2 FROM parent;

בדיקה ומדידה של קצב העברת הנתונים

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

שיטות מומלצות לטעינה תקופתית בכמות גדולה למסד נתונים קיים

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

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

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