טרנספורמציה של נתונים באמצעות שפת טיפול בנתונים (DML)

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

אפשר להריץ פקודות DML בדיוק כמו שמריצים פקודות SELECT, בתנאים הבאים:

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

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

מגבלות

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

  • אי אפשר לשנות שורות שנכתבו לאחרונה באמצעות שיטת הסטרימינג tabledata.insertall באמצעות שפת מניפולציה של נתונים (DML), כמו פקודות UPDATE,‏ DELETE,‏ MERGE או TRUNCATE. הפעולות האחרונות של כתיבה הן אלה שהתרחשו ב-30 הדקות האחרונות. אפשר לשנות את כל השורות האחרות בטבלה באמצעות הצהרות UPDATE,‏ DELETE,‏ MERGE או TRUNCATE. יכול להיות שיחלפו עד 90 דקות עד שהנתונים שמוזרמים יהיו זמינים לפעולות העתקה.

    לחלופין, אפשר לשנות שורות שנכתבו לאחרונה באמצעות Storage Write API באמצעות פקודות UPDATE,‏ DELETE או MERGE. מידע נוסף זמין במאמר שימוש בשפת טיפול בנתונים (DML) עם נתונים שהועברו לאחרונה בסטרימינג.

  • אין תמיכה בשאילתות משנה קשורות בתוך when_clause, ‏ search_condition,‏ merge_update_clause או merge_insert_clause בהצהרות MERGE.

  • בשאילתות שמכילות הצהרות DML אי אפשר להשתמש בטבלת wildcard כיעד של השאילתה. לדוגמה, אפשר להשתמש בטבלת תו כללי לחיפוש בסעיף FROM של שאילתת UPDATE, אבל אי אפשר להשתמש בטבלת תו כללי לחיפוש כיעד של פעולת UPDATE.

פקודות DML

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

INSERT דוח

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

INSERT dataset.Inventory (product, quantity)
VALUES('whole milk', 10),
      ('almond milk', 20),
      ('coffee beans', 30),
      ('sugar', 0),
      ('matcha', 20),
      ('oat milk', 30),
      ('chai', 5)

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       20 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       30 |
 | sugar             |        0 |
 | whole milk        |       10 |
 +-------------------+----------+/

מידע נוסף על פקודות INSERT זמין במאמר בנושא פקודת INSERT.

DELETE דוח

משתמשים בהצהרת DELETE כדי למחוק שורות בטבלה. בדוגמה הבאה, כל השורות בטבלה dataset.Inventory עם הערך quantity 0 נמחקות.

DELETE dataset.Inventory
WHERE quantity = 0

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       20 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       30 |
 | whole milk        |       10 |
 +-------------------+----------+/

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

TRUNCATE דוח

משתמשים בהצהרת TRUNCATE כדי להסיר את כל השורות מטבלה, אבל להשאיר את המטא-נתונים של הטבלה ללא שינוי, כולל סכימת הטבלה, התיאור והתוויות. בדוגמה הבאה מוסרות כל השורות מהטבלה dataset.Inventory.

TRUNCATE dataset.Inventory

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

UPDATE דוח

משתמשים בהצהרת UPDATE כדי לעדכן שורות קיימות בטבלה. ההצהרה UPDATE צריכה לכלול גם את מילת המפתח WHERE כדי לציין תנאי. בדוגמה הבאה, הערך של quantity בשורות יופחת ב-10 למוצרים שמכילים את המחרוזת milk.

UPDATE dataset.Inventory
SET quantity = quantity - 10,
WHERE product LIKE '%milk%'

/+-------------------+----------+
 |      product      | quantity |
 +-------------------+----------+
 | almond milk       |       10 |
 | chai              |        5 |
 | coffee beans      |       30 |
 | matcha            |       20 |
 | oat milk          |       20 |
 | whole milk        |        0 |
 +-------------------+----------+/

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

MERGE דוח

ההצהרה MERGE משלבת את הפעולות INSERT, ‏ UPDATE ו-DELETE בהצהרה אחת, ומבצעת את הפעולות באופן אטומי כדי למזג נתונים מטבלה אחת לטבלה אחרת. מידע נוסף ודוגמאות לגבי MERGEדף החשבון זמינים במאמר MERGEדף החשבון.

משימות מקבילות

מערכת BigQuery מנהלת את המקבילות של הצהרות DML שמוסיפות, משנות או מוחקות שורות בטבלה.

נסו שוב לבצע את הפעולה באמצעות נסיגה אקספוננציאלית בין הניסיונות.

בו-זמניות של פקודות DML מסוג INSERT

במהלך כל תקופה של 24 שעות, 1,500 ההצהרות הראשונות של INSERT מופעלות מיד אחרי שהן נשלחות. אחרי שמגיעים למגבלה הזו, מספר ההצהרות בו-זמנית של INSERT שכותבות לטבלה מוגבל ל-10. הצהרות נוספות של INSERT מתווספות לתור של PENDING. אפשר להוסיף לתור עד 100 הצהרות לכל טבלה בכל זמן נתון.INSERT כשINSERTהצהרה מסתיימת, ההצהרה הבאה INSERTמוסרת מהתור ומופעלת.

