نسخ قراءة PostgreSQL للتقارير: حافظ على سرعة لوحات المعلومات

لماذا يمكن أن تبطئ التقارير قاعدة البيانات الأساسية

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

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

إليك الطرق الشائعة التي تؤذي بها لوحات المعلومات قاعدة بيانات OLTP:

• القراءات الثقيلة تتنافس على CPU والذاكرة وقراءات/كتابات القرص
• عمليات المسح الكبيرة تدفع الصفحات "الساخنة" خارج الكاش، فتبطئ الاستعلامات العادية
• الفرز الكبير وGROUP BY يكتب على القرص ويخلق دفعات حمل
• الاستعلامات طويلة التشغيل تزيد التنافس وتُطيل مدة الذروات
• عوامل التصفية التقريرية تجعل الحمل غير متوقع (نطاقات تواريخ، شرائح)

النسخة للقراءة هي خادم PostgreSQL منفصل ينسخ البيانات باستمرار من الخادم الأساسي ويمكنه خدمة استعلامات للقراءة فقط. استخدام نسخ قراءة PostgreSQL للتقارير يسمح للوحات المعلومات بتشغيل أعمالها الثقيلة في مكان آخر، حتى يظل الأساسي مركزًا على المعاملات السريعة.

التوقع الذي يجب تحديده مبكرًا: النسخ تُساعد على القراءة، لا على الكتابة. لا يمكنك إرسال INSERT/UPDATE/DELETE بأمان إلى نسخة قياسية، والنتائج قد تتأخر قليلًا عن الأساسي لأن النسخ يستغرق وقتًا. بالنسبة للعديد من اللوحات هذا تبادل مناسب: أرقام أقل "تجديدًا" قليلًا مقابل أداء ثابت للتطبيق.

إذا بُنيت لوحات داخلية (مثلاً في AppMaster) فإن هذا الانقسام غالبًا ما يتوافق بشكل جيد: يواصل التطبيق الكتابة إلى الأساسي، بينما تستعلم شاشات التقارير من النسخة.

كيف تعمل نسخ القراءة في PostgreSQL (بالعربية المبسطة)

نسخة قراءة PostgreSQL هي خادم قاعدة بيانات ثانٍ يحتفظ بنسخة قريبة من الوقت الحقيقي من قاعدة البيانات الرئيسية (الأصل). يتعامل الأساسي مع الكتابات (INSERT، UPDATE، DELETE). تخدم النسخة في الغالب القراءات (SELECT)، لذلك استعلامات التقارير لا تتنافس مع المعاملات اليومية.

الأساسي مقابل النسخة في دقيقة

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

تحت الغطاء، ينسخ PostgreSQL التغييرات عن طريق إرسال تيار مما تغيّر على الأساسي وإعادة تطبيقه على النسخة. هذا يعني أن النسخة تنتهي بنفس بنية وبيانات قاعدة البيانات، لكنها متأخرة قليلًا.

عمليًا، النسخ تنسخ:

• بيانات الجداول (الصفوف)
• تغييرات الفهارس (حتى تتمكن الاستعلامات من استخدام نفس الفهارس)
• تغييرات المخطط (مثل أعمدة جديدة، جداول جديدة، وأنواع كثيرة من الترحيلات)
• معظم تغييرات قاعدة البيانات الأخرى التي تحدث عبر SQL عادي

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

لهذا السبب تُستخدم نسخ قراءة PostgreSQL للتقارير على نطاق واسع: تفصل بين عمل OLTP (المعاملات السريعة والمتكررة) وعمل OLAP-الطراز (قراءات أطول، تجميعات، وإجماليات). إذا بنيت لوحات داخلية أو لوحات إدارة (مثلًا في AppMaster)، فإرشاد صفحات التقارير إلى نسخة هو غالبًا أسهل طريقة للحفاظ على رضا الطرفين.

أحمال العمل الشائعة التي تنتمي للنسخة

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

النمط الأكثر شيوعًا للوحة هو نطاق تاريخ واسع مع بعض الفلاتر. "آخر 90 يومًا حسب المنطقة والمنتج والقناة" يمكن أن يمس ملايين الصفوف بسهولة، حتى عندما يعرض الرسم النهائي 12 عمودًا فقط. يمكن أن تتنافس هذه المسوحات مع قاعدة البيانات الأساسية على قراءات القرص ومساحة الكاش.

أحمال تناسب النسخة جيدًا

تبدأ معظم الفرق بنقل التالي إلى قاعدة التقارير:

• الانضمامات الكبيرة عبر جداول متعددة (orders + items + customers + refunds)
• التجميعات مثل SUM، COUNT DISTINCT، حساب النسب المئوية، مجموعات الأغسام (cohorts)
• استعلامات طويلة التشغيل التي ترتب وتجمع مجموعات نتائج كبيرة
• تقارير مجدولة تعمل كل ساعة/يوم وتعيد نفس العمل الثقيل
• جلسات BI الاستكشافية حيث ينقر الأشخاص ويعيدون تشغيل تنويعات

حتى عندما يكون الاستعلام "للقراءة فقط"، يمكنه أن يحرق CPU والذاكرة وI/O. عمليات GROUP BY الكبيرة يمكن أن تدفع استعلامات أخرى خارج الذاكرة. المسوحات المتكررة يمكن أن تزعزع مخبأ البوفر، بحيث يبدأ الأساسي في القراءة من القرص أكثر.

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

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

إذا بُنيت لوحات داخلية داخل منصة مثل AppMaster، فإرشاد شاشات التقارير إلى اتصال النسخة غالبًا ما يكون فوزًا سهلًا، طالما يفهم الجميع أن البيانات قد تتأخر لبضع ثوانٍ (أو دقائق).

المقايضة: الطزاجة مقابل السرعة (تأخر النسخ)

تحافظ النسخة على سرعة اللوحات لأنها تزيل استعلامات التقارير من قاعدة البيانات الأساسية. التكلفة هي أن النسخة عادةً ما تكون متأخرة قليلًا. يسمى هذا التأخير تأخر النسخ (replication lag)، وهو المقايضة الأساسية في نسخ قراءة PostgreSQL للتقارير.

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

يحدث التأخر عندما ينتج الأساسي تغييرات أسرع مما يمكن للنسخة استلامه وإعادة تطبيقه. الأسباب الشائعة تشمل دفعات كتابة (عروض خاطفة، استيرادات)، عرض نطاق شبكة محدود، قرص بطيء على النسخة، أو استعلامات طويلة التشغيل تتنافس على CPU وI/O بينما تحاول النسخة تطبيق التغييرات.

طريقة عملية لاختيار تأخر مقبول هي مطابقته للقرار الذي تدعمه اللوحة:

• لوحات مؤشرات تنفيذية: ثوانٍ إلى بضع دقائق غالبًا ما تكون مقبولة.
• قوائم العمليات (الشحن، الدعم): استهدف تقريبًا الوقت الحقيقي، عادة ثوانٍ.
• الإغلاق المالي أو التدقيق: نفّذ على لقطة محكومة، لا "حيّة".
• صفحات "طلباتي الأخيرة" المخصصة للعملاء: قرب الوقت الحقيقي، أو استخدم الأساسي.

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

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

إذا سمح لك تطبيقك أو الأداة بدون كود باختيار اتصال قاعدة بيانات (مثل توجيه الشاشات للقراءة إلى نسخة في AppMaster)، يمكنك تطبيق هذا الانقسام من دون تغيير في كيفية بناء الفريق للواجهة.

خطوة بخطوة: إعداد نسخ القراءة للوحـات المعلومات

إعداد نسخة للوحات يتعلق في الغالب باتخاذ بعض الاختيارات الواضحة مقدمًا، ثم إبقاء حركة تقارير القراءة بعيدًا عن قاعدة البيانات الأساسية.

1) اختر الشكل الصحيح أولًا

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

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

2) بنِ النسخة كخادم تقارير

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

إليك تدفق إعداد عملي لنسخ قراءة PostgreSQL للتقارير:

• قرّر عدد النسخ ومواقعها (نفس المنطقة أو أقرب للمستخدمين).
• اختر async مقابل sync بناءً على مقدار التأخّر الذي تتحمله اللوحات.
• جهّز موارد للعمل الثقيل على القراءة (عادةً CPU، RAM، وIOPS للقرص أهم من حجم التخزين).
• أنشئ بيانات اعتماد منفصلة للقراءة فقط لمستخدمي التقارير والأدوات.
• وجّه استعلامات اللوحات إلى النسخة (كوّن التطبيق، أداة BI، أو خدمة تقارير صغيرة لاستخدام اتصال النسخة).

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

إذا بنيت التطبيقات بـ AppMaster، فهذا عادةً يعني تحديد اتصال قاعدة بيانات منفصل للتقارير واستخدامه فقط لنقاط نهاية اللوحات، حتى تظل عمليات الدفع وتدفقات المعاملات الأخرى على المسار السريع الخاص بها.

