Масштабируемое хранилище изображений

Question

В настоящее время я разрабатываю архитектуру для веб-приложения, которая также должна обеспечивать хранение изображений. Пользователи смогут загружать фотографии как одну из ключевых функций сервиса. Также просмотр этих изображений будет одним из основных видов использования (через Интернет).

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

1. Используйте (распределенную) файловую систему, такую ​​как HDFS, и подготовьте выделенные веб-серверы в качестве «клиентов файловой системы» для сохранения загруженных изображений и запросов на обслуживание. Метаданные изображения сохраняются в дополнительной базе данных, включая информацию о пути к файлу для каждого изображения.

2. Используйте систему, ориентированную на BigTable, например HBase, поверх HDFS и сохраняйте вместе изображения и метаданные. Опять же, веб-серверы блокируют загрузку изображений и запросы.

3. Используйте полностью безсхемную базу данных, такую ​​как CouchDB, для хранения изображений и метаданных. Кроме того, используйте саму базу данных для загрузки и доставки с помощью API-интерфейса RESTful на основе HTTP. (Дополнительный вопрос: CouchDB сохраняет BLOB-объекты через Base64. Может ли он возвращать данные в виде изображений / JPEG и т. Д.)?

Answer 1

Для этого мы использовали CouchDB, сохраняя изображения как «вложение». Но через год файлы базы данных CouchDB размером в несколько десятков ГБ оказались головной болью. Например, репликация CouchDB по-прежнему имеет проблемы, если вы используете ее с документами очень больших размеров.

Итак, мы просто переписали наше программное обеспечение, чтобы использовать CouchDB для информации об изображениях и Amazon S3 для фактического хранения изображений. Код доступен на http://github.com/hudora/huImages

Возможно, вы захотите настроить сервис хранилища, совместимый с Amazon S3, для вашего проекта. Это обеспечивает гибкость и оставляет возможность выбора amazon без необходимости внешних служб. Walruss кажется самым популярным и масштабируемым клоном S3.

Я также призываю вас взглянуть на дизайн Livejournal с их превосходными предложениями Open 101 * * MogileFS и Perlbal . Эта комбинация является, пожалуй, самой известной настройкой обслуживания изображений.

Кроме того, Архитектура flickr может быть источником вдохновения, хотя они не предлагают программное обеспечение с открытым исходным кодом для широкой публики, как Livejournal.

Answer 2

"Дополнительный вопрос: CouchDB сохраняет капли через Base64."

CouchDB не сохраняет BLOB-объекты как Base64, они хранятся в виде двоичного кода. При извлечении документа JSON с помощью ?attachments=true мы конвертируем двоичный файл на диске в Base64, чтобы безопасно добавить его в JSON, но это только на уровне представления.

См. Автономные вложения .

CouchDB обслуживает вложения с типом контента, с которым они хранятся, фактически это возможно для сервера вложения HTML, CSS и GIF / PNG / JPEG непосредственно в браузеры.

Вложения могут быть потоковыми, и в CouchDB 1.1 даже поддерживают заголовок Range (для потоковой передачи мультимедиа и / или возобновления прерванной загрузки).

Answer 3

Использование Seaweed-FS (раньше называлось Weed-FS), реализация стога сена Facebook.

Seaweed-FS очень гибок и урезан до основ. Он был создан для хранения миллиардов изображений и быстрого их обслуживания.

Answer 4

Мы используем MogileFS. Мы небольшие пользователи с объемом менее 8 ТБ и около 50 миллионов файлов. Несколько лет назад мы перешли от хранения в Amazon S3, чтобы лучше контролировать имена файлов и производительность.

Это не самое красивое программное обеспечение, но оно очень "протестировано в полевых условиях", и в основном все пользователи используют его так же, как вы будете.

Answer 5

Может быть, посмотрите описание Facebook hayStack

Игла в стоге сена: эффективное хранение миллиардов фотографий

Answer 6

Рассматривали ли вы Amazon Web Services? S3 - это сетевое хранилище файлов, а SimpleDB - хранилище ключей-> атрибутов. Оба являются производительными и легко масштабируемыми. Это дороже, чем поддерживать свои собственные серверы и настройки (при условии, что вы собираетесь делать это самостоятельно, а не нанимать людей), но вы гораздо быстрее приступаете к работе.

Редактировать: Я беру это обратно - в долгосрочной перспективе при больших объемах это дороже, но при низких объемах оно выше первоначальной стоимости покупки аппаратного обеспечения.

S3: http://aws.amazon.com/s3/ (вы можете хранить свои файлы изображений здесь, и для производительности может иметь кэш изображений на вашем сервере, а может и нет)

SimpleDB: http://aws.amazon.com/simpledb/ (метаданные могут быть здесь: отображение идентификатора изображения для любых данных, которые вы хотите сохранить)

Редактировать 2: Я даже не знал об этом, но есть новый веб-сервис под названием Amazon CloudFront (http://aws.amazon.com/cloudfront/).. Он предназначен для быстрой доставки веб-контента и хорошо интегрируется с S3. Akamai для ваших изображений. Вы можете использовать это вместо кэша изображений.

Answer 7

Как часть Cloudant, я не хочу продвигать продукт… но BigCouch решает эту проблему в моем стеке научных приложений (физика - ничего общего с Cloudant и, конечно, никакого отношения к прибыли!) Он сочетает в себе простоту дизайна CocuhDB с автоматическим разделением и масштабируемостью, которые отсутствуют в CouchDB с одним сервером. Обычно я использую его для хранения меньшего количества больших файлов (несколько ГБ) и большого количества маленьких файлов (100 МБ или меньше). Я использовал S3, но затраты на получение фактически начинают складываться для небольших файлов, к которым неоднократно обращаются.

Answer 8

Я написал магазин изображений на вершине кассандры. У нас много и записей, и случайных чтений чтения / записи мало. Для высокого отношения чтения / записи я предлагаю вам mongodb (GridFs).

Answer 9

Я экспериментировал с некоторыми функциями _update, доступными для серверов представлений CouchDB на моем сервере представлений Python.

Одна действительно крутая вещь, которую я сделал, была функция обновления для загрузки изображений, так что я мог использовать PIL для создания миниатюр и других связанных изображений и прикреплять их к документу, когда они помещаются в CouchDB.

Это может быть полезно, если вам требуется манипулирование изображениями и вы хотите сократить объем кода и инфраструктуры, которые необходимо поддерживать.

Answer 10

Хорошо, если все эти вещи в AWS не сработают, вот пара мыслей.

Что касается (3), если вы поместите двоичные данные в базу данных, эти же данные будут получены. Что делает его в формате JPEG, это формат данных, а не то, что база данных думает, что это. Что заставляет клиента (веб-браузер) думать, что это JPEG, это когда вы устанавливаете заголовок Content-type на image/jpeg. Вы также можете установить для него что-то другое (не рекомендуется), например текст, и именно так браузер попытается его интерпретировать.

Что касается хранения на диске, мне нравится CouchDB за его простоту, но HDFS наверняка будет работать. Вот ссылка на пост о подаче графического контента из CouchDB: http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html

Редактировать: вот ссылка на полезную дискуссию о кэшировании изображений в memcached против их обслуживания с диска в linux / apache.