تصحيح أخطاء مخطط استعلام Postgres (2018)

في GoCardless ، تعد Postgres قاعدة بياناتنا المفضلة. فهي لا تدعم واجهة برمجة التطبيقات الخاصة بنا فحسب ، بل تُستخدم على نطاق واسع في Postgres في عدد من الخدمات الداخلية. نحن نحبها كثيرًا لدرجة أننا لا نصمت ، حتى عندما تسوء الأمور.

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

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

نختتم بالتدابير التي اتخذناها لمنع حدوث ذلك مرة أخرى. ما رأيناه

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

بالنظر إلى أبعد من ذلك ، وجدنا عددًا مزعجًا من طلبات البحث الطويلة جدًا التي يتم تشغيلها عادةً في أقل من 50 مللي ثانية. الآن بعد أن خشينا أننا وصلنا إلى خطة بحث سيئة ، فقد حان الوقت للعثور على مثال لطلب البحث والبحث بشكل أعمق: تحديد * تحويلات دفع DE المدفوعات الانضمام ON payments.id = payment_transitions.payment_id أين payment_transitions.payout_id = "PO00123456789Z" ORDER BY payment_transitions.id ASC الحد 1 ؛ كم عدد المدفوعات ، كم عدد الانتقالات؟

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

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

آلات في Postgres ، حيث يمثل كل انتقال سطرًا جديدًا.

سيتم تمييز حوالي 20٪ من معاملات الدفع لدينا بمعرف الدفع ، وهناك ما يقرب من 20 معاملة دفع لكل دفعة. يمكننا أن نتوقع بشكل معقول أن يزداد عدد قيم payout_id خطيًا مع حجم جدول تحويلات الدفع.

باستخدام أرقام تقريبية ، إذا كان لدينا 350 مليون عملية تحويل للدفع ، ف ...