העברה מ-PostgreSQL אל Spanner (ניב PostgreSQL)

בדף הזה מוסבר איך להעביר מסד נתונים של PostgreSQL בקוד פתוח (מעכשיו נקרא לו פשוט PostgreSQL) למסד נתונים של Spanner בניב PostgreSQL (מעכשיו נקרא לו Spanner).

מידע על מעבר ל-Spanner ולניב GoogleSQL זמין במאמר מעבר מ-PostgreSQL ל-Spanner (ניב GoogleSQL).

מגבלות על העברה

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

תהליכים מאוחסנים וטריגרים

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

רצפים

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

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

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

אמצעי בקרה על גישה

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

תהליך ההעברה

ההעברה כוללת את המשימות הבאות:

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

שלב 1: מיפוי של סכימת PostgreSQL ל-Spanner

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

מפתחות ראשיים

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

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

אינדקסים

אינדקסים של b-tree ב-PostgreSQL דומים לאינדקסים משניים ב-Spanner. במסד נתונים של Spanner, משתמשים באינדקסים משניים כדי ליצור אינדקס לעמודות שמתבצע בהן חיפוש לעיתים קרובות, וכדי להחליף אילוצים של UNIQUE שצוינו בטבלאות. לדוגמה, אם ב-DDL של PostgreSQL מופיעה ההצהרה הבאה:

     CREATE TABLE customer (
        id CHAR (5) PRIMARY KEY,
        first_name VARCHAR (50),
        last_name VARCHAR (50),
        email VARCHAR (50) UNIQUE
     );

You can use the following statement in your Spanner DDL:

    CREATE TABLE customer (
       id VARCHAR(5) PRIMARY KEY,
       first_name VARCHAR(50),
       last_name VARCHAR(50),
       email VARCHAR(50)
       );

    CREATE UNIQUE INDEX customer_emails ON customer(email);

כדי למצוא את האינדקסים של כל אחת מהטבלאות שלכם ב-PostgreSQL, מריצים את פקודת המטא \di ב-psql.

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

ב-Spanner, אינדקסים מיושמים כטבלאות, ולכן יצירת אינדקס לעמודות עם ערכים שעולים באופן מונוטוני (כמו עמודות שמכילות נתוני TIMESTAMP) עלולה לגרום לנקודה חמה. מידע נוסף על שיטות למניעת נקודות חמות זמין במאמר What DBAs need to know about Spanner, part 1: Keys and indexes (מה שבעלי תפקידים של DBA צריכים לדעת על Spanner, חלק 1: מפתחות ואינדקסים).

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

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

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

SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;

הנה דוגמה להצהרת DDL שיוצרת אינדקס משני לטבלה Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

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

תצוגות

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

עמודות שנוצרו

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

שילוב טבלאות

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

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

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

הנה דוגמה ליצירת טבלת אלבומים שמשולבת בטבלת ההורה Singers (זמרים) שהוגדרה קודם:

CREATE TABLE Albums (
 SingerID      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

מידע נוסף זמין במאמר בנושא יצירת טבלאות משולבות.

סוגי נתונים

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

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

סוג נתונים	שימוש במקום זאת
bigserial,serial8	bigint, int8
‫bit [ (n) ]	-
bit varying [ (n) ], varbit [ (n) ]	-
קופסה	-
‫character [ (n) ], char [ (n) ]	character varying
cidr	טקסט
מעגל	-
inet	טקסט
מספר שלם, int4	bigint, int8
‫interval [fields] [ (p) ]	bigint
json	jsonb
line	-
lseg	-
macaddr	טקסט
כסף	מספרי, עשרוני
נתיב	-
pg_lsn	-
נקודה	-
פוליגון	-
realfloat4	דיוק כפול, float8
smallint, int2	bigint, int8
smallserial, serial2	bigint, int8
‫serial, ‏ serial4	bigint, int8
שעה [ (p) ] [ בלי אזור זמן ]	טקסט, בסימון HH:MM:SS.sss
‫time [ (p) ] with time zonetimetz	טקסט, בפורמט HH:MM:SS.sss+ZZZZ. אפשר גם להשתמש בשתי עמודות.
חותמת זמן [ (p) ] [ בלי אזור זמן ]	text או timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	text או bytea
xml	טקסט

שלב 2: תרגום של שאילתות SQL

ב-Spanner יש הרבה פונקציות של PostgreSQL בקוד פתוח שזמינות כדי להקל על המעבר.

אפשר ליצור פרופיל של שאילתות SQL באמצעות הדף Spanner Studio במסוף Google Cloud כדי להריץ את השאילתה. באופן כללי, שאילתות שמבצעות סריקות מלאות של טבלאות גדולות הן יקרות מאוד, ולכן מומלץ להשתמש בהן במשורה. מידע נוסף על אופטימיזציה של שאילתות SQL זמין במאמר שיטות מומלצות לשימוש ב-SQL.

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

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

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

למידע נוסף:

• יצירה וניהול של מופעים
• יצירה וניהול של מסדי נתונים
• מידע על סכימות

שלב 4: מבצעים רפקטורינג באפליקציה

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

שלב 5: מעבירים את הנתונים

יש שתי דרכים להעביר את הנתונים:

• באמצעות הכלי להעברת נתונים ל-Spanner.

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

• באמצעות הפקודה COPY FROM STDIN.

  פרטים נוספים זמינים במאמר בנושא פקודת COPY לייבוא נתונים.