التحكم في الوصول والسلامة لمستخدمي التقارير

النسخة للقراءة رائعة للوحـات، لكنها لا تزال تحتاج حواجز حماية. عاملها كمورد مشترك: أعطِ أدوات التقارير حق الوصول الكافي فقط لأداء عملها، وحد من مقدار الضرر الذي يمكن لاستعلام سيئ أن يفعله.

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

إليك نهج بسيط يناسب معظم الفرق:

-- Create a dedicated login
CREATE ROLE report_user LOGIN PASSWORD '...';

-- Allow read-only access to a schema
GRANT CONNECT ON DATABASE yourdb TO report_user;
GRANT USAGE ON SCHEMA public TO report_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO report_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO report_user;

-- Put safety limits on the role
ALTER ROLE report_user SET statement_timeout = '30s';
ALTER ROLE report_user SET idle_in_transaction_session_timeout = '15s';

بعد ذلك، تحكم في طفرات الاتصالات. تحب اللوحات وأدوات BI فتح اتصالات كثيرة، خصوصًا عندما تحدث عدة عناصر واجهة في آن واحد. قلل اتصالات التقارير عند قاعدة البيانات وعند pooler، واجعلها منفصلة عن حركة المعاملات.

قائمة فحص عملية:

• استخدم مستخدمًا للقراءة فقط (بدون INSERT/UPDATE/DELETE، ولا تغييرات مخطط).
• اضبط مهلات زمنية لكل دور للاستعلامات الطويلة والجلسات الخاملة.
• حدّ عدد الاتصالات القصوى لمستخدمي التقارير إلى رقم آمن.
• قصر الوصول على المخططات والجداول التي تحتاجها اللوحة فقط.
• أخفِ أو استبعد الأعمدة الحساسة (PII، أسرار، رموز) من طرق العرض في التقارير.

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

تجعل هذه الضوابط نسخ قراءة PostgreSQL للتقارير سريعة ومتوقعة وأكثر صعوبة في إساءة الاستخدام.

المراقبة التي تمنع المفاجآت في لوحاتك

النسخة تساعد فقط إذا تصرفت بشكل متوقع. الشيئان اللذان يفاجئان الفرق عادةً هما تأخر النسخ الصامت (تبدو اللوحات "خاطئة") وذروات الموارد على النسخة (تصبح اللوحات بطيئة). يجب أن تلتقط المراقبة كلاهما قبل أن يلاحظه المستخدمون.

ابدأ بقياس التأخر والاتفاق على ما يعنيه "طازج بما يكفي" لعملك. بالنسبة للعديد من لوحات التقارير، 30 إلى 120 ثانية مقبولة. للبعض الآخر (مثل المخزون أو الاحتيال)، حتى 5 ثوانٍ قد تكون كثيرة. مهما اخترت، اجعلها رقمًا مرئيًا ونبه عند تجاوزه.

إليك إشارات عملية للمراقبة لنسخ قراءة PostgreSQL للتقارير:

• تأخر النسخ (بالثواني والبايت). أنذر عندما يتجاوز عتبتك لعدة دقائق، ليس فقط لقفزة مفردة.
• صحة النسخة: ضغط CPU، الذاكرة، وقراءات قرص I/O خلال ساعات الذروة.
• إشغال الاتصالات على النسخة (جلسات لوحة المعلومات المتعددة يمكن أن تبدو كأن "قاعدة البيانات بطيئة").
• الاستعلامات البطيئة على النسخة، باستخدام إحصاءات وسجلات النسخة نفسها (لا تفترض أن الأساسي يخبرك القصة كاملة).
• Autovacuum والانتفاخ (bloat) على النسخة. قد تتدهور القراءات عندما تتضخم الجداول أو الفهارس.

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

أخيرًا، قرّر مسبقًا ماذا يفعل تطبيقك عندما تكون النسخة غير متوفرة أو متأخرة جدًا. اختر سلوكًا واحدًا ونفّذه باستمرار:

• عرض لافتة "البيانات متأخرة" عندما يتجاوز التأخر العتبة.
• تعطيل أقوى المخططات مؤقتًا والابقاء على الملخصات الخفيفة.
• الرجوع إلى نتائج مخزنة مؤقتًا لفترة ثابتة (مثل آخر 15 دقيقة).
• توجيه القراءات الحرجة مرة أخرى إلى الأساسي فقط لشاشات محددة.
• وضع اللوحات في وضع صيانة قراءة فقط حتى تتعافى النسخة.

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