אם אתם צריכים להריץ הצהרות DML INSERT בתדירות גבוהה יותר, כדאי להשתמש ב-Storage Write API כדי להזרים נתונים לטבלה.

בו-זמניות (concurrency) של פקודות DML מסוג UPDATE,‏ DELETE ו-MERGE

פקודות ה-DML‏ UPDATE, DELETE ו-MERGE נקראות פקודות DML משנות. אם שולחים הצהרת DML אחת או יותר לשינוי טבלה בזמן שמשימות DML אחרות לשינוי הטבלה עדיין פועלות (או בהמתנה), מערכת BigQuery מריצה עד 2 מהן בו-זמנית, ואז עד 20 משימות נוספות מוכנסות לתור כPENDING. כשמשימה שהייתה בהמתנה מסתיימת, המשימה הבאה בתור מוצאת מהתור ומופעלת. הצהרות DML לשינוי בתור משתפות תור לכל טבלה באורך מקסימלי של 20. הצהרות נוספות מעבר לאורך התור המקסימלי של כל טבלה נכשלות עם הודעת השגיאה: Resources exceeded during query execution: Too many DML statements outstanding against table PROJECT_ID:DATASET.TABLE, limit is 20.

משימות DML אינטראקטיביות בעדיפות גבוהה שנמצאות בתור יותר מ-7 שעות נכשלות עם הודעת השגיאה הבאה:

DML statement has been queued for too long

התנגשויות בפקודות DML

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

  • פקודת INSERT DML שמוסיפה שורות לטבלה לא מתנגשת עם אף פקודת DML אחרת שמופעלת במקביל.

  • פקודת MERGE DML לא מתנגשת עם פקודות DML אחרות שפועלות בו-זמנית, כל עוד הפקודה רק מוסיפה שורות ולא מוחקת או מעדכנת שורות קיימות. זה יכול לכלול הצהרות MERGE עם סעיפים UPDATE או DELETE, כל עוד הסעיפים האלה לא מופעלים כשהשאילתה מופעלת.

DML פרטני

DML ברמת גרנולריות גבוהה הוא שיפור ביצועים שנועד לייעל את הביצוע של פקודות UPDATE, DELETE ו-MERGE (שנקראות גם פקודות DML משתנות).

שיקולי ביצועים

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

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

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

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

הפעלת DML ברמת דיוק גבוהה

כדי להפעיל DML ברמת גרנולריות גבוהה, מגדירים את האפשרות enable_fine_grained_mutations של הטבלה לערך TRUE כשמריצים הצהרת DDL מסוג CREATE TABLE או ALTER TABLE.

כדי ליצור טבלה חדשה עם DML ברמת גרנולריות גבוהה, משתמשים בהצהרה CREATE TABLE:

CREATE TABLE mydataset.mytable (
  product STRING,
  inventory INT64)
OPTIONS(enable_fine_grained_mutations = TRUE);

כדי לשנות טבלה קיימת באמצעות DML ברמת גרנולריות גבוהה, משתמשים במשפט ALTER TABLE:

ALTER TABLE mydataset.mytable
SET OPTIONS(enable_fine_grained_mutations = TRUE);

כדי לשנות את כל הטבלאות הקיימות במערך נתונים באמצעות DML מפורט, משתמשים בהצהרת ALTER TABLE: 

FOR record IN
 (SELECT CONCAT(table_schema, '.', table_name) AS table_path
 FROM mydataset.INFORMATION_SCHEMA.TABLES)
DO
 EXECUTE IMMEDIATE
   "ALTER TABLE " || record.table_path || " SET OPTIONS(enable_fine_grained_mutations = TRUE)";
END FOR;

אחרי שהאפשרות enable_fine_grained_mutations מוגדרת לערך TRUE, פקודות DML לשינוי נתונים מופעלות עם יכולות DML ברמת פירוט גבוהה, ומשתמשות בתחביר הקיים של פקודות DML.

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

SELECT
  table_schema AS datasetId,
  table_name AS tableId,
  is_fine_grained_mutations_enabled
FROM
  DATASET_NAME.INFORMATION_SCHEMA.TABLES;

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

השבתה של DML עם גרנולריות גבוהה

כדי להשבית DML ברמת גרנולריות גבוהה מטבלה קיימת, משתמשים בהצהרת ALTER TABLE.

ALTER TABLE mydataset.mytable
SET OPTIONS(enable_fine_grained_mutations = FALSE);

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

תמחור

הפעלת DML ברמת דיוק גבוהה בטבלה עלולה להיות כרוכה בעלויות נוספות. העלויות האלה כוללות:

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

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

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

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

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

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

שיקולים לגבי נתונים שנמחקו

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

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

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

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

התזמון של משימות איסוף נתונים מיותרים שהועברו נקבע לפי התדירות של פעילות DML בטבלה והזמינות של המשאבים, אם משתמשים בהקצאה של BACKGROUND:

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

