Хранение файлов на будущее - PullRequest
0 голосов
/ 01 июня 2009

Я принимаю загрузки файлов от пользователей. Каждый файл имеет указатель в БД, который имеет информацию о расположении файла в файловой системе. В настоящее время я храню файлы в файловой системе не по категориям, и каждый файл в данный момент называется уникальным значением. Все категоризации, наименования и т. Д. Выполняются в приложении с использованием базы данных.

Фактор, который меня беспокоит, связан с проблемами синхронизации файлов. Если бы я хотел настроить синхронизацию файловой системы, где, например, файлы пользователя автоматически обновляются при подключении к ПК, будет ли эта система работать хорошо? Я понятия не имею, как будет работать такая система, так что, надеюсь, я смогу получить какой-то вклад.

По сути, оптимально ли представление имени и местоположения файла исключительно в базе данных, особенно если указанный файл может быть синхронизирован с приложением для ПК?

Ответы [ 5 ]

6 голосов
/ 01 июня 2009

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

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

Убедитесь, что у вас есть хорошие резервные копии базы данных, а также хранилище документов.

3 голосов
/ 01 июня 2009

Все, что вам нужно для работы такой системы, - это убедиться, что используемый вами API (или, что более вероятно, созданный) может разумно взаимодействовать с базой данных и файловой системой. Так как это то, что ваш сайт уже делает в любом случае, это не составит труда реализовать.

Тот факт, что вашим файлам присвоены идентификаторы вместо простых английских имен, в основном не имеет отношения к удаленной синхронизации.

2 голосов
/ 01 июня 2009

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

Таким образом, вы также можете заставить систему загружать файл из другого места, в зависимости от того, какую базу данных хэшей вы используете для поиска файла, так что это обеспечивает некоторую прозрачность, если вам нужны люди, чтобы иметь доступ к одному и тому же файлу из разных мест ( т.е. NFS или WebDAV).

1 голос
/ 02 июня 2009

Мы используем именно эту модель для хранения файлов вместе с (бесстыдным плагином) SabreDAV , чтобы конечному пользователю показалось, что это обычная файловая система.

Я думаю, что это прекрасная модель, поскольку поиск файла задокументирован и легко найден, проблем не должно быть. Просто сделайте резервные копии вашей БД:)

Еще один совет, который я могу дать, мы используем md5 () для идентификатора файла, чтобы сгенерировать уникальное имя файла. Мы используем части файлов для генерации структуры каталогов, например .. id 1 приведет к: b026324c6904b2a9cb4b88d6d61c81d1, результирующее имя файла станет:

b02 / 632 / 4c6 / 904b2a9cb4b88d6d61c81d1 Причина этого заключается в том, что большинство стабильных файловых систем могут работать очень медленно после большого количества файлов (или каталогов) в одном каталоге. Это намного, намного быстрее, пройти через несколько подкаталогов.

0 голосов
/ 01 июня 2009

Скучный ответ ™:

Я думаю, это зависит от того, что ты хочешь сделать, как всегда:)

Я имею в виду, возьмите вашу обычную хостинговую компанию. Разработчики постоянно синхронизируют файлы с веб-серверами. Имеет ли смысл для веб-сервера хранить сгенерированные хэшем имена файлов в БД, которые указывают на физические файлы? Нет. Тогда вы не могли войти в систему с помощью своего FTP-клиента и загружать подобные файлы, и вам нужно было бы написать собственный модуль для работы Apache и т. Д. Мгновенная головная боль.

Имеет ли смысл Flickr использовать БД? Да, конечно! (Опять же, вы не можете войти через FTP-клиент и управлять своими фотографиями - и это, вероятно, хорошо!)

Просто помните, что файловая система - это (очень простая) база данных. И это БД, которая поставляется с множеством полезных бесплатных инструментов.

my 2 101

/0
...