קריאות

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

סקירה כללית

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

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

  • קריאת שורה אחת
  • סריקות או קריאה של כמה שורות

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

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

קריאת נתונים באמצעות מחשוב ללא שרת (serverless) של Data Boost

התכונה Bigtable Data Boost מאפשרת להריץ משימות קריאה עם תפוקה גבוהה בלי להשפיע על תעבורת הנתונים של האפליקציות בנתיב ההגשה. ‫Data Boost הוא שירות מחשוב ללא שרתים שבו אפשר להשתמש כדי לקרוא את הנתונים ב-Bigtable בזמן שאפליקציית הליבה משתמשת בצמתי האשכול למחשוב. ב-Enterprise Plus, היכולת של Data Boost לשליחת שאילתות מתרחבת עם תמיכה ב-SQL וגישה לנתונים באחסון HDD ובאחסון מדורג.

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

קריאה של שורה אחת

אפשר לבקש שורה אחת על סמך מפתח השורה. קריאות של שורה אחת, שנקראות גם קריאות נקודתיות, לא תואמות ל-Data Boost. דוגמאות קוד זמינות לגרסאות הבאות:

סריקות

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

סריקות הפוכות

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

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

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

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

כדי לסרוק בסדר הפוך, מגדירים את הערך של השדה ReadRowsRequest reversed ל-true. ברירת המחדל היא False.

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

  • ספריית הלקוח של Bigtable ל-C++ בגרסה 2.18.0 ואילך
  • ספריית לקוח של Bigtable ל-Go בגרסה 1.21.0 ואילך
  • ספריית לקוח Bigtable ל-Java גרסה 2.24.1 ואילך
  • ‫Bigtable HBase client for Java גרסה 2.10.0 ואילך

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

דוגמאות לתרחישי שימוש

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

איפוס סיסמאות

נניח שכל אחד ממפתחות השורה מכיל מספר לקוח ותאריך, בפורמט 123ABC#2022-05-02, ואחת מהעמודות היא password_reset, שבה מאוחסנת השעה שבה הסיסמה אופסה. ‫Bigtable מאחסן את הנתונים באופן אוטומטי לפי סדר מילוני, כמו בדוגמה הבאה. שימו לב: העמודה לא קיימת בשורות (ימים) שבהן הסיסמה לא אופסה.

`123ABC#2022-02-12,password_reset:03`
`123ABC#2022-04-02,password_reset:11`
`123ABC#2022-04-14`
`123ABC#2022-05-02`
`223ABC#2022-05-22`

אם רוצים לדעת מתי בפעם האחרונה הלקוח 123ABC איפס את הסיסמה שלו, אפשר לסרוק הפוך טווח של 123ABC# עד 123ABC#<DATE>, באמצעות התאריך של היום או תאריך עתידי, עבור כל השורות שמכילות את העמודה password_reset עם מגבלת שורות של 1.

שינויים במחירים

בדוגמה הזו, מפתחות השורות מכילים ערכים של product,‏ model ו-timestamp, ואחת מהעמודות מכילה את המחיר של המוצר והדגם בזמן מסוים.

`productA#model2#1675604471,price:82.63`
`productA#model2#1676219411,price:82.97`
`productA#model2#1677681011,price:83.15`
`productA#model2#1680786011,price:83.99`
`productA#model2#1682452238,price:83.12`

אם רוצים למצוא תנודות במחיר סביב המחיר ב-14 בפברואר 2023, גם אם מפתח השורה של התאריך הזה לא קיים בטבלה, אפשר לבצע סריקה קדימה החל ממפתח השורה productA#model2#1676376000 למספר N של שורות, ואז לבצע סריקה הפוכה למספר זהה של שורות מאותה שורת התחלה. שתי הסריקות יציגו את המחירים לפני ואחרי הזמן שצוין.

אפשרויות קריאה מסוננות

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

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

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

קריאת נתונים מתצוגה מורשית

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

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

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

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

קריאת נתונים מתצוגה חומרית רציפה

אפשר לקרוא נתונים מתצוגה חומרית מתמשכת באמצעות SQL או קריאה ל-ReadRows Data API. תצוגות מהותיות רציפות הן לקריאה בלבד. הנתונים בתצוגה חומרית מוקלדים על סמך השאילתה שמגדירה אותה.

SQL

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

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

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

Data API

אם אתם מתכננים לקרוא מתצוגה חומרית רציפה באמצעות קריאה ReadRows מאחת מספריות הלקוח של Bigtable, כדאי לבדוק את שאילתת ה-SQL שמשמשת להגדרת התצוגה. כדאי לשים לב אם בתצוגה יש עמודה מוגדרת של _key, שמומלצת לתצוגות שנועדו לקריאה באמצעות ReadRows, ואם יש בה עמודה של _timestamp.

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

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

סוג קידוד
BOOL ערך של בייט אחד, 1 = true, ‏ 0 = false
BYTES ללא קידוד
‫INT64 (או INT, ‏ SMALLINT, ‏ INTEGER, ‏ BIGINT, ‏ TINYINT, ‏ BYTEINT) ‫64 ביט big-endian
FLOAT64 ‫IEEE 754‏ 64 ביט, לא כולל NaN ו-‎+/-inf
מחרוזת UTF-8
TIME/TIMESTAMP מספר שלם ב-64 ביט שמייצג את מספר המיקרו-שניות מאז ראשית זמן יוניקס (Unix epoch) (עקבי עם GoogleSQL)
מידע נוסף זמין במאמר קידוד בהפניית API של Data API.

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

SELECT
  _key,
  SUM(clicks) AS sum_clicks
FROM
  mytable
GROUP BY
  sum_clicks

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

קריאות וביצועים

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

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

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

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

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

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

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

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

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

שורות גדולות

מערכת Bigtable אוכפת את המגבלות הבאות שחלות על שורות גדולות:

  • הגודל המקסימלי של שורה הוא 256MB. אם אתם צריכים לקרוא שורה שהפכה לגדולה יותר מהמגבלה, אתם יכולים להשתמש במספור עמודים בבקשה, במסנן cells per row limit ובמסנן cells per row offset. חשוב לדעת שאם פעולת כתיבה מגיעה לשורה בין בקשות קריאה עם חלוקה לדפים, יכול להיות שהקריאה לא תהיה אטומית.

  • הגודל המקסימלי של קריאה ל-API של ReadRows הוא 512KB. אם תחרגו מהמגבלה, Bigtable יחזיר שגיאה מסוג INVALID_ARGUMENT.

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