העברת סכימה מ-MySQL

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

השוואה בין סוגי נתונים

ממפים את רשימת סוגי הנתונים הבאה ב-MySQL לסוגי הנתונים המקבילים ב-Spanner:

סוג הנתונים ב-MySQL מקבילה ב-Spanner הערות
INTEGER, INT, BIGINT, MEDIUMINT, SMALLINT, TINYINT INT64
TINYINT, BOOL, BOOLEAN, BOOLEAN הערכים של TINYINT(1) מייצגים ערכים בוליאניים של true (שונה מאפס) או false (אפס).
BIT BOOLEAN, INT64
CHAR, VARCHAR, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT STRING ב-Spanner נעשה שימוש במחרוזות Unicode UTF8 בכל מקום, ואין אפשרות להגדיר השוואות.
VARCHAR תומך באורך מקסימלי של 65,535 בייט, בעוד ש-Spanner תומך באורך של עד 2,621,440 תווים.
FLOAT FLOAT32
DOUBLE FLOAT64
DECIMAL, NUMERIC NUMERIC ב-MySQL, סוגי הנתונים NUMERIC ו-DECIMAL תומכים ב-65 ספרות דיוק וקנה מידה בסך הכול, כפי שמוגדר בהצהרת העמודה. סוג הנתונים NUMERIC ב-Spanner תומך בדיוק של עד 38 ספרות ובקנה מידה של עד 9 ספרות אחרי הנקודה העשרונית.
אם אתם צריכים דיוק גבוה יותר, כדאי לעיין במאמר בנושא אחסון נתונים מספריים עם דיוק שרירותי כדי לקבל מידע על מנגנונים חלופיים.
BINARY, VARBINARY, TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB BYTES אפשר לאחסן אובייקטים קטנים (פחות מ-10MiB) כ-BYTES. כדאי להשתמש במוצרים חלופיים כמו Cloud Storage כדי לאחסן אובייקטים גדולים יותר. Google Cloud
DATE DATE גם ב-Spanner וגם ב-MySQL משתמשים בפורמט yyyy-mm-dd לתאריכים, כך שלא נדרש שינוי. פונקציות SQL מסופקות כדי להמיר תאריכים למחרוזת בפורמט.
DATETIME, TIMESTAMP TIMESTAMP ב-Spanner, השעה נשמרת בלי קשר לאזור הזמן. אם אתם צריכים לאחסן אזור זמן, אתם צריכים להשתמש בעמודה נפרדת של STRING. יש פונקציות SQL להמרה של חותמות זמן למחרוזת מפורמטת באמצעות אזורי זמן.
TEXT, TINYTEXT, ENUM STRING אפשר לאחסן ערכים קטנים של TEXT (פחות מ-10MiB) בתור STRING. כדאי להשתמש במוצרים חלופיים של Google Cloud , כמו Cloud Storage, כדי לתמוך בערכים גדולים יותר של TEXT.
ENUM STRING צריך לבצע אימות של ערכי ENUM באפליקציה.
SET ARRAY<STRING> צריך לבצע אימות של ערכי הרכיב SET באפליקציה.
LONGBLOB, MEDIUMBLOB BYTES או STRING שמכיל URI לאובייקט. אפשר לאחסן אובייקטים קטנים (פחות מ-10MiB) כ-BYTES. כדאי להשתמש במוצרים חלופיים כמו Cloud Storage כדי לאחסן אובייקטים גדולים יותר. Google Cloud
LONGTEXT, MEDIUMTEXT STRING (מכיל נתונים או URI לאובייקט חיצוני) אפשר לאחסן אובייקטים קטנים (פחות מ-2,621,440 תווים) בתור STRING. כדאי להשתמש במוצרים חלופיים כמו Cloud Storage כדי לאחסן אובייקטים גדולים יותר. Google Cloud
JSON JSON מחרוזות JSON קטנות (פחות מ-2,621,440 תווים) אפשר לאחסן כ-JSON. כדאי להשתמש במוצרים חלופיים כמו Cloud Storage כדי לאחסן אובייקטים גדולים יותר. Google Cloud
GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTIPOLYGON, GEOMETRYCOLLECTION STRING, ARRAY ‫Spanner לא תומך בסוגי נתונים גיאו-מרחביים. אתם חייבים לאחסן את הנתונים האלה באמצעות סוגי נתונים סטנדרטיים, ולהטמיע את הלוגיקה של חיפוש או סינון בתוך האפליקציה.

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

מומלץ להביא בחשבון את הדוגמאות הבאות:

  • ‫MySQL כולל TEXT, ‏ TINYTEXT, ‏ MEDIUMTEXT, ‏ LONGTEXT. ב-Spanner יש סוג אחד STRING עם פרמטר של אורך תווים שאפשר להגדיר לכל ערך עד 2,621,440 תווים.

  • ‫MySQL כולל את INTEGER, INT, BIGINT, MEDIUMINT, SMALLINT ו-TINYINT. ב-Spanner יש סוג יחיד INT64 שמאחסן ערכים של מספרים שלמים חתומים בגודל 8 בייט. ההבדל העיקרי הוא ש-INT64 ב-Spanner צורך יותר נפח אחסון מאשר MEDIUMINT, ‏ SMALLINT ו-TINYINT. בנוסף, INT64 לא מתעד את מגבלות הטווח של MEDIUMINT,‏ SMALLINT ו-TINYINT, אבל אפשר לאכוף אותן על ידי הוספת אילוצים של CHECK.

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

שאילתות

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

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

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

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

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

רצפים

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

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

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

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