أصعب جزء في ربط وكيل ذكاء اصطناعي بقاعدة بيانات ليس توليد SQL، بل السماح لمهام استدلال متوازية وغير متوقعة—وقد تكون طويلة—بقراءة بيانات العمل الحالية دون سحب CPU أو الذاكرة أو I/O من الدفع والطلبات وبقية معاملات الإنتاج. في 24 سبتمبر 2026 أعلنت Google Cloud معاينة PostgreSQL for agents في AlloyDB، ومبدؤها: شارك نسخة محدثة لحظيًا من البيانات، لكن لا تشارك موارد قاعدة البيانات التي تخدم التطبيق.
هذه معاينة وليست خدمة متاحة عمومًا بضمانات نهائية. يتطلب الوصول تقديم طلب، وتوثقها Google ضمن شروط Pre-GA ودعم محدود. مع ذلك، تستحق المعمارية الدراسة لأنها تعالج مشكلة حقيقية في الأنظمة الموزعة لا تحلها read replicas أو خوادم التخزين المشتركة أو exports إلى object storage إلا جزئيًا.
ماذا قدمت Google فعلًا؟
الوحدة الجديدة هي AlloyDB agent node: آلة microVM مستقلة ومؤقتة تشغل محرك PostgreSQL كاملًا. تقول Google إن العقدة تستخدم فهارس PostgreSQL وامتداداته وقدرات الاستعلام، ومنها البحث المتجهي والنصي الكامل والمكاني، فوق نسخة للقراءة فقط ومحدثة من بيانات الإنتاج. ويمكنها كذلك المشاركة في استعلامات تصل إلى BigQuery أو Spark عبر مسارات federation الموثقة.
الكلمة الأهم هي «مستقلة». بحسب شرح Google للمعمارية، لا تشارك عقد الوكلاء حوسبة قاعدة البيانات أو الذاكرة أو مكونات الشبكة مع primary الإنتاج. كما تستخدم في الوصول إلى التخزين مقاطع Colossus مخصصة بدل مسار التخزين الخاص بخادم الإنتاج. لذلك يمكن لموجة من استعلامات الوكلاء أن تستهلك أسطولها الخاص بدل التنافس على execution slots في primary.
العقد مؤقتة: ينشئها التطبيق لمهمة، ويوزع العمل على عدد كبير منها، ثم يحررها. تصف Google توسعًا من الصفر إلى آلاف العقد واحتسابًا للثواني النشطة. لكن الإعلان لا ينشر جدول أسعار كاملًا لكل الإعدادات؛ لذلك يجب حساب التكلفة من اتفاق المعاينة بدل استنتاجها من عبارة «التوسع إلى الصفر».
لماذا لا تمنح Read Replica الحد نفسه؟
غالبًا تكون read replica أول حل للحمل التحليلي أو استعلامات الوكلاء. هي مألوفة وتحافظ على سلوك PostgreSQL، لكنها خادم محجوز بسعة محدودة. إذا وصل مئات الوكلاء دفعة واحدة فسيتزاحمون على الموارد نفسها، إلا إذا بالغ الفريق في الحجز أو وسّع الأسطول بنشاط. كما يدخل replica lag ومسؤوليات الترقية ضمن نموذج التشغيل.
يمكن لقاعدة بيانات مفككة الحوسبة والتخزين أن تربط عدة workers بتخزين مشترك، لكن حماية noisy neighbor تعتمد على مقدار ما بقي مشتركًا من I/O وcache وmetadata والشبكة. أما تصدير snapshots إلى object store فيعزل الإنتاج أفضل ويتوسع بتكلفة منخفضة، لكنه يقدم بيانات قديمة وقد يفقد تنفيذ العلاقات والفهارس ودلالات المعاملات.
مقايضة AlloyDB مختلفة: أبقِ تنفيذ PostgreSQL قريبًا من البيانات الحية، ثم أنشئ مسار حوسبة ووصول تخزين مستقلًا لأحمال الوكلاء. الوصول للقراءة فقط يضيّق blast radius كثيرًا، لكنه يعني أيضًا أن الوكيل لا ينفذ workflow كثيف الكتابة داخل العقدة. يجب أن تمر تغييرات الإنتاج عبر خدمة أو مسار أوامر مستقل بصلاحيات واضحة، مع validation وidempotency وموافقة بشرية عندما تتطلب المخاطر ذلك.
العزل للقراءة فقط ليس صلاحيات وصول
تفصل الميزة الموارد، لكنها لا تقرر أي صفوف يجوز للوكيل رؤيتها. قد تكشف عقدة تقرأ نسخة حالية من الإنتاج بيانات شخصية أو مالية أو بيانات tenants إذا كانت credentials أوسع من اللازم. تعامل مع العقدة كعميل قاعدة بيانات داخل failure domain جديد، لا كصندوق أمان تلقائي.
أنشئ role مخصصًا لكل فئة من الوكلاء، وامنحه فقط schemas وviews وfunctions اللازمة. طبّق row-level security عندما تتطلب حدود tenants ذلك، ولا تضع الأسرار في prompts، وسجّل هوية قاعدة البيانات وهوية المستخدم أو الخدمة التي بدأت المهمة. فالاستعلام للقراءة فقط قد يسبب ضررًا عبر كشف البيانات أو استرجاع كمية مفرطة.
تقليل البيانات مهم في RAG واستخدام الأدوات معًا. استخدم views مصممة تستبعد الأعمدة الحساسة بدل أن تطلب من الموديل عدم اختيارها. ضع حدودًا لمدة الاستعلام وحجم النتيجة والتوازي عند agent gateway. سجّل بصمة الاستعلام والـrole والعقدة والـlatency وعدد الصفوف ومعرّف المهمة دون نسخ النتائج الحساسة إلى نظام مراقبة أقل حماية. تكمل هذه الضوابط تصميم عزل tenants في PostgreSQL وحدود الاسترجاع في هندسة جودة RAG.
كيف تقرأ الأرقام دون تحويلها إلى وعد؟
تقول Google إن زيادة agent nodes من عقدة إلى عشر رفعت benchmark من نحو 3,900 إلى 41,000 استعلام في الثانية، وإن اختبارًا أكبر وصل إلى قرابة ثلاثة ملايين استعلام في الثانية عند 1,000 عقدة—ووصفته بزيادة 773 مرة. كما ذكرت أكثر من ثمانية ملايين IOPS، وأكثر من تيرابت في الثانية في اختبار scan شمل 2,100 عقدة، وعدم قياس أثر على primary خلال تلك التجارب.
هذه نتائج هندسية معلنة من المزود، وليست قياسات مستقلة أو SLA. قيمتها أنها تثبت اختبار المعمارية عند fan-out استثنائي، لا أنها تتنبأ بزمن استجابة تطبيقك أو فاتورته. شكل الاستعلام ودفء cache وتصميم الفهارس وحجم النتائج وتوزيع البيانات والتوازي والمنطقة كلها تغير النتيجة. كما أن زيادة throughput بمقدار 773 مرة لا تعني تقليل وقت الوكيل الكامل بالمقدار نفسه؛ فقد يهيمن استدلال الموديل وتنسيق الأدوات والتسلسل على critical path.
لذلك يجب أن يقيس التقييم مستوى قاعدة البيانات ومستوى المهمة. في القاعدة: زمن بدء العقدة، وp50/p95/p99 للاستعلام، وسلوك cache، وI/O، والاستعلامات الفاشلة، وإجمالي ثواني العقد النشطة. وفي التطبيق: المهام المكتملة، ووقت أول نتيجة مفيدة، وعدد tool calls والمحاولات، وجودة الإجابة، وتكلفة المهمة الناجحة. قارنها مع replica ثابتة ومسار snapshots باستخدام corpus الاستعلامات نفسه.
تصميم تجربة آمنة
ابدأ بحمل واحد للقراءة فقط، يكون مصدر حقيقته في AlloyDB ويستفيد فعلًا من حداثة البيانات: البحث لدعم العمليات، أو التحقيق في الاحتيال، أو مساعد catalog خيارات أفضل من وكيل يصدر refunds تلقائيًا. ابنِ التجربة كـcontrol plane صريح بدل السماح للموديل بإنشاء البنية التحتية كيفما شاء.
user task -> policy gateway -> node lease -> scoped SQL tool
| | |
v v v
identity + limits create/expire query + audit
|
v
isolated agent nodeعلى gateway ربط المهمة بـdatabase role وحد أقصى للعقد وميزانية وقت وسياسة استعلامات. ينشئ lease controller العقد أو يعيد استخدامها ضمن هذا الحد، ويضمن انتهاءها بعد النجاح أو الإلغاء أو timeout. تستخدم أداة SQL عمليات جاهزة حيثما أمكن وترفض الكتابة. وتتولى خدمة أوامر منفصلة أي mutation مقترح بعد التحقق من قواعد العمل.
اختبر الفشل قبل العرض: حلقة استعلامات خاطئة، وألف مهمة متزامنة، وإلغاء أثناء بدء العقدة، وتعطل federation target، ومحاولة تجاوز tenant boundary، ومهمة تتجاوز الميزانية. تحقق من بقاء latency الإنتاج ضمن هدفه ومن إزالة العقد اليتيمة. وأدخل دورة حياة العقد وإشارات الاستعلام ضمن نموذج الحوادث المستخدم في مراقبة الـbackend.
أين تناسب المعاينة، وأين لا تناسب؟
يصبح التصميم جذابًا عندما تكون البيانات أصلًا في AlloyDB، وتهم حداثتها، وتصل الأحمال على شكل موجات كبيرة، ويكون SQL أو امتدادات PostgreSQL أفضل من index مستقل. وقد يبسّط تجارب كانت ستحتاج أسطول replicas ثابتًا وكبيرًا.
يقل جدواه عندما يتطلب الحمل كتابات متكررة، أو تتوزع البيانات الموثوقة على أنظمة كثيرة بلا حد federation نظيف، أو تكفي replica صغيرة وثابتة لتحقيق latency والتكلفة. وعلى الفرق التي تستخدم قاعدة أخرى مقارنة تكلفة الانتقال بإضافة query service معزولة، أو analytical store يغذيه CDC، أو نظام vector متخصص. الجدة المعمارية وحدها ليست سببًا لنقل مصدر الحقيقة.
الخلاصة العملية أضيق من العنوان التسويقي: يعرض AlloyDB الآن حد حوسبة جديدًا لوصول وكلاء AI للقراءة فقط إلى بيانات PostgreSQL حديثة. إذا صمدت ادعاءات العزل تحت حمل الفريق نفسه، فقد يحمي هذا الحد الإنتاج من fan-out الوكلاء. لكنه لا يستبدل least privilege أو حوكمة البيانات أو ميزانيات الاستعلام أو المراقبة أو مسار كتابة مستقل بصلاحياته. هذه هي الأجزاء التي تجعل تشغيل الوكيل آمنًا.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
