كيف تتعامل مع الكثير من الملفات الصغيرة؟
https://stackoverflow.com/questions/115882
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
يجمع المنتج الذي أعمل عليه عدة آلاف من القراءات يوميًا ويخزنها كملفات ثنائية بحجم 64 كيلو بايت على قسم NTFS (نظام التشغيل Windows XP).بعد عام من الإنتاج، يوجد أكثر من 300000 ملف في دليل واحد ويستمر العدد في النمو.وقد جعل هذا الوصول إلى أدلة الأصل/الأسلاف من مستكشف Windows يستغرق وقتًا طويلاً للغاية.
لقد حاولت إيقاف تشغيل خدمة الفهرسة ولكن ذلك لم يحدث أي فرق.لقد فكرت أيضًا في نقل محتوى الملف إلى قاعدة بيانات/ملفات مضغوطة/كرات القطران ولكن من المفيد لنا الوصول إلى الملفات بشكل فردي؛في الأساس، لا تزال الملفات مطلوبة لأغراض البحث والباحثون غير مستعدين للتعامل مع أي شيء آخر.
هل هناك طريقة لتحسين NTFS أو Windows حتى يتمكن من العمل مع كل هذه الملفات الصغيرة؟
المحلول
يتدهور أداء NTFS بشدة بعد وجود 10000 ملف في الدليل.ما تفعله هو إنشاء مستوى إضافي في التسلسل الهرمي للدليل، حيث يحتوي كل دليل فرعي على 10000 ملف.
من الجدير بالذكر أن هذا هو النهج الذي اتبعه أعضاء SVN الإصدار 1.5.لقد استخدموا 1000 ملف كحد أدنى افتراضي.
نصائح أخرى
في الواقع، سيعمل NTFS بشكل جيد مع أكثر من 10000 ملف في الدليل طالما طلبت منه التوقف عن إنشاء أسماء ملفات بديلة متوافقة مع أنظمة Windows الأساسية 16 بت.افتراضيًا، يقوم NTFS تلقائيًا بإنشاء اسم ملف "8 نقطة 3" لكل ملف يتم إنشاؤه.تصبح هذه مشكلة عند وجود العديد من الملفات في الدليل لأن Windows يقوم بفحص الملفات الموجودة في الدليل للتأكد من أن الاسم الذي يقومون بإنشائه ليس قيد الاستخدام بالفعل.يمكنك تعطيل تسمية "8 نقطة 3" عن طريق تعيين قيمة التسجيل NtfsDisable8dot3NameCreation على 1.تم العثور على القيمة في مسار التسجيل HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem.من الآمن إجراء هذا التغيير لأن ملفات الأسماء "8 dot 3" مطلوبة فقط من خلال البرامج المكتوبة للإصدارات القديمة جدًا من Windows.
يلزم إعادة التشغيل قبل أن يصبح هذا الإعداد ساري المفعول.
ترجع مشكلة الأداء إلى الكم الهائل من الملفات الموجودة في دليل واحد:بمجرد القضاء على ذلك، يجب أن تكون على ما يرام.هذه ليست مشكلة خاصة بـ NTFS:في الواقع، يتم مواجهتها بشكل شائع مع ملفات المستخدم الرئيسية/البريد على أنظمة UNIX الكبيرة.
إحدى الطرق الواضحة لحل هذه المشكلة هي نقل الملفات إلى مجلدات ذات اسم يعتمد على اسم الملف.على افتراض أن جميع ملفاتك لها أسماء ملفات ذات طول مماثل، على سبيل المثال.ABCDEFGHI.db، ABCEFGHIJ.db، إلخ، قم بإنشاء بنية دليل مثل هذا:
ABC\
DEF\
ABCDEFGHI.db
EFG\
ABCEFGHIJ.db
باستخدام هذه البنية، يمكنك تحديد موقع الملف بسرعة بناءً على اسمه.إذا كانت أسماء الملفات ذات أطوال متغيرة، فاختر الحد الأقصى للطول وأضف الأصفار (أو أي حرف آخر) لتحديد الدليل الذي ينتمي إليه الملف.
لقد رأيت تحسينات كبيرة في الماضي من خلال تقسيم الملفات إلى تسلسل هرمي متداخل من الأدلة، على سبيل المثال، الحرف الأول ثم الثاني من اسم الملف؛فإن كل دليل لا يحتوي على عدد زائد من الملفات.ومع ذلك، فإن معالجة قاعدة البيانات بأكملها لا تزال بطيئة.
يمكنك تجربة استخدام شيء مثل نظام الملفات الصلبة.
يمنحك هذا نظام ملفات افتراضيًا يمكن للتطبيقات تركيبه كما لو كان قرصًا فعليًا.يرى التطبيق الخاص بك الكثير من الملفات الصغيرة، ولكن يوجد ملف واحد فقط على محرك الأقراص الثابتة لديك.
إذا كان بإمكانك حساب أسماء الملفات، فقد تتمكن من فرزها في مجلدات حسب التاريخ، بحيث يحتوي كل مجلد على ملفات لتاريخ معين فقط.قد ترغب أيضًا في إنشاء تسلسلات هرمية للشهر والسنة.
أيضًا، هل يمكنك نقل الملفات الأقدم من سنة مثلاً إلى موقع مختلف (ولكن لا يزال من الممكن الوصول إليها)؟
أخيرًا، ومرة أخرى، يتطلب هذا منك أن تكون قادرًا على حساب الأسماء، ستجد أن الوصول المباشر إلى الملف أسرع بكثير من محاولة فتحه عبر المستكشف.على سبيل المثال قوله
notepad.exe "P:\ath o\your\filen.ame"
من سطر الأوامر يجب أن يكون سريعًا جدًا، على افتراض أنك تعرف مسار الملف الذي تحتاجه دون الحاجة إلى الحصول على قائمة الدليل.
إحدى الحيل الشائعة هي ببساطة إنشاء مجموعة من الأدلة الفرعية وتقسيم الملفات.
على سبيل المثال، Doxygen، وهو برنامج توثيق التعليمات البرمجية الآلي الذي يمكن أن ينتج عددًا كبيرًا من صفحات html، لديه خيار لإنشاء تسلسل هرمي عميق للدليل من مستويين.ثم يتم توزيع الملفات بالتساوي عبر الدلائل السفلية.
إن وجود مئات الآلاف من الملفات في دليل واحد سيؤدي بالفعل إلى تعطيل نظام NTFS، وليس هناك الكثير مما يمكنك فعله حيال ذلك.يجب عليك إعادة النظر في تخزين البيانات بتنسيق أكثر عملية، مثل كرة قطران واحدة كبيرة أو في قاعدة بيانات.
إذا كنت تحتاج حقًا إلى ملف منفصل لكل قراءة، فيجب عليك فرزها إلى عدة أدلة فرعية بدلاً من وضعها جميعًا في نفس الدليل.يمكنك القيام بذلك عن طريق إنشاء تسلسل هرمي للأدلة ووضع الملفات في مجلدات مختلفة اعتمادًا على اسم الملف.بهذه الطريقة، لا يزال بإمكانك تخزين ملفاتك وتحميلها بمعرفة اسم الملف فقط.
الطريقة التي نستخدمها هي أخذ الأحرف القليلة الأخيرة من اسم الملف، وعكسها، وإنشاء أدلة مكونة من حرف واحد من ذلك.خذ بعين الاعتبار الملفات التالية على سبيل المثال:
1.xml
24.xml
12331.xml
2304252.xml
يمكنك فرزها في الدلائل مثل ذلك:
data/1.xml
data/24.xml
data/1/3/3/12331.xml
data/2/5/2/4/0/2304252.xml
سيضمن هذا المخطط أنك لن يكون لديك أكثر من 100 ملف في كل دليل.
لقد واجهت هذه المشكلة مرات عديدة في الماضي.لقد حاولنا التخزين حسب التاريخ، وضغط الملفات أسفل التاريخ حتى لا يكون لديك الكثير من الملفات الصغيرة، وما إلى ذلك.كانت جميعها بمثابة حلول للمشكلة الحقيقية المتمثلة في تخزين البيانات على شكل الكثير من الملفات الصغيرة على نظام NTFS.
يمكنك الانتقال إلى ZFS أو أي نظام ملفات آخر يتعامل مع الملفات الصغيرة بشكل أفضل، ولكن لا يزال عليك التوقف والسؤال عما إذا كنت بحاجة إلى تخزين الملفات الصغيرة.
في حالتنا، ذهبنا في النهاية إلى نظام تم فيه إلحاق جميع الملفات الصغيرة لتاريخ معين بطريقة من نوع TAR مع محددات بسيطة لتحليلها.انخفض عدد ملفات القرص من 1.2 مليون إلى أقل من بضعة آلاف.لقد تم تحميلها بشكل أسرع لأن نظام NTFS لا يمكنه التعامل مع الملفات الصغيرة بشكل جيد، وكان محرك الأقراص أكثر قدرة على تخزين ملف بحجم 1 ميجابايت مؤقتًا على أي حال.في حالتنا، كان وقت الوصول والتحليل للعثور على الجزء الصحيح من الملف ضئيلًا مقارنة بالتخزين الفعلي وصيانة الملفات المخزنة.
وبصرف النظر عن وضع الملفات في الدلائل الفرعية ..
شخصيًا، سأقوم بتطوير تطبيق يحافظ على واجهة هذا المجلد كما هي، أي يتم عرض جميع الملفات كملفات فردية.بعد ذلك، في خلفية التطبيق، يتم أخذ هذه الملفات فعليًا ودمجها في ملفات أكبر (وبما أن الأحجام دائمًا هي 64 كيلو بايت، فيجب أن يكون الحصول على البيانات التي تحتاجها أمرًا سهلاً نسبيًا) للتخلص من الفوضى التي تعاني منها.
لذلك لا يزال بإمكانك تسهيل وصولهم إلى الملفات التي يريدونها، ولكن يتيح لك أيضًا التحكم بشكل أكبر في كيفية تنظيم كل شيء.
هل تفكر في دفعهم إلى خادم آخر يستخدم نظام ملفات أكثر ملاءمة لكميات هائلة من الملفات الصغيرة (Solaris w/ZFS على سبيل المثال)؟
إذا كانت هناك أي جوانب ذات معنى وفئوية من البيانات، فيمكنك دمجها في شجرة الدليل.أعتقد أن التباطؤ يرجع إلى عدد الملفات الموجودة في دليل واحد، وليس العدد الهائل للملفات نفسها.
التجميع العام الأكثر وضوحًا هو حسب التاريخ، ويمنحك بنية تداخل ثلاثية الطبقات (السنة والشهر واليوم) مع ربط آمن نسبيًا بعدد الملفات في كل دليل طرفي (1-3 كيلو).
حتى لو كنت قادرًا على تحسين أداء نظام الملفات/متصفح الملفات، يبدو أن هذه مشكلة ستواجهها خلال عامين أو 3 أعوام آخرين...مجرد النظر إلى قائمة من 0.3 إلى 1 مليون ملف سيتحمل تكلفة، لذلك قد يكون من الأفضل على المدى الطويل العثور على طرق للنظر فقط إلى مجموعات فرعية أصغر من الملفات.
يمكن أن يؤدي استخدام أدوات مثل 'find' (ضمن cygwin أو mingw) إلى عدم وجود مشكلة في وجود شجرة الدليل الفرعي عند تصفح الملفات.
قم بإعادة تسمية المجلد كل يوم بطابع زمني.
إذا كان التطبيق يحفظ الملفات في c: eadings، فقم بإعداد مهمة مجدولة لإعادة تسمية القراءة عند منتصف الليل وإنشاء مجلد فارغ جديد.
ثم ستحصل على مجلد واحد لكل يوم، يحتوي كل منها على عدة آلاف من الملفات.
يمكنك توسيع الطريقة بشكل أكبر للتجميع حسب الشهر.على سبيل المثال، C: eading يصبح c:\Archive\September\22.
يجب عليك توخي الحذر بشأن توقيتك للتأكد من أنك لا تحاول إعادة تسمية المجلد أثناء حفظ المنتج فيه.
لإنشاء بنية مجلد يمكن توسيع نطاقها إلى عدد كبير غير معروف من الملفات، أحب النظام التالي:
قم بتقسيم اسم الملف إلى أجزاء ذات طول ثابت، ثم قم بإنشاء مجلدات متداخلة لكل قطعة باستثناء الأخيرة.
وتتمثل ميزة هذا النظام في أن عمق بنية المجلد لا يزيد إلا بمقدار طول اسم الملف.لذلك، إذا تم إنشاء ملفاتك تلقائيًا بتسلسل رقمي، فإن البنية تكون عميقة فقط كما يجب أن تكون.
12.jpg -> 12.jpg
123.jpg -> 12\123.jpg
123456.jpg -> 12\34\123456.jpg
يعني هذا الأسلوب أن المجلدات تحتوي على ملفات ومجلدات فرعية، لكنني أعتقد أنها مقايضة معقولة.
وهنا أ جميل PowerShell بطانة واحدة لتنطلق!
$s = '123456'
-join (( $s -replace '(..)(?!$)', '$1\' -replace '[^\\]*$','' ), $s )
