كيو سؤال الأمثل وعملية مدير مكتب البريد "

Question

وأنا أعمل حاليا مع أكبر ويكيبيديا تفريغ قاعدة بيانات كيو المشتقة؛ أنه يحتوي على حوالي 40 GB من البيانات. يتم تشغيل قاعدة البيانات على خادم G5 الجهاز HP Proliant ML370 مع سوزي لينكس إنتربرايز سيرفر 10؛ أنا الاستعلام عن ذلك من جهاز الكمبيوتر المحمول عبر شبكة اتصال خاصة يديرها بسيط موجه D-لينك. I تعيين ثابتة DHCP المتكاملة (خاصة) لكلا المحمولة والخادم.

وعلى أي حال، من جهاز الكمبيوتر المحمول، وذلك باستخدام pgAdmin III، I توديع بعض الأوامر SQL / الاستفسارات. بعض من هؤلاء CREATE INDEX، DROP INDEX، DELETE، SELECT، وما إلى ذلك في بعض الأحيان أبعث أمر (مثل CREATE INDEX)، فإنه يعود، وقال لي أن الاستعلام أعدم تماما، وما إلى ذلك، فإن عملية مدير مكتب البريد المخصصة لمثل هذه يبدو الأمر لتبقى النوم على الخادم. الآن، أنا لا أمانع حقا هذا، لأني أقول لنفسي أن يحافظ كيو مجموعة من مدراء مكاتب البريد مستعدة لمعالجة استفسار. ومع ذلك، وإذا كانت هذه العملية تلتهم 6 GB منه 9.4 GB RAM المخصصة، أنا قلق (وهو يفعل ذلك في الوقت الحالي). الآن ربما هذا هو مخبأ البيانات التي يتم الاحتفاظ بها في الذاكرة [المشتركة] في حالة حدوث استفسار آخر في حاجة إلى استخدام تلك البيانات نفسها، ولكن أنا لا أعرف.

وشيء آخر هو يزعجني.

ولقد 2 الجداول. واحد هو صفحة الجدول؛ لدي مؤشر عن دورتها <م> PAGE_ID العمود. والآخر هو pagelinks الجداول التي لديها <م> pl_from العمود الذي يشير إما لا شيء أو متغير في page.page_id العمود. على عكس <م> PAGE_ID عمود، <م> pl_from لا يوجد لديه مؤشر (حتى الآن). لإعطائك فكرة عن حجم الجداول وضرورة بالنسبة لي لإيجاد حل ناجع، <م> صفحة الجدول يحتوي على 13.4 مليون الصفوف (بعد أن حذف هذه لا حاجة لي) في حين أن <م> pagelinks الجدول يحتوي على 293 مليون.

ولست بحاجة إلى تنفيذ الأمر التالي لتنظيف <م> pagelinks جدول بعض صفوفه عديمة الفائدة:

DELETE FROM pagelinks USING page WHERE pl_from NOT IN (page_id);

وذلك في الأساس، وأتمنى لتخليص <م> pagelinks جدول كافة الروابط القادمة من صفحة لا في صفحة الجدول. حتى بعد تعطيل حلقات متداخلة و / أو التفحص متسلسلة، محسن الاستعلام يعطي لي دائما "الحل" التالية:

Nested Loop  (cost=494640.60..112115531252189.59 rows=3953377028232000 width=6)
  Join Filter: ("outer".pl_from <> "inner".page_id)"
  ->  Seq Scan on pagelinks  (cost=0.00..5889791.00 rows=293392800 width=17)
  ->  Materialize  (cost=494640.60..708341.51 rows=13474691 width=11)
        ->  Seq Scan on page  (cost=0.00..402211.91 rows=13474691 width=11)

ويبدو أن هذه المهمة ستستغرق أكثر من أسبوعين لإكمال. من الواضح، وهذا أمر غير مقبول. ويبدو لي أن وأود أن كثيرا بل استخدام الفهرس <م> PAGE_ID لبذل كل شيء ... وإنما هو محسن عنيد وأنا قد أكون مخطئا.

Answer 1

