שדות גרוסים

בדף הזה מוסבר איך לראות ולשלוט בשימוש בשדות מפורקים ב-Cloud Firestore. האפשרות הזו זמינה במהדורת Enterprise של Firestore.

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

שאילתות שיכולות להפיק תועלת משדות מפורקים

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

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

  db.pipeline()
    .collection("/customers")
    .where(lessThan("account_balance", 0))
    .aggregate(
      countAll().as("total"),
    )
  

  או עם group-by:

  db.pipeline()
    .collection("/customers")
    .where(lessThan("account_balance", 0))
    .aggregate({
      accumulators: [
        field('account_balance').average().as('avg_account_balance')
      ],
      groups: [field('market_segment')]
    })
  

• שאילתות תחזית: שאילתות שמחזירות רק קבוצת משנה ספציפית של שדות. לדוגמה:

  db.pipeline()
    .collection("/customers")
    .select("family_name", "given_name")
    .limit(10)
  

• סינון שאילתות: שאילתות שבהן מנוע השאילתות Cloud Firestore קובע שמועיל להשתמש בשדות מפורקים לסינון מסמכים. לדוגמה:

  db.pipeline()
    .collection("/customers")
    .where(equal("given_name", "alice"))
  

צפייה בשימוש בשדות שגורסים

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

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

פלט לדוגמה

...
└── • TableScan
        source: /customers
        order: UNDEFINED
        row range: (-∞..+∞)
        filter: ($account_balance_1 < 0L)
        output bindings: {$account_balance_1=account_balance, $market_segment_1=market_segment}
        variables: [$account_balance_1, $market_segment_1]

        Execution:
         records returned: 1,374
         latency: 26.58 ms
         post-filtered rows: 13,626
         records scanned: 15,000
         data bytes read: 23.73 MiB (24,887,141 B)

        Storage:
         scan shape: shredded_fields_only
         shredded fields used: [account_balance, market_segment]

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

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

ערכים נתמכים לאפשרות table_scan_method:

• shredded_fields_enabled (ברירת מחדל): שימוש בשדות מפורקים כשהם זמינים.
• ‫shredded_fields_disabled: אל תשתמשו בשדות מפורקים.
• ‫force_shredded_fields: השאילתה תיכשל אם לא ניתן לבצע סריקה של טבלה על ידי סריקת שדות מפורקים.

דוגמה

var opts = new PipelineExecuteOptions()
    .with("table_scan_method", "shredded_fields_disabled");

var snapshot = db.pipeline()
    .collection("/customers")
    .where(equal("given_name", "alice"))
    .execute(opts)
    .get();

אזהרות לגבי ביצועי שאילתות

יכול להיות ש-Cloud Firestore יציג אזהרות לגבי ביצועים בתוצאת ההסבר של השאילתה אם הוא יזהה שימוש לא יעיל בשדה מפורק. לדוגמה:

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

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

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

מגבלות

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