Writes

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

‫Bigtable Data API וספריות הלקוח מאפשרים לכם לכתוב נתונים לטבלאות באופן פרוגרמטי. ‫Bigtable שולח בחזרה תגובה או אישור לכל פעולת כתיבה.

כל ספריית לקוח מאפשרת לשלוח את סוגי בקשות הכתיבה הבאים:

  • כתיבות פשוטות
  • הוספה והגדלה
  • כתיבה מותנית
  • כתיבה באצווה

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

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

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

דוגמאות של בקשות כתיבה בספריית הלקוח Cloud Bigtable שמתוארות בדף הזה מופיעות במאמר דוגמאות לכתיבה.

סוגי פעולות כתיבה ומתי כדאי להשתמש בהן

כל בקשות הכתיבה כוללות את הרכיבים הבסיסיים הבאים:

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

חותמת הזמן של מוטציה מקבלת כברירת מחדל את התאריך והשעה הנוכחיים, שנמדדים כזמן שחלף מאז ראשית זמן יוניקס, 00:00:00 UTC ב-1 בינואר 1970.

חותמת זמן ששולחים ל-Bigtable צריכה להיות ערך במיקרו-שנייה עם דיוק של מילי-שנייה לכל היותר. חותמת זמן עם דיוק של מיקרו-שנייה, כמו 3023483279876543, נדחית. בדוגמה הזו, ערך חותמת הזמן הקביל הוא 3023483279876000.

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

כתיבה פשוטה

אפשר לכתוב שורה אחת ל-Bigtable באמצעות MutateRow בקשה שכוללת את שם הטבלה, את המזהה של פרופיל האפליקציה שבו רוצים להשתמש, מפתח שורה ועד 100,000 שינויים בשורה הזו. פעולת כתיבה של שורה אחת היא אטומית. משתמשים בסוג הכתיבה הזה כשמבצעים כמה שינויים בשורה אחת.

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

מתי לא כדאי להשתמש בכתיבות פשוטות

כתיבות פשוטות הן לא הדרך הכי טובה לכתוב נתונים בתרחישי השימוש הבאים:

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

  • אתם רוצים תפוקה גבוהה (שורות לשנייה או בייטים לשנייה) ולא צריכים השהיה נמוכה. במקרה כזה, כתיבה בקבוצות תהיה מהירה יותר.

עדכונים מצטברים

ב-Bigtable אפשר ליצור תאים עם סוג נתונים של aggregate. תאים מצטברים מותאמים למקרים שבהם רוצים לשנות את הערכים בתאים קיימים בטבלה, ולצבור את ערכי התאים בזמן כתיבת הנתונים. אלה סוגי הצבירה שזמינים:

  • ‫Sum – הגדלה של מונה או שמירה של סכום מצטבר.
  • ‫Minimum – שולחים מספר שלם לתא, ו-Bigtable שומר את הערך הנמוך מבין שני הערכים.
  • ‫Maximum – שולחים מספר שלם לתא, ו-Bigtable שומר את הערך הגבוה מבין שני הערכים.
  • ‫HyperLogLog (HLL) – שליחת ערך שנוסף לקבוצה הסתברותית של כל הערכים שנוספו לתא.

בקשות לעדכון תאים מצטברים נשלחות עם MutateRow בקשה וסוג מוטציה של AddToCell או MergeToCell או אחד מסוגי המוטציה של מחיקה.

הוספה

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

הכללים חלים לפי הסדר. לדוגמה, אם הבקשה כוללת בקשה להוספת הערך של עמודה שמכילה את הערך some עם המחרוזת thing, וכלל מאוחר יותר באותה בקשה מוסיף לאותה עמודה את הערך body, הערך ישתנה פעמיים בפעולת כתיבה אטומית אחת, והערך שיתקבל יהיה somethingbody. הכלל המאוחר יותר לא מחליף את הכלל המוקדם יותר.

אפשר גם להגדיל מספר שלם באמצעות קריאה ReadModifyWriteRow, אבל מומלץ להשתמש בתאים מצטברים וב-AddToCell או ב-MergeToCell במקום זאת. אפשר להגדיל ערך באמצעות ReadModifyWrite רק אם הוא מקודד כמספר שלם חתום בפורמט big-endian של 64 ביט. ב-Bigtable, פעולת הגדלה של ערך ריק או לא קיים נחשבת כאילו הערך הוא אפס.

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

מתי לא מומלץ להשתמש בReadModifyWriteRow

אל תשלחו בקשות ReadModifyWriteRow במקרים הבאים:

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

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

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

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

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

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

