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

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

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

посмотреть Автономные Вложения.

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

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

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

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

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

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

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

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

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

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

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

возможно, посмотрите на описание Facebook hayStack

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

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

хорошо, если все эти вещи AWS не будут работать, вот пара мыслей.

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

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

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

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

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

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

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

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

...

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