Azure SQL Database مقابل Fabric SQL Database: شرح الفروقات في التكلفة والحوسبة

By Mirko Peters · 2026-10-21

قارن بين تكاليف الحوسبة في Azure SQL Database وFabric SQL Database، والتوسع بدون خادم، ووحدات السعة، واقتصاديات التخزين، والمقايضات بين الميزات.

Automatically translated with AI from the original post. Read the English original

يعتمد الاختيار بين Azure SQL Database وFabric SQL Database على فهم الاختلافات في تخصيص الحوسبة وسلوكيات التوسع ووحدات السعة. ورغم أن كلتيهما تعملان على محرك SQL نفسه القوي، فإن تكامل Fabric مع OneLake ونماذج السعة المشتركة يفرض اعتبارات معمارية وتكلفة مميزة على المؤسسات التي تعتمد على البيانات.

النقاط الرئيسية

• تستمد قاعدة بيانات Fabric SQL قدرتها من وحدات السعة (CUs) المشتركة في Fabric، بدلًا من طبقات vCore المستقلة في Azure.
• تتقلص موارد الحوسبة إلى الصفر وتُحرَّر تلقائيًا بعد 15 دقيقة من عدم النشاط لتوفير التكاليف.
• تُفوتر تكاليف التخزين باستمرار على أساس ساعي، في حين أن تخزين النسخ الاحتياطية مجاني حتى حجم قاعدة البيانات الأساسية.
• يلغي Mirroring المدمج الحاجة إلى خطوط ETL يدوية، إذ يملأ ملفات Delta Parquet في OneLake في الوقت الفعلي.
• توفر قاعدة Azure SQL Database التقليدية مجموعات مرنة مخصصة (Elastic pools) ومهام SQL Server Agent، وتتعامل بيئات Fabric معها بطريقة مختلفة.

فهم الحوسبة: vCores مقابل وحدات السعة

عند ترحيل أحمال العمل أو تخطيط بنية سحابية جديدة، يكمن التحول الجوهري بين Azure SQL التقليدية وFabric SQL في إدارة الحوسبة. في Azure SQL Database المستقلة، تخصص vCores مخصصة أو حوسبة Serverless مرتبطة مباشرةً بنسخة قاعدة البيانات الفردية، وتدير حدود التوسع ونوافذ الصيانة ومستويات الأداء على أساس كل قاعدة بيانات على حدة.

في المقابل، تستمد قاعدة بيانات Fabric SQL قدرتها الحاسوبية من مجموعة السعة الأوسع في مؤسستك ضمن Fabric. يعني هذا النموذج المشترك أن قاعدة البيانات تتشارك الميزانية مع تقارير Power BI وخطوط Data Factory وLakehouses. يتم تحويل معدل وحدات السعة في Fabric (CUs) إلى قدرة قاعدة البيانات بشكل ديناميكي خلف الكواليس. فعلى سبيل المثال، يعادل تخصيص 64 وحدة سعة تقريبًا 24.5 vCore لأحمال عمل قاعدة البيانات. ويمنع هذا النهج الموحد للمجمّع تجزؤ الموارد الشائع في بيئات قواعد البيانات المتعددة، ويتيح المشاركة الديناميكية عبر مساحة عمل التحليلات لديك.

قواعد التوسع بدون خادم وفوترة الخمول

تعتمد كلتا الخدمتين على بنى Serverless تتوسع عند ذروة تنفيذ الاستعلامات وتعود إلى الانكماش عندما ينخفض الحمل. ومع ذلك، تكتسب آليات فوترة وقت الخمول أهمية خاصة لتوقعات الميزانية. تراقب Fabric SQL Database النشاط باستمرار. فإذا بقيت قاعدة البيانات خاملة تمامًا لمدة 15 دقيقة دون استعلامات واردة، فإنها تحرر جميع موارد الحوسبة لديها، فتنخفض تكلفة الحوسبة إلى الصفر.

لمنع زمن الاستجابة عند البدء البارد للمستخدم التالي، تطبّق Microsoft فترة احتفاظ مقصودة. فإذا عملت قاعدة البيانات بكثافة لمدة دقيقتين ثم خمدت، تُفوتر عن دقيقتي النشاط بالإضافة إلى 15 دقيقة إضافية من الحوسبة الجاهزة، أي ما مجموعه 17 دقيقة. أما التخزين فيبقى ثابتًا ويُفوتر كل ساعة، سواء كانت قاعدة البيانات تعالج المعاملات فعليًا أم في وضع السكون.

تكاليف التخزين واقتصاديات النسخ الاحتياطي

