CMS против масштабируемости идентификатора хранилища файловой системы

Ваш вопрос очень похож на этот. Ваша нагрузка в первую очередь читает ваши изображения или пишет? Если вам нужна масштабируемость чтения, в сообщении описывается memcached, который, вероятно, является всем, что вам нужно. jackrabbit имеет множество дополнительных функций, но больше для иерархического хранения текста. Не уверен, что это улучшит производительность ваших изображений. Кроме того, если вы все же выберете jackrabbit, убедитесь, что ваша иерархия контента достаточно глубокая, чтобы jackrabbit оставался эффективным. У любого родителя, имеющего 10 000 или более детей, будет невысокая успеваемость.

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

c:\<customer_id>\<document_year>\<document_month>\<document_day>\actual_file.tif

Я бы также высказал предположение, что в зависимости от настроек вашего сервера, возможно, стоит предоставить каждому клиенту (в зависимости от объема данных или типа учетной записи) свой собственный диск / раздел.

Имейте в виду, что без какой-либо системы пользовательского контроля или разрешений эти пути к файлам можно было бы предсказуемо угадывать и просматривать (как если бы вы этого еще не знали ... Я знаю, мне очень жаль). Тот факт, что вы подняли маркер «шестизначный уникальный код», предполагает, что вам не нужен путь общего формата, но я бы посоветовал вам использовать общий формат (любого формата, который вы в конечном итоге выбрать) было бы лучше.

Еще в те дни, когда я работал с Windows, я сортировал свои собственные каталоги по первичному отношению файла, в настоящее время это будет считаться «тегом» (например, c:\documents and settings\university\year1\module21\assignment1.doc), это упростило поиск вещей позже. Похоже, что структура каталогов ваших клиентов принудительно применена вами - но найти то, что они сделали на прошлой неделе, будет легче, если им нужно будет пройти только дату, запомнив, куда они положили что-то на прошлой неделе, когда они дошли до папки с шестизначными уникальными номерами будут, ну, трудно. В лучшем случае.

Предложенную вами стратегию хранения необходимо будет рассмотреть, если вы собираетесь переместить свой контент на другие машины (SAN / NAS). Для этого вам нужно будет удалить все данные о клиентах из пути и просто создать хэш, который вы затем сохраните в базе данных, чтобы связать с файлом, к которому вы обращаетесь. Таким образом, у вас останется примерно такая структура папок:

NAS1/00/01/86/63/54/89/image01/image.tiff
NAS2/00/02/46/62/22/11/image02/image.tiff
...

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

И, как упоминал Дейв, убедитесь, что у вас не слишком много детей в одной папке. В районе 10.000 все становится довольно вялым.