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

Question

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

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

Answer 1

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

Answer 2

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

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

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

Чтобы сохранить в файловой системе:

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

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

Answer 3

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

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

(Gravatars?)

Answer 4

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

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

Answer 5

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

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

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