SQL Server 2025 مقابل PostgreSQL 17 على 2 vCPU: ما يُظهره هذا الاختبار المعياري

أنتج اختبار HammerDB على مضيفين متطابقين في الحجم بمواصفات 2 vCPU و4 GB من نظام Ubuntu فجوة ظاهرية كبيرة في معدل الإنتاجية بين SQL Server 2025 وPostgreSQL 17. سجّل تشغيل PostgreSQL قيمة 8,937 NOPM و20,495 TPM. بينما بلغ ذروة التقاط منفصل عبر DMV في SQL Server نحو 2,158 معاملة في الثانية.

هذه الأرقام مفيدة، لكنها لا تدعم استنتاجًا نظيفًا بأن "SQL Server أسرع بست مرات". تم قياس الجانبين باستخدام عدّادات مختلفة ونوافذ اختبار مختلفة. توثّق هذه المقالة النتيجة، وضبط PostgreSQL المستخدم، والتغييرات المطلوبة لمباراة إعادة قابلة للدفاع عنها.

بيئة الاختبار

استخدم كلا مضيفي قواعد البيانات نفس السعة الرئيسية المعلنة:

2 vCPU نواة
4 GB ذاكرة RAM
تخزين SSD
Ubuntu 24.04 LTS
50 مستودع TPC-C
50 مستخدم افتراضي في HammerDB

استخدم تشغيل PostgreSQL الموقّت فترة إحماء مدتها 10 دقائق ونافذة قياس مدتها 5 دقائق. تم جمع مقاييس SQL Server لمدة 10 دقائق عبر مناهج الإدارة الديناميكية (DMVs) في SQL Server.

يحاكي عبء عمل TPC-C في HammerDB معالجة الطلبات عبر المستودعات. تمثل معاملات New-Order حوالي 45 في المائة من المزيج، وPayments حوالي 43 في المائة، بينما تشكل Order-Status وDelivery وStock-Level الباقي.

ضبط PostgreSQL 17 المستخدم في الاختبار

غيّر تشغيل PostgreSQL المضبوط إعدادات الخادم التالية للمضيف المقيد:

`shared_buffers = 1GB`
`effective_cache_size = 3GB`
`synchronous_commit = off`
`checkpoint_timeout = 15min`
`checkpoint_completion_target = 0.9`
`random_page_cost = 1.1`
`effective_io_concurrency = 200`
`huge_pages = try`
`max_connections = 100`
`wal_level = minimal`

بقي Autovacuum مفعّلًا. وهذا أمر مهم لـ TPC-C لأن التحديثات تنشئ نسخ صفوف ميتة في الجداول النشطة مثل STOCK وCUSTOMER وDISTRICT وORDER_LINE.

يغيّر إعدادان المعنى الإنتاجي للنتيجة. يمكن لـ `synchronous_commit = off` أن يفقد المعاملات المعترف بها مؤخرًا بعد عطل في نظام التشغيل أو انقطاع التيار الكهربائي. يعطّل `wal_level = minimal` معلومات WAL اللازمة للتكرار المادي والأرشفة المستمرة. إنها خيارات معيارية معقولة فقط عندما يتم بيان حدود الموثوقية والاسترداد هذه بوضوح.

نتيجة PostgreSQL المبلّغة

طباعة HammerDB:

`System achieved 8937 NOPM from 20495 PostgreSQL TPM`

NOPM، أو عدد الطلبات الجديدة في الدقيقة، هو المقياس الرئيسي لـ HammerDB TPC-C. إنه يعدّ معاملة New-Order التجارية ومصمم للمقارنة بين المحركات عندما تعمل كلا المحركين بإعدادات السائق نفسها.

تُحوّل قيمة 20,495 TPM إلى حوالي 342 معاملة في الثانية. هذا هو المتوسط الذي يمثله عدّاد TPM النهائي، وليس قياس ذروة منفصلًا. كما يستشهد التقرير بمتوسط يقارب 189 TPS من البيانات المأخوذة، لذا يجب أن ترافق أي مقارنة نهائية السلاسل الزمنية الخام وطريقة الحساب.

نتيجة SQL Server المبلّغة

استخدم جانب SQL Server إجراءً مخزّنًا لعينة عدّادات أداء DMV. عبر 214 عينة، أبلغ التقاط عن ذروة تقارب 2,158 TPS ومتوسط يقارب 883 TPS.

هنا تصبح المقارنة غير مؤكدة. عدّاد DMV في SQL Server مثل Batch Requests/sec ليس مكافئًا تلقائيًا لـ HammerDB NOPM أو TPM أو معاملات TPC-C المكتملة. يمكن لمعاملة تجارية واحدة أن تنفّذ عدة دفعات SQL. تؤثر أيضًا النشاط الداخلي والعدّاد الدقيق المختار على التفسير.

