سؤال

لقد انتهيت للتو من نقل أكبر قدر ممكن من بيانات بنية الارتباط المتعلقة بويكيبيديا (باللغة الإنجليزية).في الأساس، قمت بتنزيل مجموعة من ملفات SQL من ويكيبيديا أحدث مستودع تفريغ.نظرًا لأنني أستخدم PostgreSQL بدلاً من MySQL، فقد قررت تحميل كل عمليات التفريغ هذه في قاعدة البيانات الخاصة بي باستخدام أوامر قذيفة خط الأنابيب.

على أية حال، أحد هذه الجداول يحتوي على 295 مليون صف:ال روابط الصفحات طاولة؛فهو يحتوي على كافة الارتباطات التشعبية داخل الويكي.من جهاز الكمبيوتر المحمول الخاص بي، وباستخدام pgAdmin III، أرسلت الأمر التالي إلى خادم قاعدة البيانات الخاص بي (كمبيوتر آخر):

SELECT pl_namespace, COUNT(*) FROM pagelinks GROUP BY (pl_namespace);

لقد كان في ذلك لمدة ساعة أو نحو ذلك الآن.المشكلة هي أن مدير مكتب البريد يبدو أنه يستهلك المزيد والمزيد من مساحة HD المحدودة للغاية.أعتقد أنه أكل حوالي 20 غيغابايت حتى الآن.لقد سبق لي أن قمت بتجربة ملف postgresql.conf لمنحه المزيد من المرونة في الأداء (أي.دعه يستخدم المزيد من الموارد) لأنه يعمل بذاكرة وصول عشوائي (RAM) تبلغ 12 جيجابايت.أعتقد أنني ضاعفت معظم وحدات البايت أربع مرات والمتغيرات ذات الصلة بهذا الملف معتقدًا أنه سيستخدم المزيد من ذاكرة الوصول العشوائي للقيام بعمله.

ومع ذلك، لا يبدو أن قاعدة البيانات تستخدم الكثير من ذاكرة الوصول العشوائي.باستخدام شاشة نظام Linux، أستطيع أن أرى أن مدير مكتب البريد يستخدم 1.6 جيجابايت من الذاكرة المشتركة (RAM).على أي حال، كنت أتساءل عما إذا كان بإمكانكم يا رفاق مساعدتي في فهم ما يفعله بشكل أفضل لأنه يبدو أنني لا أفهم حقًا كيف يستخدم PostgreSQL موارد HD.

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

لا تتردد في أن تطلب مني المزيد من التفاصيل، ثكس.

هل كانت مفيدة؟

المحلول

وانها على الارجح GROUP BY هذا ما يسبب المشكلة. من أجل القيام التجمع، وقاعدة بيانات لديه لفرز الصفوف لوضع عناصر مكررة معا. مؤشر ربما لن يساعد. عملية حسابية الخلفي من بين المغلف:

وعلى افتراض كل صف يأخذ 100 بايت من المساحة، وهذا هو 29500000000 بايت، أو حوالي 30GB للتخزين. لا يمكن ان تناسب كل ما في الذاكرة، لذلك النظام هو سحق، الذي يبطئ العمليات بنسبة عاملا من 1000 أو أكثر. مساحة HD الخاص بك قد تتلاشى في الفضاء المبادلة إذا انها تستخدم تبادل الملفات.

إذا ما عليك سوى أن تفعل هذا الحساب مرة واحدة، في محاولة كسر إربا إلى مجموعات فرعية أصغر من البيانات. على افتراض pl_namespace غير رقمي ويتراوح من 1-295million، حاول شيئا من هذا القبيل:

SELECT pl_namespace, COUNT(*)
FROM pagelinks
WHERE pl_namespace between 1 and 50000000
GROUP BY (pl_namespace);

وثم نفعل نفس الشيء بالنسبة 50٬000٬001-100٬000٬000 وهكذا دواليك. الجمع بين إجاباتك معا باستخدام UNION أو ببساطة جدولة النتائج مع برنامج خارجي. نسيت ما كتبت عن مؤشر لا يساعد GROUP BY. هنا، سوف مؤشر تساعد شرط WHERE.

نصائح أخرى

ماذا بالضبط تدعي أنها تستهلك 9.5 ميغابايت فقط من ذاكرة الوصول العشوائي؟يبدو هذا غير مرجح بالنسبة لي، فالذاكرة المشتركة تكاد تكون مؤكدة يكون ذاكرة الوصول العشوائي (RAM) التي تتم مشاركتها بين عمليات Postgres المختلفة.(مما أتذكره، أن كل عميل ينتهي به الأمر كعملية منفصلة، ​​على الرغم من مرور فترة طويلة، لذا قد أكون مخطئًا جدًا.)

هل لديك فهرس على pl_namespace عمود؟إذا كان هناك عدد كبير جدًا من النتائج المميزة، فيمكنني أن أتخيل أن هذا الاستعلام ثقيل جدًا على جدول صف يبلغ 295 مليونًا بدون فهرس.ومع ذلك، فإن سعة 10 غيغابايت هي كمية كبيرة لا يمكن ابتلاعها.هل تعرف الملفات التي يكتب إليها؟

وطيب حتى هنا هو جوهر ما يلي:

وجملة GROUP BY جعلت مؤشر "غير صالح، وبالتالي فإن مدير مكتب البريد (عملية خادم كيو) قررت إنشاء مجموعة من الجداول (23GB من الجداول) التي كانت موجودة في الدليل $ PGDATA / القاعدة / 16384 / pgsql_tmp.

عند تعديل الملف postgresql.conf، وكنت قد أعطيت الإذن لكيو لاستخدام 1.6 GB من ذاكرة الوصول العشوائي (والتي سوف الآن مضاعفة لأنه لديه حق الوصول إلى 11.7 GB من ذاكرة الوصول العشوائي)؛ عملية مدير مكتب البريد كان في الواقع يستخدم بنسبة 1.6 GB من ذاكرة الوصول العشوائي، ولكن ذلك لم يكن كافيا، وبالتالي فإن الدليل pgsql_tmp.

وكما أشار باري براون، منذ أن تم تنفيذ هذا الأمر فقط SQL للحصول على بعض المعلومات الإحصائية حول توزيع الروابط بين pagelinks.namespaces ، كان يمكن أن الاستعلام مجموعة فرعية من و296،000،000 <م> pagelinks (هذا هو ما يفعلونه لعمليات المسح).

وعندما عاد الأمر مجموعة النتائج، تم حذف كافة الجداول المؤقتة تلقائيا كما لو أن شيئا لم يحدث.

وتشك للرجال مساعدتكم!

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top