עדכון הסכימה

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

במסוף Google Cloud

שולחים פקודת ALTER TABLE בדף Spanner Studio.

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

מריצים את הפקודה ALTER TABLE באמצעות הפקודה gcloud spanner databases ddl update.
שימוש בספריות לקוח
שימוש ב-REST API של projects.instances.databases.updateDdl
שימוש ב-RPC API‏ UpdateDatabaseDdl

עדכוני סכימה נתמכים

מערכת Spanner תומכת בעדכוני הסכימה הבאים של מסד נתונים קיים:

מוסיפים או מסירים סכימה עם שם.
יוצרים טבלה חדשה. העמודות בטבלאות החדשות יכולות להיות NOT NULL.
מחיקת טבלה, אם אין בה טבלאות אחרות שמשולבות בתוכה, ואין לה אינדקסים משניים.
יצירה או מחיקה של טבלה עם מפתח זר.
הוספה או הסרה של מפתח זר מטבלה קיימת.
מוסיפים עמודה לא מפתח לכל טבלה. אי אפשר NOT NULL עמודות חדשות שהן לא עמודות מפתח.
- הסרה של עמודה שאינה מפתח מכל טבלה, אלא אם היא נמצאת בשימוש על ידי אינדקס משני, מפתח זר, עמודה וירטואלית מאוחסנת או אילוץ בדיקה.
הוספה של NOT NULL לעמודה שהיא לא עמודת מפתח, לא כולל עמודות ARRAY.
הסרת NOT NULL מעמודה שאינה עמודת מפתח.
שינוי עמודה מסוג STRING לעמודה מסוג BYTES או עמודה מסוג BYTES לעמודה מסוג STRING.
שינוי עמודה מסוג PROTO לעמודה מסוג BYTES או עמודה מסוג BYTES לעמודה מסוג PROTO
שינוי סוג הודעת הפרוטו של עמודה מסוג PROTO.
כדי להוסיף ערכים חדשים להגדרה של ENUM ולשנות את השם של ערכים קיימים, משתמשים ב-ALTER PROTO BUNDLE.
לשנות הודעות שמוגדרות ב-PROTO BUNDLE בדרכים שרירותיות, בתנאי שהשדות ששונו בהודעות האלה לא משמשים כמפתחות באף טבלה, ושהנתונים הקיימים עומדים באילוצים החדשים.
הגדלה או הקטנה של מגבלת האורך עבור סוג STRING או BYTES (כולל MAX), אלא אם מדובר בעמודה של מפתח ראשי שהועברה בירושה מטבלה ראשית אחת או יותר לטבלאות צאצא.
הגדלה או הקטנה של מגבלת האורך של עמודה מסוג ARRAY<STRING>,‏ ARRAY<BYTES> או ARRAY<PROTO> למקסימום המותר.
הפעלה או השבתה של חותמות זמן של ביצוע פעולות (commit) בעמודות של ערכים ומפתחות ראשיים.
מוסיפים או מסירים אינדקס משני.
הוספה או הסרה של אילוץ מסוג CHECK מטבלה קיימת.
הוספה או הסרה של עמודה וירטואלית מאוחסנת מטבלה קיימת.
יוצרים חבילת נתונים סטטיסטיים חדשה לאופטימיזציה.
ליצור תצוגות מפורטות ולנהל אותן.
ליצור ולנהל רצפים.
ליצור תפקידים במסד הנתונים ולהעניק הרשאות.
הגדרת ערך ברירת מחדל של עמודה, שינוי שלו או ביטול שלו.
לשנות את האפשרויות של מסד הנתונים (לדוגמה, default_leader או version_retention_period).
ליצור ולנהל סנכרון שינויים בזרמי נתונים.
ליצור ולנהל מודלים של למידת מכונה.

עדכוני סכימה שלא נתמכים

‫Spanner לא תומך בעדכוני הסכימה הבאים של מסד נתונים קיים:

אם יש שדה PROTO מסוג ENUM שמופנה על ידי טבלה או מפתח אינדקס, אי אפשר להסיר ערכים של ENUM מ-proto enums. (הסרת ערכים של ENUM מ-enums שמשמשים עמודות של ENUM<> נתמכת, כולל כשמשתמשים בעמודות האלה כמפתחות).
שינוי עמודה מסוג STRING(36) לעמודה מסוג UUID או עמודה מסוג UUID לעמודה מסוג STRING(36).

