لوحات المؤشرات تُثقل قاعدة PostgreSQL التشغيلية: ماذا يغيّر تسريع GPU فعلًا؟

تتكرر الشكوى بالصيغة نفسها تقريبًا: لوحة مؤشرات العمليات تحتاج أربعين ثانية لتظهر صباحًا، وفي أثناء ذلك يتباطأ تنفيذ الطلبات في التطبيق، ثم يقترح أحدهم في الاجتماع: "نحتاج مستودع بيانات".

إن كنت تدير PostgreSQL لجهة حكومية أو بنك أو مجموعة صناعية في المملكة، فغالبًا سمعت هذا الاقتراح: انقل التقارير إلى نظام آخر، وانسخ البيانات ليلًا، واترك قاعدة المعاملات تعمل براحة. الحل ينجح، لكنه يضيف نظامًا ثانيًا يحتاج إلى تأمين، ونسخة ثانية من بيانات خاضعة للتنظيم يجب أن تبقى داخل المملكة، وأرقامًا متأخرة عن الواقع بساعات.

هذا المقال عن الخيار الآخر: أن تبقى التحليلات على قاعدة PostgreSQL التي تشغّلها الآن، مع تغيير العتاد الذي ينفّذ الجزء الثقيل من الاستعلامات. هذا هو دور CYBERTEC PGEE GPU Edition. وسنكون واضحين أيضًا في الحالات التي لا يفيد فيها.

لماذا تؤذي لوحة المؤشرات التطبيق؟

أحمال المعاملات (OLTP) وأحمال التحليل تطلب من الخادم أشياء متعاكسة.

إدخال طلب أو الاستعلام عن رصيد يلمس بضعة صفوف عبر فهرس، ويحتاج زمن استجابة منخفضًا وأقفالًا قصيرة ومعالجًا وذاكرة متاحين طوال الوقت.

أما لوحة مثل "الإيرادات حسب المنطقة واليوم خلال 18 شهرًا" فتمسح ملايين الصفوف، وتجمّعها، وتربطها بجداول مرجعية، ثم ترتّب النتيجة. إنها تريد كل الأنوية وكل ما يتيحه الخادم من عرض نطاق الذاكرة.

عندما يعمل النوعان على الخادم نفسه، يكسب الاستعلام التحليلي معركة الموارد، وتدفع المعاملات الثمن في زمن الاستجابة الأسوأ (tail latency). التنفيذ المتوازي في PostgreSQL ينهي التقرير أسرع، لكنه يفعل ذلك بأخذ مزيد من الأنوية التي يحتاجها التطبيق.

الحلّان المعتادان وكلفتهما

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

نقل التحليلات إلى مستودع بيانات. صار للتقارير عتادها الخاص، لكنك تتحمّل في المقابل:

• التأخير: خطوط ETL أو CDC تعني أن اللوحات تعرض الماضي، و"الوقت الحقيقي" يصبح "حتى آخر تحميل".

• سطح أمني ثانٍ: أدوار وصلاحيات أخرى، وسجل تدقيق آخر، ومكان إضافي تُخزَّن فيه أرقام الهوية والرواتب. وإن كنت تعتمد على التشفير الشفاف للبيانات (TDE) وإخفاء البيانات لتلبية متطلبات نظام حماية البيانات الشخصية، فستحتاج ضوابط مماثلة في النظام الجديد.

• سؤال إقامة البيانات مرة ثانية: النسخة يجب أن تبقى داخل المملكة أيضًا وتخضع للتدقيق نفسه.

• عبء الصيانة: هناك من يجب أن يتولى مهام ETL وتغيّرات المخطط والعطل الذي يقع فجرًا عندما يتغير عمود في المصدر.

لبعض الجهات هذه المقايضة صحيحة. لكن في حالات كثيرة لا يوجد المستودع إلا لأن القاعدة التشغيلية عجزت عن الإجابة عن بضعة أسئلة ثقيلة بالسرعة المطلوبة.