والواقع أنني قررت إنشاء جدول مؤقت لتسريع تنفيذ الاستعلام:

CREATE TABLE temp_to_delete AS(
    (SELECT DISTINCT pl_from FROM pagelinks) 
        EXCEPT 
    (SELECT page_id FROM page));
DELETE FROM pagelinks USING temp_to_delete 
    WHERE pagelinks.pl_from IN (temp_to_delete.pl_from);

والمثير للدهشة، الانتهاء من هذا الاستعلام في حوالي 4 ساعات في حين أن الاستعلام الأولي ظلت نشطة لمدة 14hrs قبل أن أقرر للقضاء عليها. وبشكل أكثر تحديدا، حذف عاد:

Query returned successfully: 31340904 rows affected, 4415166 ms execution time.

وأما بالنسبة للجزء الأول من سؤالي، يبدو أن عملية مدير مكتب البريد يحتفظ بالفعل بعض المعلومات في ذاكرة التخزين المؤقت. عندما يتطلب استفسار آخر المعلومات ليس في ذاكرة التخزين المؤقت وبعض ذاكرة (RAM)، يتم إفراغ ذاكرة التخزين المؤقت. ومدراء مكاتب البريد هي في الواقع ولكن مجموعة من العملية ".

وحدث أيضا بالنسبة لي أن <م> جنوم نظام رصد هو أسطورة لأنه يعطي معلومات غير كاملة ولا قيمة لها في القيمة المعلوماتية. ومن المقرر معظمها إلى هذا التطبيق أن أكون قد تم ذلك الخلط في الآونة الأخيرة. على سبيل المثال، أنها لا تعتبر استخدام الذاكرة من المستخدمين الآخرين (مثل المستخدم بوستجرس!) وحتى يقول لي ان لدي 12 GB من ذاكرة الوصول العشوائي غادر عند هذا غير صحيح لذلك. وبالتالي، حاولت من زوجين من المراقبين نظام أود أن أعرف كيفية استخدام كيو مواردها، ويبدو أن <م> xosview هو في الواقع أداة صالحة.

وآمل أن يساعد هذا!

Answer 2

لسؤالك الثاني، قد تتمكن من محاولة إنشاء جدول جديد مع فقط السجلات التي تحتاج إليها مع CREATE TABLE AS بيان. إذا كان الجدول الجديد صغير بما فيه الكفاية، فإنه قد يكون faster- ولكن قد لا يساعد أيضا.

Answer 3

وعملية مدير مكتب البريد الخاص بك سوف تبقى هناك طالما أن اتصال العميل مفتوح. هل pgadmin إغلاق الاتصال؟ أنا لا أعرف.

والذاكرة المستخدمة يمكن أن يكون shared_buffers (التحقق من إعدادات التكوين الخاص بك) أم لا.

والآن، الاستعلام. لعمليات صيانة كبيرة مثل هذه، لا تتردد في وضع work_mem إلى شيء كبير مثل عدد قليل GB. أنت تبدو وكأنها حصلت على الكثير من ذاكرة الوصول العشوائي، واستخدام ذلك.

ووضع work_mem إلى '4GB'؛ شرح حذف من pagelinks WHERE pl_from NOT IN (SELECT PAGE_ID من الصفحة)؛

ووينبغي الصفحة مسح يليها، تجزئة ذلك، ويليها pagelinks المسح، تطل في تجزئة للتحقق من page_ids. يجب أن تكون سريعة جدا (أسرع بكثير من 4 ساعات!) ولكن كنت في حاجة الى work_mem كبيرة للتجزئة.

ولكن بما انك حذف جزء كبير من الجدول الخاص بك، قد يكون أسرع إلى القيام بذلك مثل هذا:

وCREATE TABLE pagelinks2 AS SELECT * FROM على pagelinks على الانضمام صفحات ب ON a.pl_from = b.page_id؛

و(هل يمكن استخدام بسيطة JOIN بدلا من IN)

ويمكنك أيضا إضافة ORDER BY على هذا الاستعلام، وسوف يكون الجدول الجديد أمر لطيف على القرص في وقت لاحق الوصول الأمثل.