يُحدث إدارة التخزين في قاعدة بيانات SQL في Fabric فرقًا كبيرًا في التكلفة مقارنةً بالإعدادات القديمة. فبما أن قاعدة البيانات تبدأ تلقائيًا نسخًا متماثلًا مستمرًا إلى OneLake، تُنسخ سجلاتك التشغيلية إلى ملفات Delta Parquet مفتوحة المصدر. يضمن هذا التنسيق المفتوح عدم حبس بياناتك داخل نظام مغلق، إذ يمكن لأي أداة قادرة على قراءة تنسيق Delta الاستعلام عن النسخة المتماثلة مباشرةً.

كما أن اقتصاديات النسخ الاحتياطي محسّنة بدرجة كبيرة في منظومة Fabric. تتيح إمكانية الاستعادة إلى نقطة زمنية محددة للمسؤولين إرجاع الزمن إلى الوراء حتى سبعة أيام لاستعادة البيانات بعد تلفها عن طريق الخطأ أو وقوع أخطاء فادحة من المستخدمين. ومساحة النسخ الاحتياطي مجانية بالكامل حتى الحجم الإجمالي لقاعدة البيانات الأساسية. ولا تُفرض رسوم إضافية إلا إذا تجاوزت مساحة النسخ الاحتياطي حجم قاعدة البيانات النشطة نفسها، وهو ما يوفر شبكة أمان مالية متوقعة للاحتفاظ بالبيانات على المدى الطويل.

المفاضلات التشغيلية: ما تكسبه وما تخسره

على الرغم من أن محرك SQL الأساسي متطابق في المنصتين، فإن اختيار قاعدة بيانات SQL في Fabric بدلًا من Azure SQL Database يتطلب تقييم بعض المفاضلات في الميزات. فمعرفة ما هو غير متوفر في تطبيق Fabric تمنع العوائق المعمارية غير المتوقعة أثناء التطوير.

الميزات الحصرية لـ Azure SQL التقليدية

تدعم قواعد بيانات Azure SQL المستقلة المجموعات المرنة (elastic pools) بشكل أصيل حسب الاسم، مما يمنح مسؤولي قواعد البيانات تحكمًا دقيقًا في تجميع قواعد البيانات. كما تتضمن SQL Server Agent الكلاسيكي، الذي تعتمد عليه كثير من التطبيقات القديمة في جدولة الإجراءات المخزنة ومهام الصيانة داخليًا.

المزايا الأصيلة لـ SQL في Fabric

تُلغي قاعدة بيانات SQL في Fabric العبء الإداري المرتبط بإعداد خطوط نسخ متماثل خارجية. فور إنشاء قاعدة البيانات، يُفعَّل النسخ المتماثل تلقائيًا لجميع الجداول المدعومة دون الحاجة إلى إعداد يدوي لعمليات ETL. إضافةً إلى ذلك، تتكامل مع Git بشكل أصيل لإدارة المصدر، وتدعم أسماء الكائنات ذات الأجزاء الثلاثة، مما يتيح لك ربط الجداول التشغيلية بـ Lakehouses و Warehouses بسهولة في استعلام واحد. للاطلاع على نظرة شاملة لكيفية ترابط هذه المكونات، استمع إلى الحلقة الكاملة لتستمع إلى تحليل الخبراء واستراتيجيات عملية لمهندسي البيانات المعماريين المعاصرين.

الأسئلة المتداولة

كيف تعمل الفوترة لقاعدة بيانات SQL في Fabric غير النشطة؟

تستمر فوترة الحوسبة لمدة 15 دقيقة بعد انتهاء تنفيذ آخر استعلام، وذلك للحفاظ على قاعدة البيانات جاهزة، وبعد ذلك تنخفض تكاليف الحوسبة إلى صفر. أما التخزين فيستمر في الفوترة بشكل ساعي بغض النظر عن النشاط.

هل أحتاج إلى إعداد النسخ المتماثل يدويًا للحصول على البيانات في OneLake؟

لا. يبدأ النسخ المتماثل تلقائيًا لحظة إنشاء قاعدة بيانات SQL في Fabric، ويزامن جداولك العلائقية باستمرار إلى OneLake في شكل ملفات Delta Parquet مفتوحة المصدر، دون الحاجة إلى كود ETL مخصص.

هل يمكنني استخدام SQL Server Agent لجدولة المهام في قاعدة بيانات SQL في Fabric؟

لا يتوفر SQL Server Agent في قاعدة بيانات SQL في Fabric. وبدلًا من ذلك، توصي Microsoft باستخدام خطوط أنابيب Data Factory أو مهام Apache Airflow للجدولة والأتمتة.

كيف تُحتسب تكلفة النسخ الاحتياطي في SQL في Fabric؟

نُسخ الاستعادة إلى نقطة زمنية محددة مجانية بالكامل حتى الحجم الإجمالي لمساحة قاعدة البيانات النشطة. ولا تدفع مقابل مساحة النسخ الاحتياطي إلا إذا تجاوزت مساحته حجم قاعدة البيانات الأساسية.