ما الذي يغيّره تسريع GPU فعلًا؟

تملك وحدة GPU عرض نطاق ذاكرة ومسارات تنفيذ متوازية تفوق بكثير ما في معالج مركزي، وهذا تحديدًا ما يحتاجه استعلام يمسح ويجمّع ملايين الصفوف. يضع PGEE GPU Edition هذا العتاد تحت PostgreSQL عبر عدة مكوّنات.

مُخطِّط يحسب الكلفة ويعرف GPU

يتعامل المُحسِّن مع GPU كخيار تنفيذ إضافي ويحسب كلفته مثل أي خطة أخرى. إن كانت خطة المعالج أرخص، أو كان الاستعلام لا يتوازى جيدًا على GPU، يبقى التنفيذ على المعالج. لا حاجة لوسم الاستعلامات يدويًا، ولن يُدفع استعلام غير مناسب إلى GPU بالقوة.

تنفيذ هجين بمحرّكين

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

ذاكرة مؤقتة عمودية مضغوطة على GPU

يخزّن PostgreSQL البيانات على القرص صفوفًا، فالمسح الذي يحتاج ثلاثة أعمدة من جدول فيه أربعون عمودًا يسحب الصفوف كاملة عبر الذاكرة. أما GPU Edition فيحتفظ في ذاكرة GPU بالأعمدة التي تحتاجها الاستعلامات المسرَّعة فقط، بصيغة عمودية مضغوطة، لتعمل النوى الحسابية بشكل متّجه (vectorized) على بيانات متجاورة. وتذكر CYBERTEC أن هذا التمثيل أصغر عادةً بأربع إلى ست مرات من البيانات المقابلة على القرص. وتبقى الأعمدة الأكثر استخدامًا مقيمة على GPU، فلا تدفع لوحة تتحدث كل دقيقة كلفة النقل من ذاكرة الخادم في كل مرة.

لهذا أثر مباشر على تحديد الحجم: ذاكرة GPU هي المورد الشحيح، والنسخة العمودية المضغوطة للأعمدة النشطة تتسع لحجم عمل أكبر بكثير مما تتسع له نسخة صفّية.

SQL كما هو، وتفعيل متدرّج

تتصل الاستعلامات الحالية وأدوات ذكاء الأعمال والتطبيقات بـ PostgreSQL كما تفعل اليوم، دون مشروع لإعادة كتابة SQL. ويمكن تفعيل التسريع لكل جلسة أو لكل دور (role)، فتبدأ بدور التقارير وتترك دور التطبيق على مسار المعالج بينما تقيس النتائج.

ما نشرته CYBERTEC من أرقام

لم نُجرِ اختبارات أداء خاصة بنا لهذا المقال، والأرقام التالية أمثلة منشورة من CYBERTEC وليست قياسات وربر:

• على نظام صغير من فئة DGX Spark، استغرق استعلام على 288 مليون صف 3.6 ثانية على المعالج و0.007 ثانية على GPU، والذاكرة المؤقتة دافئة في الحالتين.

• في أحمال تحليلية من نوع TPC-DS، تذكر CYBERTEC تحسّنًا كبيرًا، يتجاوز في بعض الحالات خط أساس المعالج أحادي النواة بفارق واسع جدًا.

اعتبر هذه الأرقام دليلًا على أن الآلية تعمل، لا توقعًا لنظامك. المكسب يعتمد على حجم البيانات والأعمدة النشطة وشكل الاستعلام والتزامن وطراز GPU. الرقم الوحيد الذي يجب أن يبني عليه قرار الشراء هو ما تقيسه على استعلاماتك.

أي الاستعلامات تنتقل إلى GPU وأيها يبقى؟

بحسب CYBERTEC، الفئات التي تستفيد هي:

• المسح التسلسلي الكبير مع شروط التصفية

• التجميع العددي (SUM وAVG وCOUNT على جداول كبيرة)

