מבוא להעברות נתונים ב-MySQL

אתם יכולים לטעון נתונים מ-MySQL ל-BigQuery באמצעות המחבר של שירות העברת הנתונים ל-BigQuery ל-MySQL. המחבר תומך במכונות MySQL שמתארחות בסביבה המקומית, ב-Cloud SQL ובספקי ענן ציבורי אחרים כמו Amazon Web Services ‏ (AWS) ו-Microsoft Azure. במאמר הזה נסביר על האפשרויות להטמעת נתונים בהעברה מ-MySQL, על מיפוי סוגי הנתונים ועל התמחור.

במאמר טעינת נתוני MySQL ל-BigQuery מוסבר איך מתזמנים העברה של MySQL.

אפשרויות להטמעת נתונים

בקטעים הבאים מפורטות האפשרויות להעברת נתונים כשמגדירים העברת נתונים מ-MySQL.

הגדרת TLS

המחבר של MySQL תומך בהגדרה של אבטחת שכבת התעבורה (TLS) כדי להצפין את העברות הנתונים ל-BigQuery. המחבר של MySQL תומך בהגדרות ה-TLS הבאות:

  • מצב הצפנת נתונים ואימות של רשות אישורים ושם מארח. במצב הזה מתבצע אימות מלא של השרת באמצעות TLS בפרוטוקול TCPS. הוא מצפין את כל הנתונים בזמן ההעברה ומוודא שהאישור של שרת מסד הנתונים נחתם על ידי רשות אישורים (CA) מהימנה. בנוסף, במצב הזה נבדק אם שם המארח שאליו מתחברים זהה בדיוק לשם הנפוץ (CN) או לשם חלופי של בעלים (subject) (SAN) באישור של השרת. המצב הזה מונע מתוקפים להשתמש באישור תקף של דומיין אחר כדי להתחזות לשרת של מסד הנתונים.

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

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

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

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

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

    השתמשו במצב הזה אם אתם צריכים לוודא שכל הנתונים מוצפנים, אבל אתם לא יכולים או לא רוצים לאמת את זהות השרת. מומלץ להשתמש במצב הזה כשעובדים עם רשתות VPC פרטיות.

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

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

