Хранение изображений в магазинах NoSQL
Наше приложение будет обслуживать большое количество маленьких уменьшенных изображений (размером около 6-12 КБ) по протоколу HTTP. Меня попросили выяснить, является ли использование хранилища данных NoSQL жизнеспособным решением для хранения данных. В идеале мы хотели бы, чтобы наше хранилище данных было отказоустойчивым и распространяемым.
Стоит ли хранить большие двоичные объекты в магазинах NoSQL, и какой из них подходит для них? Кроме того, является ли NoSQL хорошим решением для нашей проблемы, или нам лучше хранить изображения в файловой системе и обслуживать их непосредственно с веб-сервера (кроме того, CDN в настоящее время не подходит для нас)?
5 ответов
Монго БД должна хорошо работать для вас. Я еще не использовал его для блобов, но вот хорошее еженедельное интервью подкаста FLOSS с Майклом Дирольфом из команды Mongo DB, где он рассматривает этот вариант использования.
Хранить ли изображения в БД или в файловой системе - одна из тех дискуссий типа "священной войны"; каждая сторона чувствует, что их способ делать вещи - единственный правильный путь. В общем:
Хранить в БД:
- Проще управлять резервным копированием / копировать все сразу в одном месте.
- Помогает согласованности и целостности ваших данных. Вы можете установить в поле BLOB запрет на NULL, но не сможете предотвратить удаление внешнего файла. (Хотя это не относится к NoSQL, так как нет традиционных ограничений).
Чтобы сохранить в файловой системе:
- Файловая система предназначена для обслуживания файлов. Пусть это сделает свою работу.
- БД часто является вашим узким местом в приложении. Какую бы нагрузку вы не сняли, тем лучше.
- Проще обслуживать на CDN (который вы упомянули, неприменимо в вашей ситуации).
Я склонен опускаться на сторону файловой системы, потому что она гораздо лучше масштабируется. Но, в зависимости от размера вашего проекта, любой из этих вариантов будет работать нормально. С NoSQL различия еще менее заметны.
Я искал подобное решение для личного проекта и наткнулся на Riak, который, на мой взгляд, кажется удивительным решением этой проблемы. По сути, он распространяет указанное количество копий каждого файла на серверы в сети. Он спроектирован таким образом, чтобы сервер приходил или уходил, не имеет большого значения. Все копии на сервере, который уходит, распределяются среди других.
При правильной конфигурации Riak может справиться со сбоем всего центра обработки данных.
О, и у него есть коммерческая поддержка.
Ну, CDN был бы очевидным выбором. Поскольку этого нет, я бы сказал, что лучшим выбором для отказоустойчивости и балансировки нагрузки будет ваш собственный частный центр обработки данных (что бы это ни значило для вас) за 2 или более балансировщиками нагрузки, такими как F5. Это будет ваша самая простая система управления, и вы сможете получить отказоустойчивость настолько, насколько позволяет ваш аппаратный бюджет. Вам не понадобятся новые знания в области программного обеспечения, только XCOPY.
Для истинной отказоустойчивости вам понадобится географическая разбросанность, или вам нужен человек с экскаватором.
(Gravatars?)
Если вы находитесь в среде Python, рассмотрите модуль y_serial: http://yserial.sourceforge.net/
Менее чем за 10 минут вы сможете хранить и получать доступ к своим изображениям (фактически, любому произвольному объекту Python, включая веб-страницы) - в сжатом виде; NoSQL.