تجاوز UploadCreator للاستيراد

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

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

لدينا أكثر من 600,000 مرفق، لذا فإنني قلق جدًا بشأن المدة التي سيستغرقها استيرادها باستخدام استدعاء create_upload نفسه.

        upload = create_upload(u.id, photo_filename, File.basename(photo_filename))
        if upload.persisted?
          u.import_mode = false
          u.create_user_avatar
          u.import_mode = true
          u.user_avatar.update(custom_upload_id: upload.id)
          u.update(uploaded_avatar_id: upload.id)
        else
          puts "Error: Upload did not persist for #{u.username} #{photo_real_filename}!"
        end
إعجابَين (2)

هل لديك أي فكرة حول هذا يا @neounix، بما أنك قمت بتشغيل مستورد ضخم للملفات مرة واحدة؟

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

مرحبًا @TheDarkWizard

لم أستخدم سكريبتات Discourse لنقل الملفات الفعلية.

استخدمنا أدوات نقل الملفات العادية مثل tar و gzip و sftp و rsync وما إلى ذلك.

بصراحة، استخدمنا قطعًا مختلفة من سكريبتات Discourse (الهجرة)، لكن انتهى بنا الأمر بكتابة أكثر من نصف الكود الذي استخدمناه أثناء عملية الهجرة؛ لأننا قضينا شهورًا في كتابة كود gsub() لتنظيف (مراجعة) منشورات “البرمجة” التي تعود لعقود، والتي راجعها مشرفون نشروا الكثير من الأكواد على مر السنين، وكان الجميع يريد أن يكون كودهم مثاليًا بدون أي مشاكل في بناء الجملة!

اعتقدنا أن السكريبتات التي قدمها Discourse كانت نقطة انطلاق ممتازة واستخدمناها على نطاق واسع؛ كما كتبنا الكثير من أكوادنا الخاصة بناءً على تلك السكريبتات أيضًا.

نأمل أن يكون ذلك مفيدًا.

أعتذر، ربما تم تجاوز سؤالي. نحن لا نحتاج إلى تعليمات حول كيفية نقل الملفات إلى بيئة الخادم حيث يتم الاستيراد. لدينا سكريبت استيراد جماعي يكتبه @Ghan، ونحن نحاول معرفة كيفية تسريع إرفاق المرفقات. أدى الانتقال من أداة الاستيراد العادية إلى أداة الاستيراد الجماعي إلى تقليل وقت استيراد المنشورات من أسبوع إلى ساعتين تقريبًا. كنت آمل أن يتمكن أحد من توجيهنا في الاتجاه الصحيح حول كيفية التعامل مع المرفقات بشكل صحيح.

آسف إذا قرأت سؤالك بشكل خاطئ ولم تكن إجابتي مفيدة.

على أي حال، أنا متأكد من أنك ستتمكن من حل الأمر. الأمر ليس معقداً للغاية (إنه مجرد برنامج) :slight_smile: وأنتم أذكياء.

أتمنى لكم التوفيق. آسف على عدم قدرتي على المساعدة أكثر. لقد أكملنا عملية الهجرة في الربع الثاني من عام 2020، وهي (مهمة الهجرة) الآن في ماضٍ بعيد عنا.

إعجاب واحد (1)

منطقي!

موقعك يبدو رائعاً :slight_smile:

إعجاب واحد (1)

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

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

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

هذه حقيقة أساسية.