BigQuery Graph يصبح عامًا، لكن GQL يتطلب حجز Enterprise
أعلنت Google Cloud في 1 سبتمبر 2026 الإتاحة العامة لـBigQuery Graph، بعد طرحه للمعاينة، لتشغيل التحليل البياني فوق البيانات التي يديرها BigQuery. ويوضح إعلان Google Cloud أن عمليات اجتياز العلاقات تعمل داخل المستودع إلى جانب SQL، من دون نقل البيانات إلى محرك رسوم بيانية مستقل أو بناء مسار ETL منفصل.
وفي التاريخ نفسه، أصبحت فرق البيانات أمام منتج متاح عمومًا، لكن ليس أمام طريقة فوترة واحدة لكل قدراته. فقد أكدت مراجعة PC Europa للإصدار حالة الإتاحة العامة والعمل مباشرة فوق الجداول الحالية، بينما يبقى تشغيل GQL الكامل مرتبطًا بنوع الحجز المستخدم.
ما الذي أصبح متاحًا داخل BigQuery؟
يتيح BigQuery Graph تعريف رسم خصائص فوق الجداول أو العروض القائمة: تمثل بعض الصفوف عقدًا مثل الحسابات والأجهزة والموردين، وتمثل جداول أخرى الحواف التي تربطها مثل التحويلات وعمليات تسجيل الدخول والعقود. لا يستلزم هذا التعريف إنشاء نسخة تخزين مستقلة للرسم، ولذلك يمكن إبقاء البيانات الأساسية ضمن سير العمل القائم.
يدعم المنتج واجهة متوافقة مع معيار ISO GQL ومعيار SQL/PGQ. ويمكن تحويل مخرجات الاستعلام البياني إلى نتائج جدولية ودمجها مع SQL، كما تتكامل إمكانات البحث النصي والمتجهي مع تحليل العلاقات. المكسب العملي ليس استبدال SQL، بل إضافة طريقة أوضح لوصف الأنماط والمسارات عندما تصبح سلسلة عمليات JOIN طويلة أو عندما لا يكون عدد القفزات معروفًا سلفًا.
ينبغي مع ذلك فصل حالة BigQuery Graph عن حالة كل ميزة محيطة وردت في إعلان الإطلاق؛ فقد نبّهت Google إلى أن بعض الإمكانات المذكورة متاحة عمومًا، بينما لا يزال بعضها في المعاينة أو قيد الطرح. لذا لا تعني إتاحة المحرك عمومًا أن كل أدوات المحادثة والوصول عبر السحب ووظائف الوكلاء تحمل الحالة نفسها.
حجز Enterprise هو الحد الفاصل لـGQL
الإتاحة العامة لا تمنح استعلامات GQL لكل نماذج الفوترة. تنص وثائق BigQuery Graph على أن تشغيل GQL يتطلب حجزًا يستخدم Enterprise أو Enterprise Plus؛ أما التسعير عند الطلب فيسمح بإنشاء الرسوم واستدعاء GRAPH_EXPAND لتشغيل استعلامات SQL عليها. وتُحاسب استعلامات الرسم القائمة على السعة وفق الحوسبة المقاسة بالـslots، بينما يُحتسب تخزين الجداول الأساسية مرة واحدة مهما تعددت نماذج الرسم المبنية فوقها.
هذا قيد وظيفي ومالي في آن واحد. يستطيع مشروع يعمل بالتسعير عند الطلب توسيع جوار عقدة أو متابعة علاقات ضمن نطاق مضبوط بواسطة GRAPH_EXPAND، ثم تصفية الناتج وتجميعه في SQL؛ لكنه لا يحصل بذلك على واجهة GQL الكاملة لمطابقة الأنماط والمسارات.
أما الفريق الذي يملك حجز Enterprise أو Enterprise Plus بالفعل، فعليه تحديد ما إذا كانت سعته الحالية تستوعب حمل الرسم. وإذا لم يكن لديه حجز مناسب، يصبح طلب GQL قرار سعة وفوترة، لا مجرد تفعيل لغة جديدة. ولا تنشر Google فاتورة نموذجية تصلح لجميع الأحمال، لذلك لا يمكن استنتاج أن صياغة أقصر للاستعلام ستؤدي تلقائيًا إلى تكلفة أقل.
متى تكفي SQL أو GRAPH_EXPAND؟
يتوقف الاختيار على شكل العلاقة المطلوب تحليلها. عندما تكون الجداول مترابطة بمفاتيح معروفة والمسار ثابتًا وعدد عمليات الربط محدودًا، تظل SQL الخيار الأبسط. لا تضيف طبقة الرسم قيمة كافية إذا كان السؤال الجدولي واضحًا ومستقرًا.
- SQL وحدها: للعلاقات الثابتة التي يمكن التعبير عنها بعدد واضح وقابل للصيانة من عمليات JOIN، من دون مطابقة دورات أو مسارات متغيرة.
- GRAPH_EXPAND مع SQL: لتوسيع العلاقات من عقدة أو مجموعة عقد ضمن نطاق محدد، خصوصًا في مشروع يستخدم التسعير عند الطلب ولا يحتاج إلى بناء الاستعلام كله بلغة GQL.
- GQL مع Enterprise أو Enterprise Plus: عندما تكون مطابقة الأنماط، والدورات، والمسارات متعددة القفزات جوهر السؤال، أو تصبح الصياغة العودية في SQL معقدة وصعبة المراجعة.
هذه الشجرة لا تجعل نوع الحجز بديلًا عن اختبار النموذج. قبل مقارنة الاستهلاك، يحتاج الفريق إلى التأكد من ثبات مفاتيح العقد، وصحة اتجاه الحواف، وملاءمة خصائصها الزمنية، ثم مقارنة نتيجة الرسم بنتيجة معروفة. الرسم المبني على علاقات غامضة سيعيد مسارات غامضة مهما كانت لغة الاستعلام أكثر تعبيرًا.
الاحتيال وسلاسل الإمداد يكشفان قيمة كل مسار
في كشف الاحتيال، قد يقتصر السؤال الأول على الحسابات أو الأجهزة المتصلة مباشرة بمعاملة مشتبه فيها؛ وهنا يمكن أن يكون GRAPH_EXPAND مع SQL كافيًا. أما البحث المتكرر عن حلقات تحويل، أو هويات تشترك في أجهزة متعددة، أو طريق أموال لا يُعرف طوله مسبقًا، فهو أقرب إلى عبء يستفيد من مطابقة الأنماط في GQL.
لكن وجود مسار لا يحوله تلقائيًا إلى دليل على الاحتيال. قد تشترك حسابات مشروعة في عنوان شبكة أو جهاز، ولذلك تعتمد قيمة النتيجة على تعريف الحواف ومصدرها وفترتها الزمنية، إلى جانب قواعد التحقق والتحقيق البشري. ما يزيله BigQuery Graph هو الحاجة إلى نقل البيانات لمحرك منفصل، لا الحاجة إلى تقييم قوة الإشارة.
وفي سلاسل الإمداد، يمكن تمثيل الموردين والأجزاء والطلبات ومواقع التوزيع كعقد مترابطة. يكفي SQL لتقرير عن مخزون جزء معروف أو طلبات مورد محدد، وقد يكفي GRAPH_EXPAND لتتبع طبقات محدودة. تصبح GQL أكثر جدوى عندما يكون السؤال عن جميع المنتجات والعملاء المتأثرين بصورة غير مباشرة بتعطل مورد عبر عدد غير ثابت من الروابط.
الخلاصة المؤكدة منذ 1 سبتمبر 2026 هي أن BigQuery Graph متاح عمومًا ويجري التحليل فوق بيانات المستودع، بينما تتطلب استعلامات GQL حجز Enterprise أو Enterprise Plus. أما فرق التسعير الفعلي بين GQL وGRAPH_EXPAND فلا يمكن تعميمه قبل معرفة استهلاك الـslots، وحدود المسارات، وتكرار الاستعلامات؛ ولهذا قد تكفي SQL لبعض الفرق، فيما يكون الحجز مبررًا فقط عندما تكون المسارات المعقدة جزءًا متكررًا وأساسيًا من عبء العمل.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.