انتخاب file system برای ذخیره record fileها

 یکی از مشکلاتی که تو بانک هست اینه که وقتی تعداد رکوردها زیاد میشه bc_cleanup که وظیفه پاک کردن رکوردهای قدیمی‌تر رو داره کند عمل میکنه. ما به ازای هر فایل رکورد دو تا فایل دیگه هم تولید میکنیم. یکی indexش هست که مشخص میکنه iframeها تو کدوم offset از record file اصلی که extensionش brf هست کجا است. این کار seek کردن رو تسریع میکنه. یکی دیگه هم فایل db هست. این فایل نظیر رکوردی است که به ازای فایل رکورد در دیتابیس ایجاد میکنیم. در این صورت اگر جدول Events هم بپره میتونیم با استفاده از scriptی که به همین منظور نوشته‌ام دوباره اون رو ایجاد کنیم. این script اطلاعات موجود در این db fileها رو به database اضافه میکنه.

پس به ازای هر رکوردی سه تا فایل تولید میشه. وقتی ۴۰۰ هزارتا رکورد داریم طبعاً تعداد فایلهامون از یک میلیون تجاوز میکنه. حسین میگه وقتی یک find ساده میزنم روی directoryیی که رکوردها درش قرار دارند نیم ساعت طول میکشه تا جواب بده. برای همین بهش گفتم لازمه file systemهای مختلف رو برای ذخیره رکوردهامون benchmark کنیم. حالا او جدا منم جدا دارم این تست رو انجام میدم. file systemهایی که دارم روشون تستهام رو انجام میدم اینها هستند:

fat32, ntfs, resiserfs, xfs, zfs, exfat, ext4

قبلاً روی هارد سیستمم تو شرکت partitionهای مختلفی ایجاد کرده بودم. فکر میکردم یه روزی لازم بشه چنین تستهایی انجام بدیم. الان دو سه روزه دارم تستهای مختلفی روشون انجام میدم، از این قبیل:

۱. ایجاد تعداد زیادی فایل
۲. move کردن این فایلها
۳. remove کردن اونها
۴. dump کردنشون با ls
۵. remove کردن یکی از اونها
۶. find کردن یکی از اونها

میخوایم ببینیم هرکدوم از این موارد روی file systemهای مختلف چقدر طول میکشه. تست عمیقتر اینه که یه دور وقتی file system مشغولیتی نداره اینها رو تست کنیم و یه دور وقتی زیر باره. مثل وقتی که داره توش فایل ایجاد میشه یا وقتی داره move صورت میگیره. در حال حاضر هنوز برای قضاوت زوده، اما ext4 که بر خلاف انتظار داره خیلی کند عمل میکنه، fat32 هم که تعداد فایلهای محدودی رو میتونه در یک directory نگه داره (حداکثر ۶۵۵۳۵ تا). از همه‌شون بهتر تا به حال بر خلاف انتظار ntfs عمل کرده، مخصوصاً در ششمین مورد که بیشتر مد نظرمون هست. حالا حسین هم داره جدا تست میکنه. ببینیم به چه نتیجه‌ای خواهیم رسید.

برای اینکه ایجاد فایلها با سرعت بیشتری انجام بشه createLotsOfFiles.c رو نوشتم. به عنوان آرگومان حداکثر رو میگیره و از فایل 00000000 شروع به ایجاد میکنه تا برسه به اون عدد. فایلها حداقل ۸ کاراکتری است تا sortش درست انجام بشه. فکر نمیکنم به بیش از این تعداد نیازی باشه، اما اگر بزنید ایجاد میکنه.

برای move کردن نمیتونستم مثلاً بزنم mv * 1 تا اونها رو به directory دیگه‌ای به اسم 1 منتقل کنه. چون تعداد فایلها زیاد بود. برای همین یه move.c هم نوشتم تا دو تا directory رو به عنوان آرگومان بگیره و همه فایلها رو از directory اول به directory دوم منتقل کنه. مثلاً میتونیم بزنیم move . 1 تا همون کار رو برامون انجام بده. هر فایلی رو هم که شروع به انتقال میکنه اسمش رو مینویسه تا بتونیم وضعیت رو بهتر بررسی کنیم، کجا گیر میکنه، سرعتش چقدره و غیره. از اونجایی که از تابع rename برای انتقال استفاده کرده‌ام لازمه انتقال بین دو file system صورت نگیره، و الا طبعاً خطا میده. چون هدفم هم این نبود طبعاً محدودیتی برای این برنامه نیست.

نظرات

پست‌های معروف از این وبلاگ

دوربین Avigilon جدید

مقدمه

تغییرات داده شده در database در ارتباط با دوربین Hikvision DS-2CD1123G0E-I