Масштабируемое устройство хранения данных изображения
Я в настоящее время разрабатываю архитектуру для веб-приложения, которое должно также обеспечить некоторое устройство хранения данных изображения. Пользователи смогут загрузить фотографии как одну из основной характеристики сервиса. Также просмотр этих изображений будет одним из основных использований (через сеть).
Однако я не уверен, как понять такой масштабируемый компонент устройства хранения данных изображения в моем приложении. Я уже думал о различных решениях, но из-за пропавших без вести событий, я ожидаю слышать Ваши предложения. Кроме изображений, также метаданные должны besaved. Вот мои начальные мысли:
Используйте (распределенную) файловую систему как HDFS и подготовьте выделенные веб-серверы как "клиенты файловой системы" для сохранения загруженных изображений и запросов на обслуживание. Метаданные изображения сохраняются в дополнительной базе данных включая filepath информацию для каждого изображения.
Используйте BigTable-ориентированную систему как HBase сверху HDFS и сохраните образы и метаданные вместе. Снова, веб-серверы соединяют мостом загрузки изображения и запросы.
Используйте completly бессхемную базу данных как CouchDB для хранения обоих изображений и метаданных. Кроме того, используйте саму базу данных для загрузки и доставки при помощи основанного на HTTP УСПОКОИТЕЛЬНОГО API. (Дополнительный вопрос: CouchDB действительно сохраняет блобы через Base64. Это может однако возвратить данные в форме image/jpeg и т.д.)?
5 ответов
Для этого мы использовали CouchDB, сохраняя изображения в виде "Attachment". Но через год несколько десятков файлов базы данных CouchDB оказались головной болью. Например, репликация CouchDB все еще имеет проблемы, если вы используете ее с очень большими размерами документов.
Поэтому мы просто переписали наше программное обеспечение для использования CouchDB для информации об изображениях и Amazon S3 для фактического хранения изображений. Код доступен по адресу http://github.com/hudora/huImages
Возможно, вы захотите настроить Amazon S3 совместимый сервис хранения данных на месте для вашего проекта. Это сохранит вашу гибкость и оставит опцию amazon без необходимости использования внешних услуг на данный момент. Walruss, кажется, стал самым популярным и масштабируемым клоном S3.
Я также призываю вас заглянуть в Дизайн Живого Журнала с их отличными предложениями Open Source MogileFS и Perlbal. Эта комбинация , вероятно, является самой известной установкой для обслуживания изображений.
Также flickr Architecture может быть вдохновением, хотя они не предлагают открытое программное обеспечение для общественности, как это делает Livejournal
.Я экспериментировал с некоторыми из _update функциональностью, доступной серверам CouchDB view на моем сервере Python view.
Одна действительно крутая вещь, которую я сделал, была функция обновления для загрузки изображений, так что я мог использовать PIL для создания эскизов и других связанных изображений и прикрепить их к документу, когда они будут толкнуты на CouchDB.
Это может быть полезно, если вам нужны манипуляции с образами и вы хотите сократить количество кода и инфраструктуры, которую вам нужно поддерживать.
Рассматривали ли вы веб-службы Amazon? S3 - это файловое хранилище на базе веб-сервиса, а SimpleDB - это ключ -> хранилище атрибутов. Оба они производительные и высоко масштабируемые. Это дороже, чем обслуживание собственных серверов и установок (предполагая, что вы собираетесь делать это самостоятельно и не нанимать людей), но вы встаете и работаете гораздо быстрее.
Edit: Беру свои слова обратно - в долгосрочной перспективе он дороже на больших объемах, но для небольших объемов он бьет первоначальную стоимость покупки аппаратного обеспечения.
S3: http://aws.amazon.com/s3/ (файлы образов можно хранить здесь, а для производительности, возможно, иметь кэш образов на сервере, а может и нет)
SimpleDB: http://aws.amazon.com/simpledb/ (метаданные могут идти здесь: сопоставление идентификатора образа с любыми данными, которые вы хотите хранить)
Редактирование 2: Я даже не знал об этом, но появился новый веб-сервис под названием Amazon CloudFront (http://aws.amazon.com/cloudfront/). Он предназначен для быстрой доставки веб-контента, и хорошо интегрируется с S3. Что-то вроде Akamai для ваших изображений. Вы можете использовать это вместо кэша изображений.
.Хорошо, Если все эти AWS-файлы не сработают, вот пара мыслей.
Что касается (3), если вы поместите двоичные данные в базу данных, то те же самые данные выйдут наружу. Что делает это jpeg, так это формат данных, а не то, что думает база данных. Что заставляет клиента (веб-браузер) думать, что это jpeg, так это когда вы устанавливаете заголовок Content-type на image/jpeg. Вы также можете установить его на что-то другое (не рекомендуется) вроде текста, и именно так браузер будет пытаться его интерпретировать.
Для хранения на диске мне нравится CouchDB за его простоту, но HDFS, безусловно, будет работать. Вот ссылка на сообщение об обслуживании образов из CouchDB: http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html
Edit: вот ссылка на полезное обсуждение кэширования образов в memcached против их обслуживания с диска под linux/apache.
.Может быть, посмотрите на Описание Facebook HayStack
Игла в стоге сена: эффективное хранение миллиардов фотографий