ביצועים של עדכון סכימה

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

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

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

עדכוני סכימה שאומתו מול הגדרות התצוגה

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

עדכוני סכימה שמחייבים אימות נתונים

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

לדוגמה, נניח שהגדרתם את הקובץ music.proto הבא עם ספירה RecordLabel והודעת פרוטוקול Songwriter:

  enum RecordLabel {
    COOL_MUSIC_INC = 0;
    PACIFIC_ENTERTAINMENT = 1;
    XYZ_RECORDS = 2;
  }

  message Songwriter {
    required string nationality   = 1;
    optional int64  year_of_birth = 2;
  }

כדי להוסיף טבלת Songwriters לסכימה:

GoogleSQL

CREATE PROTO BUNDLE (
  googlesql.example.music.Songwriter,
  googlesql.example.music.RecordLabel,
);

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
  SongWriter googlesql.example.music.Songwriter
) PRIMARY KEY (Id);

CREATE TABLE Albums (
  SongwriterId     INT64 NOT NULL,
  AlbumId          INT64 NOT NULL,
  AlbumTitle       STRING(MAX),
  Label            INT32
) PRIMARY KEY (SongwriterId, AlbumId);

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

הוספת ההערה NOT NULL לעמודה שאינה עמודת מפתח. לדוגמה:
```
ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL;
```

הקטנת האורך של עמודה. לדוגמה:

ALTER TABLE Songwriters ALTER COLUMN FirstName STRING(10);

השינוי מ-BYTES ל-STRING. לדוגמה:

ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX);

השינוי מ-INT64/INT32 ל-ENUM. לדוגמה:

ALTER TABLE Albums ALTER COLUMN Label googlesql.example.music.RecordLabel;

הסרת ערכים קיימים מהגדרת ה-enum‏ RecordLabel.
הפעלת חותמות זמן של ביצוע שינויים בעמודה קיימת TIMESTAMP. לדוגמה:
```
ALTER TABLE Albums ALTER COLUMN LastUpdateTime SET OPTIONS (allow_commit_timestamp = true);
```
הוספת אילוץ מסוג check לטבלה קיימת.
הוספת עמודה מאוחסנת שנוצרה לטבלה קיימת.
יצירת טבלה חדשה עם מפתח זר.
הוספת מפתח זר לטבלה קיימת.

עדכוני הסכימה האלה ייכשלו אם נתוני הבסיס לא יעמדו באילוצים החדשים. לדוגמה, ההצהרה ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL תיכשל אם ערך כלשהו בעמודה Nickname הוא NULL, כי הנתונים הקיימים לא עומדים במגבלת NOT NULL של ההגדרה החדשה.

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

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

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

אפשר לבטל פעולה ממושכת של אימות נתונים באמצעות ה-method‏ projects.instances.databases.operations.cancel או באמצעות gcloud spanner operations.

סדר הביצוע של הצהרות בחבילות

אם אתם משתמשים ב-Google Cloud CLI, ב-API בארכיטקטורת REST או ב-RPC API, אתם יכולים להנפיק קבוצה של הצהרות CREATE, ALTER או DROP .

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

יכול להיות ש-Spanner ישלב ויסדר מחדש הצהרות מקבוצות שונות, ויערבב הצהרות מקבוצות שונות לשינוי אטומי אחד שמוחל על מסד הנתונים. בכל שינוי אטומי, ההצהרות מקבוצות שונות מתבצעות בסדר שרירותי. לדוגמה, אם קבוצה אחת של הצהרות מכילה את ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(50) וקבוצה אחרת של הצהרות מכילה את ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(20), ‏ Spanner ישאיר את העמודה הזו באחד משני המצבים האלה, אבל לא מצוין באיזה מהם.

גרסאות סכימה שנוצרו במהלך עדכוני סכימה

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

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

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

פעולת סכימה	משך משוער
`CREATE TABLE`	דקות
`CREATE INDEX`	דקות עד שעות, אם טבלת הבסיס נוצרת לפני האינדקס. דקות, אם ההצהרה מבוצעת באותו זמן כמו ההצהרה `CREATE TABLE` עבור טבלת הבסיס.
`DROP TABLE`	דקות
`DROP INDEX`	דקות
`ALTER TABLE ... ADD COLUMN`	דקות
`ALTER TABLE ... ALTER COLUMN`	דקות עד שעות, אם נדרש אימות ברקע. דקות, אם לא נדרש אימות ברקע.
`ALTER TABLE ... DROP COLUMN`	דקות
`ANALYZE`	בין דקות לשעות, בהתאם לגודל מסד הנתונים.