الأخطاء الشائعة والفخاخ التي يجب تجنّبها

النسخة تساعد، لكنها ليست زر سحري لـ "جعل التقارير مجانية". معظم مشاكل النسخ تأتي من معاملتها كمستودع تحليلات بلا حدود، ثم المفاجأة عندما تصبح اللوحات بطيئة أو خاطئة.

خطأ سهل السقوط فيه: يمكن أن تُحمّل النسخ أيضًا. بعض مسوحات الجداول الواسعة، الانضمامات الثقيلة، أو عمليات "SELECT *" للتصدير يمكن أن تضغط CPU والقرص وتؤدي إلى مهلات. إذا كانت النسخة على نُسخة أجهزة أصغر من الأساسي (شيء شائع لتوفير المال)، سيظهر التباطؤ أسرع.

إليك الفخاخ التي تسبب أكبر ألم:

• توجيه الشاشات الزمنية الحرجة إلى النسخة. إذا كانت اللوحة تُستخدم لتأكيد دفع اكتمل للتو أو إظهار مخزون حيّ، قد يجعل تأخر النسخ البيانات تبدو مفقودة.
• ترك أدوات BI تفتح الكثير من الاتصالات. بعض الأدوات تحدث الكثير من البطاقات في آن واحد، وكل بطاقة قد تفتح جلسة منفصلة.
• افتراض أن الفهارس تكفي. الفهرس لا يصلح استعلامًا يجلب ملايين الصفوف، يجمع على مفاتيح خاطئة، أو ينضم بلا حدود.
• نسيان أن "سريع مرة" ليس "سريع دائمًا". استعلام يعمل جيدًا صباحًا قد يزحف بعد نمو البيانات، أو عندما يعيد عدة أشخاص تحديث نفس التقرير.
• عدم التخطيط لسلوك التحويل في حالات الفشل. أثناء التبديل (failover)، قد يتم ترقية نسخة أو استبدالها، وقد يواجه العملاء أخطاء قراءة فقط أو نقاط نهاية قديمة إذا لم تخطط للتبديل.

مثال واقعي: أداتك BI تُحدّث صفحة "طلبات اليوم" كل دقيقة. إذا شغّلت خمسة استعلامات ثقيلة لكل تحديث و20 شخصًا لديهم الصفحة مفتوحة، فذلك يعني 100 دفعة استعلام ثقيلة في الدقيقة. قد يبقى الأساسي آمنًا، لكن النسخة قد تنهار.

إذا بنيت لوحات داخلية بمنصة مثل AppMaster، عامل قاعدة تقارير القراءة كهدف منفصل باتصالاتها وحدودها الخاصة وقواعد "الطزاجة المطلوبة" حتى لا يعتمد المستخدمون عن غير قصد على بيانات متأخرة.

أنماط تصميم تجعل التقارير أسرع على النسخة

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

فصل "طبقة التقارير"

فكّر في مخطط تقارير مخصص (مثلاً reporting) يحتوي على طرق عرض مستقرة وجداول مساعدة. هذا يمنع أدوات BI واللوحات من ضرب جداول المعاملات الخام مباشرة، ويعطيك مكانًا واحدًا للتحسين. طريقة عرض تقارير جيدة تُخفي الانضمامات الفوضوية بحيث يبقى استعلام اللوحة بسيطًا.

التجميع المسبق للأعباء الثقيلة

إذا كانت اللوحة تعيد حساب نفس الإجماليات طوال اليوم (إيرادات يومية، الطلبات حسب الحالة، أفضل المنتجات)، توقف عن الحساب من الصفر عند كل تحميل صفحة. أنشئ جداول ملخّصة أو materialized views تخزن تلك الأرقام بالفعل مجمعة.

خيارات شائعة:

• تجميعات يومية أو كل ساعة (حسب التاريخ، المنطقة، القناة)
• جداول لقطات "آخر معرفة" (المخزون، رصيد الحساب)
• جداول Top-N (أفضل المنتجات، أفضل العملاء)
• جداول حقائق مع أعمدة مُسلسلة لتصفية أسرع

تحديث المقاييس الثقيلة بجدول زمني

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

خزّن ما ينقر عليه المستخدمون باستمرار

إذا كانت نفس عناصر اللوحة تُطلب مرارًا، خزّن النتائج في طبقة التطبيق لفترة قصيرة (30 إلى 120 ثانية غالبًا كافية). على سبيل المثال، بطاقة "مبيعات اليوم" يمكن تخزينها مؤقتًا لكل شركة أو متجر. في أدوات مثل AppMaster، يكون هذا النوع من التخزين المؤقت سهل الإضافة حول نقطة النهاية API التي تغذي اللوحة.

