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

Question

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

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

Answer 1

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

Для хранения в БД:

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

(Gravatars?)

Answer 5

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

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