מדריך להוכחת היתכנות של Spanner

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

בנוסף לאימות היכולות הטכניות של Spanner, ה-POC משרת שתי מטרות:

• כדי להבין את היתרונות של Spanner בתרחיש השימוש שלכם
• כדי לעזור לכם לזהות את הסיכונים שקשורים למעבר ל-Spanner

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

ההנחיות במסמך הזה יעזרו לכם להעריך כל אחד מהתחומים האלה.

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

• יכולות המעקב עוזרות לכם להעריך אם Spanner מספק את התובנות שנדרשות לפעולות יעילות במסד הנתונים. ההערכה הזו כוללת:

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

  ה-POC יכול לחשוף פערים שצריך לטפל בהם כדי לבצע אופטימיזציה מלאה של היעילות התפעולית.

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

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

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

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

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

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

מחזור החיים של פעילויות POC

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

תכנון ה-POC

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

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

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

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

הגדרה של קריטריון הערכה כמותי

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

• הצגת מספר מסוים של שאילתות לשנייה (QPS) ברמת הייצור
• שמירה על זמן אחזור של פחות מ-20 אלפיות השנייה בעומסי שיא מוגדרים מראש
• טיפול בפרצי תנועה מוגדרים בבירור ללא פגיעה בביצועים

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

דוגמה לטבלת קריטריונים להערכה:

Evaluation Facet	קריטריונים להצלחה
זמינות	99.999%
אבטחה	נדרש CMEK עם EKM
התחייבות ליעד להתאוששות מאסון (RPO) במקרה של הפסקה זמנית בשירות אזורית	0
מגבלת זמן האחזור לרוב העסקאות הקריטיות	‫p50 מתחת ל-20 אלפיות השנייה
זמן האחזור של השאילתות הקריטיות ביותר שמוצגות למשתמשים	‫p50 מתחת ל-100 אלפיות השנייה
מדרגיות	להדגים שאפשר להגדיל את מספר העסקאות מ-10,000 עסקאות לשנייה ל-100,000 עסקאות לשנייה עם זמן אחזור של p50 מתחת ל-20 אלפיות השנייה, במהלך שעה אחת

הגדרת היקף התיקים להערכה

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

בחירת הגדרת מופע של Spanner

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

• הגדרות של אזור יחיד מאחסנות נתונים באזור אחד ב-Google Cloud, ומציעות זמן אחזור נמוך באותו אזור וחסכוניות בעלויות. הטופולוגיות האלה אידיאליות לעומסי עבודה שנדרשת בהם יתירות אזורית בתוך האזור, שמספקת זמינות של 99.99%.
• הגדרות של שני אזורים יוצרות רפליקה של הנתונים בשני אזורים במדינה אחת, עם רפליקת עדות בכל אזור למעבר לגיבוי בעת כשל. ההגדרה הזו מספקת זמינות גבוהה יותר (99.999%) ועמידות בפני תקלות בהשוואה להגדרה באזור יחיד. הטופולוגיות האלה מתאימות לעומסי עבודה עם דרישות תאימות מחמירות (כמו מיקום הנתונים) או דרישות של קרבה גיאוגרפית.
• הגדרות של מספר אזורים יוצרות רפליקות של הנתונים בכמה אזורים, וכך מבטיחות זמינות גבוהה מאוד ועמידות להפסקות חשמל אזוריות. הטופולוגיות האלה מתאימות במיוחד לאפליקציות שנדרש בהן שכפול נתונים בשני מקומות שונים עם זמינות של עד 99.999%.

שיקולים לגבי זמן האחזור במופעים חוצי-אזורים

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

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

הגדרות שתואמות לדרישות של האפליקציה

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

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

התאמת הגודל של Spanner

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

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

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

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

עיצוב סכימה

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

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

תכנון להשגת מדרגיות

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

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

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

אפשר ליצור סכימה לטיוטה במסוף Google Cloud , כמו שמוצג בתמונה הבאה.

העברת סכימות באמצעות כלי ההעברה של Spanner

כלי ההעברה של Spanner‏ (SMT) יכול לפשט את יצירת הסכימה כשמבצעים העברה ממסדי נתונים רלציוניים, כולל MySQL או PostgreSQL. הכלי SMT מבצע אוטומטית יצירה של סכימות וכולל אופטימיזציות בסיסיות, כמו הצעות לאינדקסים ולהתאמות של סכימות. ה-SMT מספק נקודת התחלה טובה, אבל לרוב צריך לבצע שינויים ידניים כדי להתאים את הסכימה לתרחישי השימוש הספציפיים או לדפוסי העומס שלכם.

שימוש בתהליך איטרטיבי לעיצוב סכימה

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

טעינת נתונים

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

• התהליך ההפוך של חילוץ, טרנספורמציה וטעינה (ETL) ב-BigQuery ל-Spanner הוא מנגנון טעינת נתונים משולב וקל לשימוש, שמאפשר לכם להשתמש בטרנספורמציות מבוססות-SQL כדי לטעון נתונים ל-Spanner. השיטה הזו מתאימה למגוון רחב של פורמטים של נתונים, כולל נתונים חצי-מובְנים כמו JSON.
• במסדי נתונים רלציוניים כמו MySQL ו-PostgreSQL,‏ כלי ההעברה של Spanner‏ (SMT) מבצע אוטומציה של יצירת סכימות, מיפוי סוגי נתונים וטעינה של נתונים בכמות גדולה.
• בפורמטים של קבצים שטוחים, Google מספקת תבניות Dataflow ל-CSV ל-Spanner ול-Avro ל-Spanner כדי ליצור הגדרות סכמה ידניות להעלאת נתונים בכמות גדולה. למסדי נתונים שתואמים ל-JDBC, ‏ Google מספקת את תבנית ה-JDBC ל-Spanner Dataflow.