قاعدة بسيطة: إذا كان الاستعلام بطيئًا وشائعًا، إما أن تلخّصه مسبقًا، أو تخزّنه مؤقتًا، أو كلاهما.

مثال واقعي: تقارير المبيعات دون إبطاء عملية الدفع

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

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

الحل بسيط: انقل قراءات اللوحة إلى نسخة. مع نسخ قراءة PostgreSQL للتقارير، يستمر الأساسي في إجراء الكتابات بسرعة، بينما تجيب النسخة على القراءات الطويلة. توجه اللوحة إلى سلسلة اتصال النسخة، لا إلى الأساسي.

يضبط الفريق أيضًا قواعد طزاجة واضحة حتى لا يتوقع أحد أرقامًا فورية مثالية:

• عرض "البيانات محدثة منذ X دقيقة" على اللوحة
• السماح بخمسة دقائق تأخير خلال الساعات العادية
• إذا تجاوز التأخر 10 دقائق، تحويل اللوحة إلى "وضع متأخر" وإيقاف أعقد المخططات
• إبقاء الدفع وتحديثات الطلب دائمًا على الأساسي

بعد التغيير، يكون الاختلاف ملحوظًا. يبقى الدفع مستقرًا حتى أثناء ذروات التقارير، وتُحمّل المخططات بسرعة لأنّها لم تعد تنافس المعاملات.

ما يحتاج المستخدمون لسماعه واضح: اللوحة "قريبة من الوقت الحقيقي" وليست مصدر الحقيقة لآخر 10 ثوانٍ. إذا احتاج أحدهم لأرقام دقيقة للمصالحة، فعليه تشغيل تصدير مجدول أو تقرير نهاية اليوم.

إذا بنيت التطبيق بمنصة مثل AppMaster، عامل التقارير كاتصال للقراءة منفصل من اليوم الأول حتى تظل تدفقاتك المعاملاتية متوقعة.

فحوصات سريعة وخطوات تالية

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

قائمة التحقق السريعة قبل إرسال الحركة إلى نسخة:

• اجعل اتصالات التقارير للقراءة فقط (استخدم مستخدم مخصص وفرض معاملات للقراءة فقط).
• فصل تقارير عن حركة التطبيق (مجمّع اتصال منفصل وحدود اتصالات معقولة).
• تأكد أن النسخة تحتوي على الفهارس التي تعتمد عليها لوحاتك (النسخ تنسخ الفهارس، لكن تحقق ألا تكون تغييرات حديثة مفقودة).
• اضبط statement و lock timeouts لاستعلامات التقارير حتى لا يعلق مخطط واحد كل شيء.
• تحقق من أن المخططات تتحمّل تأخيرات بسيطة (عرض طوابع زمنية "كما في" أو تقريب بالدقائق عند الحاجة).

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

قائمة المراقبة الأسبوعية (10 دقائق):

• تأخر النسخ: راقب التأخر النموذجي وأسوأ القفزات خلال ساعات الذروة.
• الاستعلامات البطيئة: تتبّع المذنبين الأعلى بوقت إجمالي، لا تشغيلات مفردة بطيئة فقط.
• الاتصالات: تحقق من الحد الأقصى للاتصالات، تشبع الpool، والاتصالات الخاملة المتراكمة.
• القرص وCPU: قد تكون النسخ عنق زجاجة على التخزين أثناء المسوحات الثقيلة.
• الاستعلامات الفاشلة: ابحث عن مهلات، عبارات مُلغاة، أو أخطاء أذونات.

الخطوات التالية تدور حول قواعد التوجيه وخطة بديلة. قرر أي نقاط نهاية آمنة دائمًا للقراءة من النسخة (لوحات، تصديرات، تقارير الإدارة)، وأيها يجب أن يبقى على الأساسي (أي شيء يتطلب حضورًا فوريًا). علّم ماذا يحدث عند عبور التأخر لحدك: عرض تحذير، تحويل قراءات فرعية إلى الأساسي، أو تعطيل أعقد المخططات مؤقتًا.

إذا كنت تبني لوحات داخلية أو أدوات إدارة، يمكن أن تكون AppMaster طريقة عملية لإطلاقها بسرعة مع توجيه شاشات التقارير إلى نسخة حتى يظل التطبيق المعاملاتي الأساسي يعمل بسلاسة.