LINUX.ORG.RU

хранение файлов в бд или на файловой шаре


0

4

В общем есть потребность хранить кучу файлов общим размером под 2 терабайта, файлов много, будет еще больше.

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

★★★

Ответ на: комментарий от anonymous

ясно, что не в астрале, чтобы избежать вот этого:

необходимости городить систему каталогов в файловой системе и от необходимости следить за синхронностью между файловым хранилищем и базой данных?

это ложится на плечи бд

IvanR ★★★ ()

Меньше грибов кушай, а то упорин он такой, в твоем случае рекомендую делать бекап бд средствами фс, как раз будет в твоем стиле.

anonymous ()

Если какую нибудь специализированную субд не использовать, то доступ к данным будет медленнее.

p.s. Если будешь делать так - то 2 таблицы: с собственно файлами и вторая с названиями файлов (ну и другими полями по которым нужна сортировка).

pi11 ★★★★★ ()
Последнее исправление: pi11 (всего исправлений: 1)

А нагрузка на БД? Как будешь разруливать ситуацию, с активной закачкой файлов на небольших скоростях. Даже метровый файлик, первоначально тянуть из БД в прослойку не будешь. Забирать из БД порциями? Так СУБД от сотен активных запросов тебе ещё такое спасибо скажет. В итоге закинуть файлы в одну папку будет уже куда интересней смотреться. А если эта папка ещё и на другом сервере и доступ к ней по http/etc то это ещё интересней даже

З.Ы. Заметь, что плодить набор директорий на современных ОС уже давно бессмысленно.

AlexVR ★★★★★ ()
Ответ на: комментарий от aeX1pu2b

Как вариант - файлы БД можно то же хранить в БД...

Мха ха ) . Неговори.

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

anonymous ()
Ответ на: комментарий от anonymous

да я в предыдущем своем вопросе все примерно описал, фотографии, видео, аудио и наверно документы, просто меня напрягает возможная ситуация, когда запись в бд есть, а файла по каким-то причинам не оказалось или наоборот файл лежит в файловой системе, а записи нет, пользователи, весьма вероятно, будут активно скачивать и аплолдить файлы, однако пользователей не много, 10 - 15 человек. Файлов 1 - 2 терабайт, количество не известно, но можно приблизительно посчитать.

IvanR ★★★ ()

почему не рекомендуется хранить их в базе данных

В какой базе данных? _Разные_ СУБДы много лет задачивались под _разные_ задачи. Вероятно, среди них не удастся найти ни одной, заточенной под обработку блобов лучше, чем адекватная файловая система. Так зачем баян?

необходимости следить за синхронностью между файловым хранилищем и базой данных

А кто-нибудь умрёт, если клиент получит инфу «этот файл когда-то был но уже удалён»?

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

А кто-нибудь умрёт, если клиент получит инфу «этот файл когда-то был но уже удалён»?

просто я перфикционист и мне будет не приятно об этом узнать

IvanR ★★★ ()

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

vtVitus ★★★★★ ()
Ответ на: комментарий от DonkeyHot

А кто-нибудь умрёт, если клиент получит инфу «этот файл когда-то был но уже удалён»?

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

arturpub ★★ ()

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

brain-dead ()

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

MikeDM ★★★★★ ()

Есть вполне успешные проекты, которые хранят терабайты котиков в gridfs на монге.

Тут все очень сильно зависит от задач. У себя вот как раз планирую gridfs использовать. Потому что небольшое потенциальное замедление не критично, а профит от простоты управления - весьма заметный.

Vit ★★★★★ ()
Ответ на: комментарий от DonkeyHot

GridFS в монге якобы заточили. Мопед не мой. Но с рулевым одной из команд, которая подобное использует, пообщаться довелось.

Если ориентироваться на максимизацию отдачи, то наверное с ФС можно выжать больше. Но уже не на порядок. А на практике часто приходится париться не над отдачей, а над хорошей управляемостью, вроде реплицирования, шардинга и т.п.

Впрочем, если выжимать совсем по максимуму, то ФС общего пользования все равно сольют специализированным решениям вроде pohmelfs (eblob) http://www.ioremap.net/

Vit ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.