כתיבה

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

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

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

  • כתיבה פשוטה
  • הוספה וצירוף
  • כתיבה מותנית
  • כתיבה באצווה

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

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

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

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

סוגי כתיבה ומתי להשתמש בהם

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

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

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

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

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

כתיבה פשוטה

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

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

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

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

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

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

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

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

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

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

הוספה

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

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

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

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

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

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

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

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

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

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

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

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

כתיבה מותנית

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

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

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

אפשר לספק עד 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 באשכול היעד, אבל ההתאמה האוטומטית לעומס מאפשרת לכם לנצל את כל היתרונות של בקרת הזרימה של כתיבה באצווה. אתם יכולים להשתמש בהתאמה אוטומטית לעומס (autoscaling) של Dataflow בדיוק כמו בכל משימה אחרת.

מידע נוסף על התאמה אוטומטית לעומס ב-Bigtable במאמר סקירה כללית על פרופילי אפליקציות מוסבר על מדיניות הניתוב של פרופילי אפליקציות.

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

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

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

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

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

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

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

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

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

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

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

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

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

רפליקציה

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

אטומיות

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

עקביות

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

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

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

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

פתרון מחלוקות

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

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