כדי לזהות משימות עיבוד של נתונים שנמחקו מ-DML גרנולרי שהועברו, מריצים שאילתה בתצוגה INFORMATION_SCHEMA.JOBS: 

SELECT
  *
FROM
  region-us.INFORMATION_SCHEMA.JOBS
WHERE
  job_id LIKE "%fine_grained_mutation_garbage_collection%"

מגבלות

הטבלאות שמופעל בהן DML ברמת גרנולריות גבוהה כפופות למגבלות הבאות:

  • לא מומלץ להשתמש ב-DML ברמת גרנולריות גבוהה בטבלאות גדולות עם מחיצות שעוברות שינויים לעיתים קרובות, אם גודלן עולה על 2TB. יכול להיות שיהיה עומס זיכרון נוסף בטבלאות האלה בשאילתות הבאות, מה שעלול להוביל לזמן טעינה ארוך יותר או לשגיאות בשאילתות.
  • אפשר להריץ רק הצהרת DML אחת שמשנה נתונים בכל פעם בטבלה שמופעל בה DML ברמת דיוק גבוהה. משימות עוקבות מתווספות לתור כ-PENDING. מידע נוסף על התנהגות בו-זמנית של DML עם שינויים זמין במאמר בנושא בו-זמניות של DML עם UPDATE,‏ DELETE ו-MERGE.
  • אי אפשר למחוק או לשכתב מחיצות בטבלה שמופעל בה DML עם הרשאות גישה ברמת השורה. כדי למחוק או להחליף נתונים במחיצה, צריך להשתמש בהצהרת DML משנה, כמו DELETE,‏ UPDATE,‏ MERGE או TRUNCATE.
  • אי אפשר להשתמש בשיטה tabledata.list כדי לקרוא תוכן מטבלה שמופעל בה DML עם הרשאות גישה ברמת השורה. במקום זאת, שולחים שאילתה לטבלה באמצעות הצהרת SELECT כדי לקרוא רשומות בטבלה.
  • אי אפשר לראות תצוגה מקדימה של טבלה שמופעל בה DML ברמת גרנולריות גבוהה באמצעות מסוף BigQuery.
  • אי אפשר להעתיק טבלה עם DML ברמת דיוק גבוהה שמופעל אחרי הפעלת פקודת UPDATE, DELETE או MERGE.
  • אי אפשר ליצור תמונת מצב של טבלה או שיבוט של טבלה עם DML ברמת דיוק גבוה שהופעל אחרי הפעלת פקודת UPDATE, DELETE או MERGE.
  • אי אפשר לשנות את השם של טבלה עם DML ברמת דיוק גבוהה אחרי שמריצים פקודת UPDATE, DELETE או MERGE.
  • אין תמיכה בשכפול בין אזורים לטבלאות שמופעל בהן DML ברמת גרנולריות גבוהה. המערכת חוסמת יצירה של מערכי נתונים משוכפלים שכבר מכילים טבלאות כאלה, אבל היא לא חוסמת הפעלה של DML עם הרשאות גישה ברמת הטבלה בטבלאות בתוך מערכי נתונים משוכפלים קיימים. עם זאת, פעולה כזו עלולה לגרום לתוצאות שגויות בשאילתות בטבלה המשנית שמופעל בה DML ברמת דיוק גבוהה.
  • פקודות DML שמופעלות בעסקה עם כמה פקודות לא עוברות אופטימיזציה באמצעות DML מדויק.
  • אי אפשר להפעיל DML ברמת דיוק גבוהה בטבלאות זמניות שנוצרו באמצעות ההצהרה CREATE TEMP TABLE.
  • מטא-נתונים המשתקפים בתוך התצוגות והתצוגות והתצוגות יכולות לכלול באופן זמני נתונים שנמחקו לאחרונה באמצעות DML מפורט עד שמשימות איסוף האשפה ברקע יושלמו.

שיטות מומלצות

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

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

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

  • לא מומלץ לחלק טבלאות למחיצות אם כמות הנתונים בכל מחיצה קטנה, ואם כל עדכון משנה חלק גדול מהמחיצות.

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

    UPDATE mydataset.mytable
SET string_col = 'some string'
WHERE id BETWEEN 54 AND 75;

    הנה דוגמה דומה שמסננת רשימה קטנה של ערכי עמודות:

    UPDATE mydataset.mytable
SET string_col = 'some string'
WHERE id IN (54, 57, 60);

    במקרים כאלה, כדאי לשקול לבצע אשכול על העמודה id.

  • אם אתם צריכים פונקציונליות של OLTP, כדאי להשתמש בשאילתות מאוחדות של Cloud SQL, שמאפשרות ל-BigQuery לשלוח שאילתות לנתונים שמאוחסנים ב-Cloud SQL.

  • כדי לפתור את שגיאת המכסה Too many DML statements outstanding against table, ולמנוע אותה, צריך לפעול לפי ההנחיות לפתרון השגיאה בדף פתרון בעיות ב-BigQuery.

שיטות מומלצות לאופטימיזציה של ביצועי השאילתות מפורטות במאמר מבוא לאופטימיזציה של ביצועי השאילתות.

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