Что лучший способ состоит в том, чтобы сохранить тысячи изображений в структуре папок окон?
Это зависит, в чем Вы нуждаетесь от DAG. У Вас может быть несколько типов DAG - "нормальный" DAG и "Изолированная Копия DAG", который используется больше для аварийного восстановления.
Сколько копий, которые Вы должны иметь, является (по-моему), большим количеством бизнес-решения, чем IT один.
"Нормальный" DAG является в основном копией указанных баз данных почтового ящика. У Вас было бы несколько копий, когда Вы хотите, чтобы обработка отказа произошла прозрачно с Вашими конечными пользователями. Это позволяет несколько серверов Exchange, действительно понижаются (для обслуживания или иначе) и сохраняют Вашу базу данных почтового ящика онлайн.
"Изолированный DAG Копии" является все еще DAG, который копирует Вашу базу данных почтового ящика, но немного отличающимся способом. Можно установить период задержки на изолированном DAG, таким образом, копия является эффективно копией основной базы данных в какой-то момент в прошлом (значением по умолчанию 14 дней, IIRC). После того как файл журнала транзакций закончен (т.е. он достигает 1 МБ, и другой создается) на Вашей активной копии базы данных, он сразу копируется во все изолированные копии, но сразу не воспроизводится. Этот журнал транзакций останется на изолированной копии, пока период задержки не истечет, в которой точке это записано в изолированную базу данных копии.
С той информацией необходимо смочь дать управлению общее представление тем, что Exchange может сделать относительно высокой доступности/аварийного восстановления и возможно рекомендовать решение, но позволить им в конечном счете решить.
В зависимости от того, есть ли у вас ресурсы для разработки такой системы, это звучит как хороший кандидат для базы данных SQL Server, использующей хранилище FILESTREAM для файлов. Таким образом, вы оставляете организацию каталогов SQL Server, и все, о чем вам нужно беспокоиться, это как управлять самими данными. Вы, вероятно, могли бы использовать SQL Express, поскольку данные FILESTREAM не учитываются при вычислении размера базы данных.
Windows немного особенная, когда дело доходит до расположения папок с тысячами файлов. Особенно изображения, поскольку Windows Explorer обращается с ними по-особенному. Тем не менее, есть несколько рекомендаций, которым нужно следовать, чтобы не допустить выхода из-под контроля:
- Если вы собираетесь просматривать структуру каталогов из Windows Explorer по какой-либо причине, держите его меньше 10 000 записи в каталоге (файлы и подкаталоги).
- Если каждый файл создает N каталогов, количество объектов файловой системы , созданных этим файлом, будет 1 + N, что линейно масштабирует время копирования.
- Короткое экспоненциальное дерево ( т. е. три уровня каталогов, каждый с 256 подкаталогами) могут удивительно масштабироваться задолго до того, как вы столкнетесь с ограничением в 10 КБ на каталог.
- Если вы обращаетесь к нему с помощью кода, перейдите к прямому открытию вместо анализа каталога - объявления до открытия. Ошибка fopen (), за которой следует сканирование каталогов, во многих случаях выполняется быстрее, чем сканирование каталога с последующим гарантированным fopen ().
Предостережения:
- Количество файлов неизменяемо, но количество каталогов зависит от вас . Сумма этих двух подсчетов влияет на скорость выполнения операций копирования.
- Постарайтесь, если это вообще возможно, не работать в проводнике Windows без необходимости. Это плохо работает с большими каталогами, и с этим ничего не поделаешь.
В моем ответе из есть много полезной информации по математике. Как сложность каталогов влияет на i-узлы?
С учетом сказанного, разные файловые системы обрабатывают большое количество файлов в справочники разными способами. Некоторые устраивают 10 000 записей, другие прыгают. Как быстро изобретенное эмпирическое правило, 1000, вероятно, является хорошей целевой границей, если у вас есть контроль над дизайном. Записи в каталоге обычно хранятся как своего рода список, и приложение для чтения должно отсортировать их порядок. Например, ls в мире Unix считывает данные в память из каталога, а затем распечатывает их в алфавитном порядке.
Взгляните на математику из другого вопроса. Также подумайте, что sysadmin1338 сказал об ином поведении Explorer. Explorer создаст эскизы всего, что распознает как изображение, а затем прочитает эскизы, чтобы отобразить их. Это слишком много операций ввода-вывода для просмотра каталога, набитого файлами.