Хранение изображений в магазинах NoSQL

Наше приложение будет обслуживать большое количество небольших изображений размером с миниатюры (размером около 6-12 КБ) через HTTP. Меня попросили исследовать, является ли использование хранилища данных NoSQL жизнеспособным решением для хранения данных. В идеале мы хотели бы, чтобы наше хранилище данных было неисправно и распределено.

Хорошо ли хранить капли в магазинах NoSQL, и какой из них хорош для этого? Кроме того, NoSQL - хорошее решение для нашей проблемы, или нам будет лучше обслуживать хранение изображений в файловой системе и обслуживание их непосредственно с веб-сервера (как в стороне, CDN в настоящее время не является для нас вариантом)?

Ответы

Ответ 1

Mongo DB должен хорошо работать для вас. Я еще не использовал его для капли, но вот приятное FLOSS Weekly интервью подкаста с Michael Dirolf от команды Mongo DB, где он обращается к этому использование случай.

Ответ 2

Можно ли хранить изображения в БД или файловой системе, это когда-нибудь один из таких дебатов "святой войны"; каждая сторона чувствует, что их способ делать вещи - это один правильный путь. В общем:

Чтобы сохранить в БД:

  • Легче управлять резервным копированием/копированием всего за один раз в одном месте.
  • Помогает с согласованностью и целостностью данных. Вы можете установить для поля BLOB значение NULL, но вы не сможете предотвратить удаление внешнего файла. (Хотя это не применимо к NoSQL, поскольку нет традиционных ограничений).

Для хранения в файловой системе:

  • Файловая система предназначена для работы с файлами. Пусть это сделает работу.
  • БД часто является узким местом в приложении. Какую бы нагрузку вы не выбрали, тем лучше.
  • Легче обслуживать CDN (который, как вы упомянули, не применим в вашей ситуации).

Я склоняюсь к стороне файловой системы, потому что она масштабируется намного лучше. Но в зависимости от размера вашего проекта, выбор, вероятно, будет работать нормально. С NoSQL различия еще менее очевидны.

Ответ 3

Хорошо, что CDN станет очевидным выбором. С тех пор я бы сказал, что ваш лучший выбор для отказоустойчивости и балансировки нагрузки будет вашим собственным центром обработки данных (что бы это ни значило для вас) за 2 или более балансировками нагрузки, такими как F5. Это будет ваша самая легкая система управления, и вы сможете получить столько отказоустойчивости, сколько позволяет ваш аппаратный бюджет. Вам не понадобятся новые знания программного обеспечения, просто XCOPY.

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

(Gravatars?)

Ответ 4

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

При правильной конфигурации Riak может справиться с сбоем всего центра обработки данных.

О, и у него есть коммерческая поддержка.

Ответ 5

Если вы находитесь в среде Python, рассмотрите модуль y_serial: http://yserial.sourceforge.net/

Менее 10 минут вы сможете хранить и получать доступ к своим изображениям (фактически, любому произвольному объекту Python, включая веб-страницы) - в сжатой форме; NoSQL.