כותב

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

ה-API של נתוני Bigtable וספריות הלקוח מאפשרים לכם לכתוב נתונים לטבלאות באופן פרוגרמטי. ‫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 שולח תגובה כשהמוטציות מסתיימות.

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

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

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

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

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

  • אתם כותבים כמויות גדולות של נתונים וצריכים שהכתיבה תסתיים במהירות. בדומה לבקשות 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 בדיוק כמו בכל עבודה אחרת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שכפול

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

אטומיות

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

עקביות

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

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

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

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

יישוב סכסוכים

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

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