סקירה כללית על העברת מפתח ראשי

בדף הזה מוסבר איך Spanner פועל עם מפתחות ראשיים, ומוצעות אסטרטגיות להעברת מפתחות ראשיים לתרחישי השימוש הבאים:

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

מפתחות ראשיים עוקבים ב-Spanner

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

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

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

המלצות לגבי מפתח ראשי

ההמלצה שמוגדרת כברירת מחדל למפתחות ראשיים ב-Spanner היא להשתמש בערכים של מזהה ייחודי אוניברסלי גרסה 4 (UUIDv4). מזהי UUID הם מזהים של 128 ביט שמשתמשים ב-122 ביט של נתונים רנדומליים. לערכי UUIDv4 יש טווח עצום של ערכים, והם ייחודיים למעשה לא משנה איפה הם נוצרים. לכן הם מועמדים טובים למפתחות ראשיים ב-Spanner שלא גורמים לנקודות חמות.

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

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

אסטרטגיות העברה

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

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

העברת מסדי נתונים של מפתחות UUID

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

אפשר להשתמש בפונקציה GENERATE_UUID() (GoogleSQL,‏ PostgreSQL) ב-Spanner כדי להעביר מסדי נתונים של מפתחות UUID.

הוראות להעברת מסדי נתונים של מפתחות UUID מופיעות במאמר העברת עמודות של מפתחות UUID.

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

נניח שאתם מבצעים מיגרציה ממסד נתונים של מופע יחיד שמשתמש במפתחות מונוטוניים רציפים, כמו AUTO_INCREMENT ב-MySQL,‏ SERIAL ב-PostgreSQL או הסוג IDENTITY הרגיל בשרת SQL או ב-Oracle.

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

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

העברת מסדי נתונים של מפתחות עוקבים עם תמיכה במעבר פעיל

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

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

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

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

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

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

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

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