אישור שרת מהימן (PEM)

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

  • אם אתם משתמשים באישור שחתום על ידי רשות אישורים פרטית בארגון שלכם או באישור עם חתימה עצמית, אתם צריכים לספק את שרשרת האישורים המלאה או את האישור היחיד עם החתימה העצמית. הפעולה הזו נדרשת לאישורים שהונפקו על ידי רשויות אישורים פנימיות של שירותי ספק שירותי ענן מנוהלים, כמו Amazon מסד נתונים רלציוני Service (RDS).
  • אם האישור של שרת מסד הנתונים שלכם חתום על ידי רשות אישורים ציבורית (לדוגמה, Let's Encrypt,‏ DigiCert או GlobalSign), אתם לא צריכים לספק אישור. אישורי הבסיס של רשויות האישורים הציבוריות האלה מותקנים מראש ומהימנים על ידי שירות העברת הנתונים ל-BigQuery.

אפשר לציין אישורים בקידוד PEM בשדה Trusted PEM Certificate בהגדרות ההעברה, עם הדרישות הבאות:

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

העברות מלאות או מצטברות

כשמגדירים העברה מ-MySQL, אפשר לציין איך הנתונים ייטענו ב-BigQuery על ידי בחירה בהעדפת הכתיבה Full או Incremental בהגדרות ההעברה. העברות מצטברות נתמכות בגרסת Preview.

אתם יכולים להגדיר העברת נתונים מלאה כדי להעביר את כל הנתונים ממערכי הנתונים של MySQL בכל העברת נתונים.

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

הוספה למצב כתיבה

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

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

בהעברות מ-MySQL, מומלץ לבחור עמודה שמתעדכנת רק כשהרשומה נוצרת, ולא תשתנה בעדכונים הבאים – לדוגמה, העמודה CREATED_AT.

מצב כתיבה של עדכון או הוספה (upsert)

במצב הכתיבה "עדכון או הוספה" (upsert), המערכת בודקת אם יש מפתח ראשי, ואז מעדכנת שורה או מוסיפה שורה חדשה בטבלת היעד. אתם יכולים לציין מפתח ראשי כדי לאפשר למחבר MySQL לקבוע אילו שינויים נדרשים כדי שהטבלה ביעד תהיה מעודכנת בהתאם לטבלה במקור. אם המפתח הראשי שצוין קיים בטבלה ב-BigQuery במהלך העברת נתונים, המחבר של MySQL מעדכן את השורה הזו עם נתונים חדשים מטבלת המקור. אם אין מפתח ראשי במהלך העברת הנתונים, המחבר של MySQL מוסיף שורה חדשה.

כשבוחרים במצב "לעדכן או להוסיף (upsert)", צריך לבחור עמודת סימן מים ומפתח ראשי:

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

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

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

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

התנהגות של הוספה מצטברת

כשאתם מבצעים שינויים בסכימת הטבלה במקור הנתונים, העברות הנתונים המצטברות מהטבלאות האלה משתקפות ב-BigQuery בדרכים הבאות:

שינויים במקור הנתונים התנהגות של הטמעה מצטברת
הוספת עמודה חדשה עמודה חדשה נוספת לטבלת היעד ב-BigQuery. כל הרשומות הקודמות בעמודה הזו יכילו ערכי null.
מחיקת עמודה העמודה שנמחקה נשארת בטבלת היעד ב-BigQuery. ערכים חדשים בעמודה שנמחקה יאוכלסו בערכי null.
שינוי סוג הנתונים בעמודה המחבר תומך רק ב המרות של סוגי נתונים שנתמכות על ידי הצהרת ה-DDL‏ ALTER COLUMN. המרות של סוגי נתונים אחרים גורמות לכך שהעברת הנתונים תיכשל.

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

מיפוי סוגי נתונים

בטבלה הבאה מופיע מיפוי של סוגי הנתונים ב-MySQL לסוגי הנתונים התואמים ב-BigQuery:

סוג הנתונים ב-MySQL סוג הנתונים ב-BigQuery סוג נתונים מעודכן ב-BigQuery
BIT BOOLEAN
TINYINT INTEGER
BOOL, BOOLEAN INTEGER

במסד נתונים של MySQL, סוגי הנתונים BOOL ו-BOOLEAN מאוחסנים באופן פנימי כ-TINYINT(1), שתומך בערכים בטווח שבין -128 ל-127. לכן, סוגי הנתונים BOOL ו-BOOLEAN ממופים ל-INTEGER כשהם מועברים ל-BigQuery. מידע נוסף זמין במאמר בנושא תחביר של סוגי נתונים מספריים.
SMALLINT INTEGER
MEDIUMINT INTEGER
INT, INTEGER INTEGER
BIGINT BIGNUMERIC
FLOAT FLOAT
DOUBLE FLOAT
DECIMAL BIGNUMERIC
DATE DATE
DATETIME TIMESTAMP DATETIME
TIMESTAMP TIMESTAMP
TIME TIME
YEAR DATE
CHAR STRING
VARCHAR STRING
BINARY BYTES
VARBINARY BYTES
TINYBLOB BYTES
TINYTEXT STRING
BLOB BYTES
TEXT STRING
MEDIUMBLOB BYTES
MEDIUMTEXT STRING
LONGBLOB BYTES
LONGTEXT STRING
ENUM STRING
SET STRING
JSON STRING JSON
GEOMETRY BYTES GEOGRAPHY

תמחור

למידע על תמחור העברות של MySQL, אפשר לעיין במאמר בנושא תמחור של שירות העברת נתונים.

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