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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

Используйте Seaweed-FS (обычно называемый Weed-FS), реализация бумаги для сена в Facebook.

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

Ответ 4

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 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.

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

Вот пример сохранения изображения blob в 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);

...

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