כתיבה מותנית

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

בקשת סינון חייבת לכלול סוג אחד או שניים של מוטציות מהסוגים הבאים:

  • מוטציות אמיתיות, או המוטציות שיש להחיל אם המסנן מחזיר ערך.
  • מוטציות שגויות, שמוחלות אם המסנן לא מחזיר כלום.

אפשר לספק עד 100,000 מכל סוג של מוטציה – true ו-false – בפעולת כתיבה אחת, וחובה לשלוח לפחות אחת. ‫Bigtable שולח תגובה כשהמוטציות מסתיימות.

בגלל שפעולת כתיבה מותנית קוראת את השורה כדי להעריך את המסנן, למבצע הקריאה צריכות להיות הרשאות bigtable.tables.readRows ו-bigtable.tables.mutateRows בטבלה (או הרשאות bigtable.authorizedViews.readRows ו-bigtable.authorizedViews.mutateRows שוות ערך בתצוגה מורשית). מידע נוסף מופיע במאמר בנושא בקרת גישה.

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

מתי לא כדאי להשתמש בכתיבה מותנית

אי אפשר להשתמש בכתיבה מותנית בתרחיש השימוש הבא:

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

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

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

כתיבה באצווה

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

  • ‫100,000 ערכים עם מוטציה אחת בכל ערך.
  • ערך אחד עם 100,000 מוטציות.
  • ‫1,000 רשומות עם 100 מוטציות לכל רשומה.

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

דוגמאות קוד שמראות איך לשלוח כתיבות באצ' מופיעות במאמר ביצוע כתיבות באצ'.

מתי לא כדאי להשתמש בכתיבה של קבוצות פריטים

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

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

בקרה על זרימת נתונים בכתיבה של נתונים בכמות גדולה

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

כשמפעילים בקרת זרימה של כתיבת אצווה למשימת Dataflow, Bigtable מבצע באופן אוטומטי את הפעולות הבאות :

  • הגבלת קצב התנועה כדי למנוע עומס יתר על אשכול Bigtable
  • הבדיקה מוודאת שהעומס על האשכול מספיק כדי להפעיל את ההתאמה האוטומטית לעומס (automatic scaling) של Bigtable (אם הוא מופעל), כך שיוספו לאשכול עוד צמתים באופן אוטומטי כשצריך

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

אתם צריכים להשתמש בפרופיל אפליקציה שהוגדר לניתוב לאשכול יחיד. הפעלת התאמה אוטומטית לעומס (autoscaling) ב-Bigtable באשכול היעד היא לא חובה, אבל היא מאפשרת לכם לנצל את היתרונות של בקרת זרימת כתיבת אצווה. אפשר להשתמש בהתאמה אוטומטית לעומס (automatic scaling) של Dataflow בדיוק כמו בכל עבודה אחרת.

מידע נוסף על התאמה אוטומטית לעומס (automatic scaling) ב-Bigtable זמין במאמר בנושא התאמה אוטומטית לעומס (automatic scaling). כדי להבין את מדיניות הניתוב של פרופילים של אפליקציות, אפשר לעיין במאמר סקירה כללית על פרופילים של אפליקציות.

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

כתיבת נתונים לתצוגה מורשית

כדי לכתוב נתונים לתצוגה מורשית, צריך להשתמש באחת מהאפשרויות הבאות:

  • ‫CLI של gcloud
  • לקוח Bigtable ל-Java

ספריות הלקוח האחרות של Bigtable עדיין לא תומכות בגישה לתצוגות מורשות.

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

כל פעולות הכתיבה לתצוגה מורשית מוחלות ישירות על הטבלה הבסיסית.

הגבלות על הגדרות של תצוגות מורשות

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

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

באופן דומה, אם התצוגה המורשית מוגדרת על ידי הקידומת של מסווג העמודה order-phone, אפשר לכתוב נתונים באמצעות מסווג העמודה order-phone123, אבל אי אפשר להשתמש במסווג העמודה order-tablet.

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

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

שכפול

כשמתקבלת פעולת כתיבה באחד מאשכולות המופע המשוכפל, היא משוכפלת מיד לאשכולות האחרים במופע.

אטומיות

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

עקביות

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

במופע עם אשכול אחד, אפשר לקרוא את הנתונים באופן מיידי, אבל אם במופע יש יותר מאשכול אחד, כלומר נעשה בו שימוש בשכפול, Bigtable הוא מודל עקביות הדרגתי. כדי להשיג עקביות של קריאה-כתיבה, אפשר להפנות בקשות לאותו אשכול.

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

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

פתרון התנגשויות

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

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