أعلنت AWS إضافة إمكانية الاستعلام المباشر من بيانات Apache Iceberg وApache Parquet المخزنة في بحيرة البيانات إلى جانب البيانات التشغيلية داخل Amazon Aurora PostgreSQL. وتسمح القدرة الجديدة للتطبيقات بدمج السجلات الحديثة والتاريخية في استعلام واحد باستخدام صياغة PostgreSQL والأدوات الحالية، من دون نسخ البيانات إلى قاعدة البيانات عبر خطوط ETL.
ما الذي تغير عملياً؟
تعتمد الوظيفة على محرك DuckDB المضمّن مباشرة داخل Aurora PostgreSQL. وبذلك يستطيع الاستعلام الواحد قراءة البيانات التشغيلية، بما في ذلك الكتابات غير المثبتة، وقراءة جداول Iceberg أو ملفات Parquet من Amazon S3. كما تدعم AWS Glue Data Catalog، وAmazon S3 وS3 Tables، إضافة إلى الكتالوجات المتوافقة مع Iceberg REST Catalog عبر آلية federation في Glue.
يحتاج المستخدم إلى إنشاء عنقود Aurora PostgreSQL، وإرفاق دور IAM يتضمن ميزة AuroraAnalytics، ثم تفعيل الامتداد aurora_analytics. بعد ذلك يمكن إنشاء foreign tables تشير إلى البيانات الخارجية، أو استخدام IMPORT FOREIGN SCHEMA لإنشاء جداول متعددة تلقائياً مع استنتاج مخطط البيانات من الميتاداتا.
لماذا يهم هذا الخبر؟
كانت التطبيقات التي تجمع بين معاملات حديثة في Aurora وسجلات تاريخية في S3 تحتاج عادةً إلى نسخ البيانات عبر reverse ETL، ما يضيف عمليات مزامنة وتكلفة تشغيلية وتعقيداً هندسياً. أما الآن، فيمكن تنفيذ هذا الدمج أثناء الاستعلام نفسه. يفيد ذلك لوحات المتابعة التي تحتاج إلى سياق تاريخي، والتطبيقات التي تربط المعاملة بسجل سابق، والأنظمة التي تتعامل مع بيانات موزعة بين قاعدة تشغيلية وبحيرة بيانات.
وتكتسب هذه النقطة أهمية إضافية في التطبيقات التي تستخدم وكلاء الذكاء الاصطناعي، إذ يصعب توقع كل مجموعة بيانات قد يحتاج إليها الوكيل مسبقاً ونسخها إلى قاعدة تشغيلية. يتيح الوصول المباشر توسيع نطاق البيانات المتاحة من دون إنشاء نسخة لكل حالة استخدام.
الأداء وخيارات الوصول
تطبق Aurora تحسينات مثل دفع المرشحات إلى مصدر البيانات وتقليص الأعمدة المقروءة، كما تخزن البيانات المستخدمة بكثرة مؤقتاً داخل مثيل Aurora. ويمكن فحص سلوك كل استعلام عبر الدالة aurora_analytics_stat_statements()، التي تعرض مؤشرات منها عدد الصفوف المفحوصة، وحجم البيانات المقروءة من S3، ومرات الاستفادة من الذاكرة المؤقتة.
تتوفر الاستعلامات على مثيلات Aurora المختلفة داخل العنقود، بما فيها الكاتب والنسخ المخصصة للقراءة، ما يتيح إسناد عمليات الفحص التحليلية بعيداً عن الحمل التشغيلي. أما الحالات التي تتطلب زمناً من رتبة أجزاء من الألف من الثانية، فيمكن فيها تجسيد البيانات داخل جدول Aurora أصلي باستخدام CREATE TABLE AS SELECT أو INSERT INTO ... SELECT أو MERGE INTO. وتُنفذ عمليات الكتابة الناتجة عن التجسيد على مثيل الكاتب.
التوفر والتكلفة
تدعم القدرة إصداري Aurora PostgreSQL 17 بدءاً من 17.11، و18 بدءاً من 18.6. وهي متاحة في جميع مناطق AWS التجارية ومناطق AWS GovCloud (US)، من دون رسم إضافي للميزة نفسها. وتظل التكلفة مرتبطة بزيادة حوسبة Aurora التي تستهلكها الاستعلامات، إضافة إلى رسوم طلبات Amazon S3 لقراءة ملفات بحيرة البيانات.
قراءة certi.news: التغيير الأساسي ليس إضافة صيغة تخزين جديدة، بل تقليص المسافة بين قاعدة البيانات التشغيلية وبحيرة البيانات. ومع ذلك، لا يلغي ذلك اعتبارات تصميم الأحمال: فالاستعلام المباشر مناسب للوصول المرن إلى البيانات، بينما تظل الحاجة إلى التجسيد قائمة عندما تكون أزمنة الاستجابة شديدة الانخفاض أولوية. كما أن استهلاك حوسبة Aurora وطلبات S3 سيظل عاملاً يجب قياسه وفق نمط الاستعلام وحجم البيانات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.