מידע נוסף על האפשרויות האלה זמין במאמר העברת נתונים משלכם.

אם אין נתונים לדוגמה, אפשר להשתמש בכלים ליצירת נתונים סינתטיים כמו JMeter מ-Machmeter ו-QuickPerf כדי ליצור מערכי נתונים שמותאמים לסכימה ולתרחיש השימוש שלכם. מידע נוסף זמין במאמר בנושא יצירת נתוני דוגמה.

שימוש בנתונים קיימים

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

מקור	כלי	יצירת סכימה	טרנספורמציות	גודל הנתונים
MySQL	SMT	אוטומטי	המרת סוג הנתונים בלבד	קטן
PostgreSQL	SMT	אוטומטי	המרת סוג הנתונים בלבד	קטן
כל JDBC	‫JDBC ל-Spanner	ידני	המרת סוג הנתונים בלבד	large
CSV	CSV to Spanner	ידני	המרת סוג הנתונים בלבד	large
	BigQuery reverse ETL	ידני	טרנספורמציות מורכבות נתמכות	large
Avro	‫Avro ל-Spanner	ידני	המרת סוג הנתונים בלבד	large
	BigQuery reverse ETL	ידני	טרנספורמציות מורכבות נתמכות	large
JSON	BigQuery reverse ETL	ידני	טרנספורמציות מורכבות נתמכות	large

העברת נתונים מ-BigQuery ל-Spanner

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

כלי ההעברה של Spanner

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

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

תבניות Dataflow

‫Dataflow הוא שירות מנוהל מלא שנועד לעיבוד נתונים ניתן להרחבה, ולכן הוא בחירה מתאימה לטעינה של כמויות גדולות של נתונים.

‫Google מספקת את תבניות הקוד הפתוח הבאות לדפוסי טעינה נפוצים:

• ‫CSV to Spanner טוען נתונים מקובצי CSV שמאוחסנים ב-Cloud Storage אל Spanner.
• ‫Avro to Spanner טוען קובצי נתונים קיימים בפורמט Avro מ-Cloud Storage.
• ‫JDBC ל-Spanner טוען נתונים ממסדי נתונים שתומכים ב-JDBC.

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

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

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

יצירת נתונים לדוגמה

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

‫JMeter מ-Machmeter

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

QuickPerf

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

בדיקות עומס

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

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

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

מידע נוסף ודוגמאות להגדרות זמינים במאגר Machmeter.

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

שיטות מומלצות לבדיקות עומס

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

• תקופת הרצה: מומלץ להקצות תקופת הרצה (בדרך כלל 30 דקות או יותר) כדי לאפשר ל-Spanner להגיע למצב יציב אחרי שינוי קנה מידה של הצמתים או אחרי הצגת עומס עבודה חדש.
• מדידת מדדים רלוונטיים: כדאי להתמקד במדדים כמו תפוקה (פעולות לשנייה), אחוזוני חביון (לדוגמה, p50,‏ p95) וניצול CPU כדי להבין איך Spanner משרת את עומס העבודה שלכם.
• הפעלת בדיקות השוואה ארוכות: כדי לקבל תוצאות מייצגות יותר, מומלץ להפעיל את בדיקות העומס למשך תקופות ארוכות (למשל, יותר משעה) כדי להביא בחשבון התנהגויות של המערכת כמו איזון מחדש ומשימות תחזוקה ברקע.
• בדיקות שינוי גודל: בודקים תרחישי הגדלה והקטנה כדי לראות את התנהגות Spanner בתצורות שונות של צמתים ובשיאי עומס.

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

מעקב

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

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

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

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

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

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

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

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

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

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

אופטימיזציה

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

אופטימיזציה של עיצוב הסכימה

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

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

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

מידע על בניית סכימות שניתנות להרחבה זמין במאמר בנושא שיטות מומלצות לעיצוב סכימות ב-Spanner.

אופטימיזציה של הסמנטיקה והשאילתות של העסקאות

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

• מצבי טרנזקציה: צריך להשתמש במצב הטרנזקציה המתאים לכל פעולה בעומס העבודה. לדוגמה, אפשר להשתמש בעסקאות לקריאה בלבד לשאילתות שלא משנות נתונים, או ב-DML עם חלוקה למחיצות לעדכונים ומחיקות בכמות גדולה.
• שימוש באוסף פעולות (batching): כשמתאפשר, מומלץ להשתמש בפעולות כתיבה באוסף כדי לצמצם את התקורה שנובעת מריבוי של הלוך ושוב.
• אופטימיזציה של שאילתות: כדאי לשנות את מבנה השאילתות כך שיכללו רק את העמודות והשורות הנדרשות, להשתמש באינדקסים ולהשתמש בפרמטרים של שאילתות באפליקציה כדי לצמצם את התקורה.

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

בדיקות עומס איטרטיביות

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

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

מדדים מרכזיים למעקב

במהלך האופטימיזציה, כדאי לעקוב אחרי מדדים מרכזיים כמו זמן אחזור (p50,‏ p99), קצב העברת נתונים וניצול המעבד (CPU).

המאמרים הבאים

• בסרטון How to plan and run a Spanner POC (איך לתכנן ולהפעיל הוכחת היתכנות של Spanner) מוסבר על השלבים החשובים, השיטות המומלצות והכלים שצריך כדי להעריך ביעילות את היכולות של Spanner.