• التجميع بـ GROUP BY

• DISTINCT وCOUNT(DISTINCT ...)

• الربط المدعوم في مخطط النجمة (star schema)، أي جدول حقائق مع جداول أبعاد

أما البحث عن سجل بعينه، والاستعلامات التي تُرجع نتائج صغيرة عبر فهرس، وعمليات INSERT وUPDATE وDELETE في المعاملات، فتبقى عمومًا على المعالج. هذا هو المُخطِّط يؤدي عمله: إطلاق عمل على GPU لجلب خمسة صفوف عبر فهرس يكلّف أكثر مما يوفّر.

ما الذي لا يتغير؟

هذا لا يقل أهمية عن السرعة بالنسبة لمسؤول قاعدة البيانات:

• النتائج هي النتائج نفسها. تشترط CYBERTEC أن تكون نتائج GPU مطابقة بايتًا ببايت لنتائج PostgreSQL المقابلة. لا ينبغي أن تتغير مجاميع تقرير لأن المُخطِّط اختار محرّكًا آخر.

• MVCC ما زال يحدد ما تراه. تتبع الذاكرة المؤقتة على GPU قواعد الرؤية في MVCC، ولا تُستخدم البيانات المخزّنة إلا ما دامت حالة الرؤية وموضع WAL يثبتان صلاحيتها. يبقى استعلام اللوحة يرى لقطة متسقة، ولا يحجب القرّاء الكتّاب.

• ACID كما هو. الالتزام والتراجع والعزل تعمل بالطريقة نفسها؛ التسريع يخص قراءات التحليل ولا يغيّر مسار الكتابة.

• الضوابط الأمنية مستمرة. يشمل GPU Edition كل ما في CYBERTEC PGEE، فيبقى التشفير الشفاف وإخفاء البيانات يعملان.

• التوافرية العالية كما هي. Patroni والنسخ المتدفق (streaming replication) مدعومان، فتحتفظ بآلية التحويل عند الأعطال، ويمكن للخوادم الاحتياطية خدمة القراءات لزيادة السعة.

• ما زالت PostgreSQL. النسخ الاحتياطي والمراقبة وإجراءات الفريق تبقى ممارسات PostgreSQL.

العتاد والمنصة

يعتمد GPU Edition على PostgreSQL 19 وما بعده، لذا خطّط له ضمن مسار ترقية الإصدار الرئيسي. ويأتي بنوى حسابية لـ CUDA وROCm معًا، ويتوسع على عدة وحدات GPU.

أمثلة من قائمة العتاد المدعوم لدى CYBERTEC:

• NVIDIA لمراكز البيانات: A100 وL40S وH100 وH200 وB200

• NVIDIA بأحجام أصغر: L4 وRTX 50xx وGB10 (فئة DGX Spark بذاكرة موحّدة)

• AMD: سلسلة Instinct، وأنظمة Ryzen AI Max PRO 400 Series وRyzen AI Max+ 395

وتُدعم تصاميم الذاكرة الموحّدة وكذلك ذاكرة VRAM المخصصة (GDDR6X وGDDR7 وHBM3 وHBM4). ويمكن النشر على Kubernetes وOpenShift وSUSE Rancher، أو على السحابات الكبرى. والنقطة العملية للجهات الحكومية في المملكة أن العتاد يمكن أن يكون في مركز بياناتك، بجوار البيانات نفسها.

مسار جانبي لفرق الذكاء الاصطناعي: من القاعدة إلى PyTorch دون نسخ

إن كانت الجهة نفسها تدرّب نماذج أو تضبطها على بيانات تشغيلية، فهناك جزء إضافي. يستطيع عميل Python المسمى pgee_gpu عرض الأعمدة المقيمة على GPU مباشرة كموترات PyTorch للقراءة فقط، دون التصدير المعتاد إلى CSV أو Parquet ثم إعادة التحميل إلى GPU. ومثال CYBERTEC الموثّق يبني مصفوفة سمات من 20 مليون صف و8 أعمدة على NVIDIA GB10 في 0.15 ثانية، مقابل 18.1 ثانية بالتصدير التقليدي.

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

