Щойно я додав функцію прогностичного пошуку (див. Приклад нижче) на свій сайт, який працює на сервері Ubuntu. Це працює безпосередньо з бази даних. Я хочу кешувати результат для кожного пошуку та використовувати його, якщо він існує, створити його.
Чи буде якась проблема зі мною збереження потенційних 10-мільйонних результатів в окремих файлах в одному каталозі? Або доцільно розділити їх на папки?
Приклад:
5
Було б краще розділитись. Будь-яка команда, яка намагається перерахувати вміст цього каталогу, швидше за все, вирішить самостійно знімати.
—
муру
Тож якщо у вас вже є база даних, чому б не використовувати її? Я впевнений, що СУБД зможе краще обробляти мільйони записів проти файлової системи. Якщо ви готові використовувати файлову систему, вам потрібно придумати схему розбиття за допомогою якогось хеша, в цьому моменті IMHO звучить, як використання БД буде менше працювати.
—
roadmr
Ще одним варіантом кешування, який би краще відповідав вашій моделі, може бути певний або перероблений. Вони є ключовими сховищами цінності (тому вони діють як один каталог, і ви отримуєте доступ до елементів просто за назвою). Redis є стійким (не втратить дані при його перезапуску) там, де запам'ятовується для більш тимчасових предметів.
—
Стівен Остерміллер
Тут є проблема з куркою і яйцями. Розробники інструментів не обробляють каталоги з великою кількістю файлів, оскільки люди цього не роблять. І люди не роблять каталогів з великою кількістю файлів, оскільки інструменти не підтримують її добре. Наприклад, я зрозумів свого часу (і я вважаю, що це все-таки так), запит на особливості зробити генераторну версію
os.listdirв python з цієї причини було категорично відхилено.
З власного досвіду я бачив поломку при переході 32k файлів в одному каталозі на Linux 2.6. Можна, звичайно, налаштовуватися за цією точкою, але я б не рекомендував це. Просто розділіть на кілька шарів підкаталогів, і це буде набагато краще. Особисто я обмежую його приблизно 10 000 за каталог, який дасть вам 2 шари.
—
Вольф