שינויים בסוגי נתונים וסנכרון שינויים בזרמי נתונים

אם משנים את סוג הנתונים של עמודה שזרם השינויים עוקב אחריה, השדה column_types של רשומות רלוונטיות של זרם השינויים משקף את הסוג החדש שלה, וכך גם נתוני ה-JSON‏ old_values בשדה mods של הרשומות.

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

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

שיטות מומלצות לעדכוני סכימה

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

פעולות שצריך לבצע לפני שמפרסמים את עדכון הסכימה

לפני שמבצעים עדכון סכימה:

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

הגבלת התדירות של עדכוני סכימה

אם מבצעים יותר מדי עדכוני סכימה בפרק זמן קצר, יכול להיות ש-Spanner throttle את העיבוד של עדכוני הסכימה שנמצאים בתור. הסיבה לכך היא שמערכת Spanner מגבילה את נפח האחסון של גרסאות הסכימה. יכול להיות שהעדכון של הסכימה יוגבל אם יש יותר מדי גרסאות ישנות של הסכימה בתוך תקופת השמירה. הקצב המקסימלי של שינויים בסכימה תלוי בהרבה גורמים, ואחד מהם הוא המספר הכולל של העמודות במסד הנתונים. לדוגמה, במסד נתונים עם 2,000 עמודות (בערך 2,000 שורות ב-INFORMATION_SCHEMA.COLUMNS), אפשר לבצע לכל היותר 1,500 שינויים בסכימה (פחות אם השינוי בסכימה דורש כמה גרסאות) במהלך תקופת השמירה. כדי לראות את המצב של עדכוני סכימה שמתבצעים, משתמשים בפקודה gcloud spanner operations list ומסננים לפי פעולות מהסוג DATABASE_UPDATE_DDL. כדי לבטל עדכון סכימה שמתבצע, משתמשים בפקודה gcloud spanner operations cancel ומציינים את מזהה הפעולה.

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

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

הצהרות שאולי צריך למלא בהן חוסרים של נתוני אינדקס, כמו CREATE INDEX
הצהרות שאולי צריך לאמת נתונים קיימים, כמו הוספת NOT NULL

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

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

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

אפשרויות לעדכונים גדולים של סכימות

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

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

לדוגמה, קבוצת ההצהרות הזו תשתמש בגרסה אחת של סכימה:

GoogleSQL

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

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

GoogleSQL

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX UnrelatedIndex ON UnrelatedTable(UnrelatedIndexKey);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

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

המתנה לסיום בקשות ה-API

כששולחים בקשות projects.instances.databases.updateDdl (API בארכיטקטורת REST) או UpdateDatabaseDdl (RPC API), צריך להשתמש ב-projects.instances.databases.operations.get (API בארכיטקטורת REST) או ב-GetOperation (RPC API), בהתאמה, כדי להמתין להשלמת כל בקשה לפני שמתחילים בקשה חדשה. המתנה לסיום כל בקשה מאפשרת לאפליקציה לעקוב אחרי התקדמות העדכונים של הסכימה. בנוסף, הוא שומר את רשימת העדכונים הממתינים של הסכימה בגודל שניתן לניהול.

טעינה בכמות גדולה

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

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

עדכוני סכימה נתמכים

עדכוני סכימה שלא נתמכים

ביצועים של עדכון סכימה

עדכוני סכימה שאומתו מול הגדרות התצוגה

עדכוני סכימה שמחייבים אימות נתונים

GoogleSQL

סדר הביצוע של הצהרות בחבילות

גרסאות סכימה שנוצרו במהלך עדכוני סכימה

שינויים בסוגי נתונים וסנכרון שינויים בזרמי נתונים

שיטות מומלצות לעדכוני סכימה

פעולות שצריך לבצע לפני שמפרסמים את עדכון הסכימה

הגבלת התדירות של עדכוני סכימה

אפשרויות לעדכונים גדולים של סכימות

GoogleSQL

GoogleSQL

המתנה לסיום בקשות ה-API

טעינה בכמות גדולה

עדכון הסכימה