متى لا يكون هو الأداة المناسبة؟

احذر من أي مسرّع يُقدَّم كحل لكل شيء. تسريع GPU خيار ضعيف عندما:

• يغلب على الحمل معاملات قصيرة واستعلامات بحث سريعة. قراءة صف عبر فهرس تعمل على المعالج أصلًا وسيُبقيها المُخطِّط هناك. هنا PGEE القياسي والفهرسة وتجميع الاتصالات أدوات أنسب.

• يكون سبب البطء قابلًا للإصلاح. فهرس ناقص، أو تقدير خاطئ، أو إحصاءات قديمة، أو استعلامات متكررة من التطبيق. قِس أولًا، وراجع مقالنا عن القياس قبل الضبط.

• تكون المشكلة في الأقفال أو في سيل الاتصالات. هذه مشكلة تزامن لا مشكلة حوسبة؛ راجع PgBouncer في بيئة الإنتاج وتصميم المعاملات.

• يستطيع المُخطِّط تقليل الكلفة على المعالج وحده. أحيانًا يكفي تغيير العلاقة بين التجميع والربط لخفض معظم الكلفة. راجع شرح دفع التجميع (Aggregation Pushdown).

• لا يمكنك الانتقال إلى PostgreSQL 19 أو أحدث بعد. يعتمد GPU Edition عليه، فالترقية تأتي أولًا.

كيف تقيّمه دون مجازفة؟

1. اجمع الاستعلامات المسببة فعلًا. استخدم pg_stat_statements لاستخراج الأعلى في إجمالي الوقت، والتقط EXPLAIN (ANALYZE, BUFFERS) لأعلى عشرة. إن كان معظم الوقت في المسح التسلسلي والتجميع بالتجزئة وDISTINCT وربط الحقائق بالأبعاد على أعداد صفوف كبيرة، فلديك عمل يناسب GPU.

2. دوّن الأعمدة التي تلمسها. هذه المجموعة هي تقريبًا ما يجب أن يتسع في ذاكرة GPU، وهي التي تحدد حجم العتاد أكثر من الحجم الكلي للقاعدة.

3. افصل القابل للإصلاح عن البنيوي. أصلح الفهارس الناقصة والخطط السيئة أولًا، وما يبقى بطيئًا هو خط الأساس الحقيقي.

4. سجّل الرقم الذي يهم العمل. زمن تحميل اللوحة، ومدة التقرير، وزمن الاستجابة p95/p99 للمعاملات الأساسية أثناء تشغيل التقارير.

5. جرّب حسب الدور. فعّل التسريع لدور التقارير فقط، بالـ SQL نفسه والبيانات نفسها، وقارن بخط الأساس، وتأكد من تطابق مجاميع التقارير.

أين يترك هذا قرار مستودع البيانات؟

إن كانت تقاريرك تحتاج سنوات من التاريخ من أنظمة مصدر كثيرة، فقد تظل منصة تحليلات مستقلة هي الخيار الصحيح. أما إن كان مقترح المستودع قائمًا أساسًا لأن بضع لوحات على بيانات تشغيلية حية بطيئة، فجرّب الخطوة الأقل كلفة أولًا: أبقِ البيانات في PostgreSQL واحدة، تحت مجموعة واحدة من الضوابط الأمنية، داخل المملكة، وامنح الاستعلامات الثقيلة العتاد الذي يناسبها.

وربر موزّع معتمد لـ CYBERTEC في المملكة العربية السعودية، وفريقها في الرياض. أخبرنا عن أحمالك وبيئة GPU لديك، وسنجري جلسة تقييم ثم نعدّ تحديد الحجم وعرض السعر: PGEE GPU Edition — اطلب جلسة تقييم.