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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Хорошо, если все, что 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 4

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

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

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

Answer 5

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

Needle in a haystack: efficient storage of billions of photos

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

См Standalone Attachments.

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

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

Answer 10

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

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

Answer 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); 

... 

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