تُظهر أرقام SQL Server أن الخادم عالج معدلًا مرتفعًا من النشاط المقاس. لا تثبت هذه الأرقام، بحد ذاتها، تفوقًا بست مرات في TPC-C على PostgreSQL.

لماذا قد تكون الفجوة الظاهرية كبيرة

يمكن أن تؤثر عدة عوامل تقنية على PostgreSQL على مضيف بنواتين:

يستخدم PostgreSQL عملية خلفية واحدة لكل اتصال عميل. تتنافس 50 عميلًا نشطًا بالإضافة إلى عمليات WAL وcheckpoint وautovacuum والخلفية على نواتين.
يضع عبء العمل كثيف الكتابة ضغطًا على توليد WAL وطرد المخازن المؤقتة ونقاط الفحص.
ينشئ MVCC مجموعات ميتة يجب على autovacuum استعادتها أثناء تشغيل الاختبار المعياري.
لا يمكن لمخزن مشترك بحجم 1 GB الاحتفاظ بمجموعة بيانات بحجم 5 GB تقريبًا، لذا فإن سلوك التخزين ومخزن نظام التشغيل المؤقت مهمان.

لدى SQL Server بنية تنفيذ وذاكرة مختلفة، بما في ذلك مخزن مشترك مدمج، ونشاط كتابة في الخلفية، وسلوك التزام المجموعة. قد تساعد هذه الاختلافات على الأجهزة المقيدة. لا يزال يجب اختبارها باستخدام مقياس إخراج على مستوى الأعمال نفسه قبل أن تفسر الفائز المقاس.

أربعة مشاكل يجب إصلاحها قبل إعلان فائز

استخدم HammerDB NOPM وTPM لكلا المحركين. لا تقارن TPM في PostgreSQL بعدّاد دفعات DMV في SQL Server.
استخدم نفس فترة الإحماء ومدة القياس. حافظ على عدد المستودعات، والمستخدمين الافتراضيين، ووضع السائق، وإعدادات وقت التفكير متطابقة.
طابق الموثوقية. قارن `synchronous_commit` في PostgreSQL مع سلوك الموثوقية المقابل في SQL Server، وأبلغ عن إعدادات مخزن التخزين المؤقت.
انشر مخرجات التشغيل الخام. شمل سجلات HammerDB، وتعريفات العدّادات، ونسب مئوية الكمون، والمعالج، والذاكرة، وتباطؤ القرص، وحجم قاعدة البيانات، وملفات الإعداد.

سيكون متابعة مفيدة اختبار 10 و25 و50 مستخدمًا افتراضيًا. قد تقيس 50 عملية قاعدة بيانات على نواتين تنافس الاتصالات أكثر من إنتاجية المحرك. سيُظهر تشغيل PostgreSQL ثانٍ عبر PgBouncer كم من النتيجة يأتي من نموذج العملية لكل اتصال.

متابعة PostgreSQL 18

أضاف PostgreSQL 18 نظام فرعي لإدخال/إخراج غير متزامن للقراءة وبعض أعمال الصيانة. لا يزيل مسار كتابة WAL الذي يهيمن على تشغيل TPC-C كثيف الكتابة، لكن القراءة الأسرع وأعمال التنظيف قد تقلل الضغط في أماكن أخرى. سيجعل تكرار الاختبار على PostgreSQL 18 باستخدام مقاييس على مستوى الأعمال نفسها المقارنة التالية أكثر فائدة.

الاستنتاج العملي

وجد هذا الاختبار المعياري 8,937 NOPM لـ PostgreSQL على مضيف صغير ومعدل DMV أكبر بكثير لـ SQL Server. كما كشف الدرس الرئيسي في اختبارات معايير قواعد البيانات: الأجهزة المتطابقة ليست كافية. يجب أن يتطابق عبء العمل، وسياسة الموثوقية، ونافذة الوقت، وتعريف المقياس.

عامل النتيجة الحالية كسبب قوي لإعادة تشغيل الاختبار، وليس كترتيب نهائي للمحرك. يجب أن يبلغ التشغيل التالي عن NOPM، وTPM الإجمالي، والكمون، وتشبع الموارد من كلا النظامين تحت إجراء HammerDB واحد.

خطط لاختبار معياري لقاعدة البيانات أو هجرة مع Worlber

تساعد Worlber الفرق على إجراء اختبارات قياس الأداء (Benchmarking) لقواعد بيانات PostgreSQL وSQL Server باستخدام أحمال عمل مطابقة، وإعدادات دوام آمنة للإنتاج، وأدلة خام، وخطط تشغيل قابلة للتكرار. كما يمكننا تقييم خيارات هجرة PostgreSQL، وضبط البيئات المقيدة، وتصميم منصة الإنتاج بناءً على متطلبات الاسترداد والتوافر لديكم.

تحدث إلى Worlber بشأن حمل عمل قاعدة البيانات الخاصة بك