Google מרחיבה את הנגישות לניתוח גרפים: החל מ־6 בנובמבר 2026 אפשר להריץ שאילתות Graph Query Language (GQL) ב־BigQuery Graph גם במסגרת תמחור לפי דרישה. עד כה דרישות המהדורה וה־Reservations הפכו את הכניסה ליכולת למורכבת יותר עבור צוותים שלא רצו להתחייב לקיבולת.
מה השתנה בתמחור?
לפי הערות הגרסה של Google Cloud, BigQuery Graph ושאילתות GQL זמינות כעת גם ללקוחות המשתמשים ב־on-demand pricing. בתיעוד המוצר מצוין כי ניתן להריץ GQL באמצעות תמחור לפי דרישה או באמצעות Reservation במהדורות Enterprise ו־Enterprise Plus.
המשמעות המעשית היא שצוות יכול להתחיל ניסוי גרף ללא הקמת Reservation ייעודי. העלות עדיין תלויה באופן שבו BigQuery מחייבת את עבודת השאילתה, ולכן חשוב להפעיל בקרות על היקף הנתונים, לעקוב אחר Bytes processed ולהגדיר תקציבים והתראות.
מהו BigQuery Graph?
BigQuery Graph מאפשר לייצג ישויות כצמתים ואת הקשרים ביניהן כקשתות. אפשר לבנות Node tables ו־Edge tables מעל טבלאות או Views קיימים, בלי לשכפל את הנתונים למסד גרפים נפרד. לאחר מכן משתמשים ב־GQL כדי לחפש דפוסי קשרים שקשה לבטא בעזרת Self Joins או שאילתות רקורסיביות ב־SQL.
הממשק תואם לעקרונות תקן ISO GQL ומשתלב עם המודל היחסי של BigQuery. כך אפשר לשלב שאילתות SQL עם התאמת דפוסים בגרף, ולהשתמש גם בחיפוש וקטורי ובחיפוש טקסט מלא כאשר המקרה דורש זאת.
איפה זה יכול לעזור?
- זיהוי הונאות: איתור קשרים לא צפויים בין משתמשים, חשבונות, מכשירים ועסקאות.
- Customer 360: חיבור בין לקוחות, רכישות, העדפות וערוצי תקשורת לצורך המלצות.
- שרשרת אספקה: מעקב אחרי קשרים בין חלקים, ספקים, הזמנות ותקלות.
- Lineage וממשל נתונים: הבנת ההשפעה של שינוי בטבלה, View או Pipeline על נכסים תלויים.
- GraphRAG וסוכני AI: שילוב ידע וקשרים כדי לשפר את ההקשר של תשובות ומסלולי החלטה.
מה לא משתנה
היכולת להריץ GQL לפי דרישה אינה הופכת כל עומס גרף לזול או פשוט. שאילתות על רשתות צפופות עלולות לסרוק כמויות גדולות של נתונים, ומודל גרף לא נכון יכול להקשות על התחזוקה. בנוסף, זמינות התכונה עשויה להשתנות לפי סוג ה־Reservation והמהדורה, ולכן ארגונים המשתמשים בקיבולת שמורה צריכים לבדוק את התאימות שלהם.
בצד האחסון, Google מציינת שחיוב האחסון חל פעם אחת על הטבלאות הבסיסיות שמגדירות את הגרף. אין חיוב אחסון נפרד עבור כל מודל גרף שנבנה מעל אותם נתונים, אך עלויות שאילתה ושירותים נלווים עדיין חלות.
כך כדאי להתחיל
- לבחור קשר עסקי אחד: למשל משתמש–מכשיר–עסקה, ולא לנסות למפות את כל הארגון.
- להגדיר מפתחות יציבים: צמתים וקשתות דורשים מזהים עקביים ואיכות נתונים טובה.
- להריץ שאילתת בסיס קטנה: להגביל עומק ודפוס, ולבדוק את העלות לפני הרחבה.
- להשוות ל־SQL: למדוד אם GQL באמת מקצר את הלוגיקה ומשפר את התחזוקה.
- להוסיף בקרת עלויות: תקציבים, התראות ובדיקת היקף הסריקה לפני העברה לייצור.
השורה התחתונה
פתיחת BigQuery Graph לתמחור לפי דרישה מורידה חסם כניסה משמעותי. ארגונים יכולים לבדוק GQL על נתונים קיימים בלי לבנות מערכת גרף נפרדת ובלי להתחייב מיד לקיבולת Enterprise. הערך הגדול הוא לא רק המחיר, אלא האפשרות לבצע ניסוי קטן, למדוד תועלת ועלות, ורק אז לבחור אם להרחיב את השימוש.
מקורות: BigQuery Release Notes, 6.11.2026; Google Cloud — Introduction to BigQuery Graph.
תמונה: Conny Schneider / Unsplash. רישיון Unsplash מאפשר שימוש חופשי, לרבות שימוש מסחרי ושיווקי; התמונה היא יצירה מופשטת ללא אנשים או סימני מסחר מזוהים. קרדיט וקישור למקור נשמרו.
