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

Question

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

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

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

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

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

Answer 1

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

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

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

Я также настоятельно рекомендую вам присмотреться к дизайну Livejournal с их отличным открытым исходным кодом МогилеФЫ и Перлбал подношения. Эта комбинация это, вероятно, самая известная установка для подачи изображений.

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

Answer 2

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

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

Видишь Автономные Навесные устройства.

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

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

Answer 3

Использование Морские водоросли-FS (раньше назывался Weed-FS), реализация Facebook haystack paper.

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

Answer 4

Рассматривали ли вы 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 5

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

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

Answer 6

Может быть, взглянете на описание Facebook hayStack

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

Answer 7

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

Answer 8

Хорошо, если все эти штуки с 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.

Answer 9

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

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

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

Answer 10

Я написал image store поверх cassandra .У нас много операций записи и случайного чтения, уровень чтения / записи невелик.Для высокого соотношения чтения и записи я предлагаю Вам mongodb (GridFS).

Answer 11

Вот пример сохранения изображения большого двоичного объекта в CouchDB с использованием PHP Laravel.В этом примере я сохраняю три изображения в зависимости от требований пользователя.

Устанавливаем соединение в CouchDB.

$connection = DB::connection('your database name');

/*region Fetching the Uers Uploaded Images*/

$FirstImage = base64_encode(file_get_contents(Input::file('FirstImageInput')));
$SecondImage =base64_encode(file_get_contents(Input::file('SecondImageInput')));
$ThirdImage = base64_encode(file_get_contents(Input::file('ThirdImageInput')));

list($id, $rev) = $connection->putDocument(array(
    'name' => $name,
    'location' => $location,
    'phone' => $phone,
    'website' => $website,
    "_attachments" =>[
        'FirstImage.png' => [
            'content_type' => "image/png",
            'data' => $FirstImage
        ],
        'SecondImage.png' => [
            'content_type' => "image/png",
            'data' => $SecondImage
        ],
        'ThirdImage.png' => [
            'content_type' => "image/png",
            'data' => $ThirdImage
        ]
    ],
), $id, $rev);

...

так же, как вы можете хранить одно изображение.