2026-11-04 · المصدر：SiliconANGLE
بتضمين المحرك التحليلي مباشرة في خدمتها المُدارة لـPostgreSQL، تلغي Amazon مسارات الاستخراج والتحويل والتحميل التي ظلت طويلاً تفصل التطبيقات التشغيلية عن سجلاتها المؤرشفة.
نسخة البيانات هي الضحية. إن Amazon Web Services تُعلّم Aurora PostgreSQL قراءة بحيرات بيانات Apache Iceberg في موضعها، بما يتيح للتطبيقات سحب السجلات المعاملاتية الحية والأرشيف التاريخي في نتيجة استعلام واحدة دون تكرار أي شيء.
المحرك الذي يؤدي العمل الأكبر هو DuckDB، الذي ضمته AWS داخل Aurora PostgreSQL نفسه. وبوجود المحرك التحليلي مقيماً داخل نظام إدارة قواعد البيانات، يمكن للاستعلامات الصادرة من الخدمة ذاتها التي تدير المعاملات الجارية أن تمتد إلى جداول Iceberg — ولا يتطلب هذا النهج أي مجموعات بيانات منسوخة ولا مسارات استخراج/تحويل/تحميل للحفاظ على تزامن العالمين.
تستهدف هذه القدرة شقاً ساد تصميم بنية بيانات المؤسسات لسنوات. فالقواعد التشغيلية مضبوطة لتتحمل كتابات صغيرة متواصلة تغيّر الحالة، بينما تضبط الأنظمة التحليلية لمسح كميات هائلة من التاريخ. وكان جسر الفجوة بينهما يعني تقليدياً نسخ بيانات الإنتاج خارجاً وتحويلها ثم تحميلها في مخزن منفصل — تخزيناً مكرراً، مع فجوة زمنية بين وصول معاملة ما وتحولها إلى تاريخ قابل للاستعلام. وبإتاحة استجواب Aurora PostgreSQL لـIceberg مباشرة، تسقط Amazon تلك الطبقة الوسيطة: فالنظام المعاملاتي والسجل التاريخي يصبحان قابلين للقراءة من مكان واحد.
كل مسار يُلغى هو أيضاً مهمة مجدولة لم تعد بحاجة إلى المراقبة أو إعادة المحاولة أو الإصلاح بين قاعدة بيانات تشغيلية وأرشيفها. ولمجموعات منصات البيانات، هذا سطح تشغيلي يُقتطع لا يُضاف.
الميزة، المعلَن عنها في 30 سبتمبر، تحول Aurora PostgreSQL إلى عنوان استعلام واحد للبيانات الحية والمؤرشفة معاً، مع بحيرة بيانات Apache Iceberg الشائعة بوصفها الطبقة التاريخية وDuckDB مزوداً للقوة التحليلية داخل قاعدة البيانات المُدارة. ولعملاء AWS، الدلالة صريحة: المسافة بين معاملات التطبيق الجارية وتاريخه الخاص أصبحت أقصر للتو.
الوسوم: AWS · Aurora PostgreSQL · DuckDB · Apache Iceberg · Cloud Databases · Data Lakes
萬安算交所 AIXX · AIXX · بورصة الحوسبة الموثقة · قاعة التداول