Назад | Перейти на главную страницу

Производительность, связанная с хранением миллионов файлов в NTFS

Есть ли у кого-нибудь метод / формула и т. Д., Которые я мог бы использовать - надеюсь, на основе текущего и прогнозируемого количества файлов - для прогнозирования «правильной» длины разделения и количества вложенных папок?

Обратите внимание: хотя и похоже, это не совсем то же самое, что Хранение миллиона изображений в файловой системе. Я ищу способ сделать изложенные теории более общими.

Предположения

Перефразируй

Со временем этот магазин будет расти. Я хочу иметь лучший баланс между текущей производительностью и ростом моих потребностей. Скажем, я удвоил или утроил объем хранилища. Мне нужно уметь удовлетворять как текущие потребности, так и прогнозируемый будущий рост. Мне нужно как планировать заранее, так и не жертвовать слишком большой частью текущих результатов.

Что я придумал

Я уже подумываю об использовании хеш-разделения для каждого такого количества символов, чтобы разделить вещи по нескольким каталогам и сохранить деревья ровными, очень похожими на то, что описано в комментариях в вопросе выше. Это также позволяет избежать дублирования файлов, что со временем станет критичным.

Я уверен, что исходная структура папок будет отличаться в зависимости от того, что я обрисовал, и в зависимости от начального масштаба. Насколько я понимаю, здесь нет единого решения, подходящего для всех. На то, чтобы что-то придумать экспериментально, потребовалось бы ужасно много времени.

Несколько лет назад я начал писать систему хранения, похожую на ceph. Затем я обнаружил ceph и то, что они работали лучше, поэтому я отказался от разработки.

В процессе разработки я спросил вопрос, аналогичный вашему, но по SA Я провел много вычислений при обработке большого количества небольших файлов и обнаружил, что именование файлов (при условии, что они могут быть чем угодно) с помощью uuid и разбиение его на 3 уровня в глубину было вполне достаточно для моих нужд.

По памяти я использовал первые 3 буквы для формирования верхнего уровня, затем следующие 3 для формирования уровня 2, а затем использовал весь uuid для имени файла.

Мои расчеты основывались на количестве файлов, которые я хотел, и количестве данных на диске, а также на том, какие ограничения были для типа файловой системы.

Для UUID, если вы используете шестнадцатеричную версию, вы получите A-Z, a-z, 0-9, поэтому 26 + 26 + 9 или 61. Для трех уровней глубины это 61 * 61 * 61 = 226 981. Я полагал, что 226 тыс. Комбинаций каталогов вполне достаточно. Для XFS это нормально. Но для NTFS я не уверен. Так что вам лучше узнать, каковы настоящие пределы. Простое перечисление такого количества каталогов при открытии проводника может привести к некоторой перегрузке вашего сервера. Так что вы можете придумать схему, в которой не так много папок на верхнем уровне. Возможно, используя одну букву, углубитесь на 4 уровня или что-то в этом роде.

Вы не предоставляете версию Windows, которую будете использовать. Я действительно рекомендую использовать 2012 R2, чтобы получить все новые функции NTFS, такие как горячее восстановление.

Вашими 3 кошмарами будут:

  • Фрагментация
  • Время, затраченное на chkdsk. Время зависит от количества файлов, а не от размера.
  • Время резервного копирования

Если у вас хотя бы Windows 2012, вам стоит взглянуть на ReFS. В этой новой файловой системе есть то, что вам нужно: http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx

Проблема с ReFS, которая может возникнуть у вас: управление программным обеспечением безопасности и резервного копирования.

Если вы придерживаетесь NTFS, я бы разделил данные на множество NTFS-дисков (используя точку монтирования) и использовал бы DFS для доступа к ним (и, таким образом, чтобы связать одну корневую папку с другим диском, а затем с другим сервером для распространения) .

Вам следует поискать программу для дефрагментации, например o & o, которая идет намного дальше, чем программа для Windows. Начните дефрагментацию с самого начала и как можно чаще.

Вам понадобится много оперативной памяти для кэширования файлов (если доступ осуществляется чаще, чем раз в то время).