Хранение изображений в MongoDB — стоит ли?

Question

[Nesvet]

Добрый день.


Нужно авторитетное мнение по данному вопросу. Была задача разобраться с GridFS, записывать и читать оттуда файлы. Всё получилось, но встал вопрос: есть ли какой-то смысл хранить там, например, изображения (фотографии)? Получается ли такое решение более производительным (или наоборот)? Если да, то как (по логике) оптимальнее это реализовать?


Как это происходит сейчас:

На GET-запрос /specialists/:login/photos/:photo (где :login — логин специалиста, :photo — уникальный идентификатор фотографии) происходит запрос в GridFS, откуда по идетификатору достаётся фотография специалиста и отдаётся браузеру.

Соответственно, на странице фотография прописывается, как

<img src="/specialists/:login/photos/:photo" alt="" />

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

Answer 1

[Анатолий]

Совершенно не стоит. Зачем вам вообще лишние запросы к базе? Тем более такие обьемные? Люди наоборот все кешируют и на винт складывают, чтоб доступ быстрей был, а вы наоборот думаете как бы кеш (изображения) убрать из под руки и засунуть в базу.

Comments

[Nesvet]

Так можно и закешировать nginx'ом — это не проблема. Что скажете?

[Анатолий]

Я скажу вот что: зачем кешировать, то что уже по сути закешировано и прекрасно лежит на винте?

[VBart]

+1
Для файлов есть специализированные базы данных, которые называются файловыми системами.

[return]

чтобы не решардить, к примеру, когда закончится место на диске

[Анатолий]

А база находится не на жестком диске? Или на дисках где лежит база место не заканчивается? По моему место является меньшей проблемой чем время запроса и выгрузки данных из базы.

Answer 2

[Stdit]

Производительным не получится, если нет большого кластера, который компенсирует сниженную скорость доступа за счёт распараллеливания. Я предпочитаю хранить картинки на отдельном сервере, а в базе ссылки на них. Вот небольшое исследование этого вопроса, правда двухлетней давности: www.coffeepowered.net/2010/02/17/serving-files-out-of-gridfs/

Answer 3

[MadJeck]

Смотрите в сторону gridFS (часть mongo) и модуля nginx ( github.com/mdirolf/nginx-gridfs ) если память не изменяет то теряете 50% в производительности, но получаете все плюшки облачного хранения файлов.

Comments

[VBart]

Теряете более 1000% производительности, превращая nginx в один процесс апача.

[MadJeck]

VBart, не говорите чушь, я кажется ссылку дал. Nginx будет использовать модуль и никакой apache вообще там не уперся.

[VBart]

Простите, какую чушь? По ссылке модуль в стадии «prove of concept» не предназначенный для использования. Он блокирует nginx полностью на время от установки соединения с базой и авторизации до получения файла целиком. Все это время nginx не может даже принимать соединения. При использовании этого модуля производительность одного воркера упадет в 100-10000 раз. Фактический один воркер nginx превращается в один воркер апача в режиме prefork.

[MadJeck]

Чушь это писать про апач про который речи и близко не было. То что он блокирует да факт, но сейчас это самое быстрое и простое решение для gridFS. На счет целесобразности использования в данном случае можно спорить. Но если число файлов больше нескольких миллионов я бы предпочел работать с облаком вместо ФС.

[VBart]

Извините, но вы вообще читать умеете? Повторю ещё раз: nginx с этим модулем работает как один процесс апача и даже хуже, иными словами, превращается из мультиплексора в однопоточный последовательный обработчик. Только похоже вам эти слова вообще ни о чем не говорят, раз вы даже не уловили сути сравнения с процессом апача.

Чтобы получить хоть какую-то производительность вам необходимо запустить около 100 воркеров nginx-а и поставить его бэкендом. Это самое медленное решение для GridFS, которое только можно придумать, причем с кучей подводных камней. И самое бессмысленное использование nginx-а.

[MadJeck]

Я вас понял, просто вместо того что бы назвать такое поведение синхронной работой вы сравниваете с апачем. Это как сказать что тойота без полного привода превращается в опель. Причем здесь опель?

[exgen]

С относительно недавнего времени это не самое быстрое и простое решение)
Мы в скором времени планируем перенести своё хранилище фотографий в GridFS. Из-за отсутствия у Mongo асинхронного драйвера nginx-gridfs не отличается особой производительностью. В свете этого печального события наш технический директор написал и выложил в open source модуль для Apache: bitbucket.org/onyxmaster/mod_gridfs/
Вот пост с анонсом в его блоге: xm.x-infinity.com/2012/04/as-were-to-move-our-terabytes-of-files.html
А тут некоторые цифры: xm.x-infinity.com/2012/04/modgridfs-performance.html

Answer 4

[Ivan Shalganov]

Если стоит вопрос хранения файлов в GridFS, значит есть потребность в облачном хранении и своевременном изменении файла/файлов в облаке, а так же контролируемая файловое хранилище (например вести счетчик использования файла в самом документе в gridfs и удалять при его обнулении). Только в этом случае имеет смысл задуматься о gridfs. Конечно, если использовать в лоб GridFS то потери производительности будут, и чем больше запросов и больше файлов тем больше просадка по производительности. Есть несколько вариантов более-менее производительные решения, но их вся суть сводиться: GridFS — (gridfs-fuse) --> disk0 — (rsync) --> disk1 — (rsync) --> disk2 — … (возможны параллельнык rsync) или GridFS — (gridfs-fuse) --> disk0 — (drbd) --> disk1, disk2,… или их комбинации.

Comments

[Ivan Shalganov]

это всего теория, на практике так и не было возможности проверить

[StamPit]

Я ж тебе говорил — забудь про FUSE. При 500+ RPS на картинки из GridFS будет ооочень печально, плюс inotify, мониторящий пару миллиардов файлов — далеко не самый быстрый вариант, несмотря на ядерное исполнение.

[StamPit]

Ну и плюс вспомни ntfs3g через FUSE. Даже десктопную нагрузку не держит. Проблема именно в FUSE.