Репликация файлов / изображений - PullRequest
5 голосов
/ 16 декабря 2008

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

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

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

Теперь единственная проблема, с которой я сталкиваюсь при хранении изображений в базе данных, - это дополнительные запросы к базе данных и дополнительная обработка, которую я должен был бы выполнить в apache, если бы я хотел, чтобы «виртуальные» ссылки на изображения указывали на записи базы данных. , (например, AddHandler)

Насколько я понимаю:

  • Если у вас есть сценарий, обслуживающий изображения: для каждого изображения потребуется вызов базы данных.
  • Если вы отображаете изображения как двоичные данные: что можно сделать в один вызов базы данных.
  • Для предоставления внешнего / связываемого изображения вы должны добавить addHandler для расширения, которое вы хотите «подделать» и указать на ваш язык сценариев (например, php, asp).

Возможно, я что-то упустил, но мне любопытно, есть ли у кого-нибудь идеи получше?


Edit: Том предложил использовать mod_rewrite для сохранения с помощью AddHandler, я принял в качестве предложенного решения проблемы AddHandler; однако я пока не чувствую, что у меня есть полное решение, поэтому, пожалуйста, продолжайте отвечать;)

Некоторые предложили использовать lighttpd поверх Apache. Насколько отличаются модули ISAPI для lighttpd?

Ответы [ 4 ]

3 голосов
/ 16 декабря 2008

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

В наших больших приложениях мы используем до 4 кластеров:

  • Кластер серверов приложений
  • Кластер веб-службы / службы данных
  • Статический ресурс (изображения, документы, мультимедиа) кластер
  • База данных кластера

Вы будете удивлены, сколько трафика может обработать статический сервер ресурсов. Поскольку на самом деле это не вычисления (без логики приложения), ответ можно оптимизировать как сумасшедший. Если вы работаете с отдельным кластером статических ресурсов, вы также оставляете себя открытым для изменения только той части вашей архитектуры. Например, в некоторых тестах lighttpd даже быстрее обслуживает статические ресурсы, чем apache. Если у вас есть отдельный кластер, вы можете изменить там свой http-сервер, не изменяя ничего в среде своего приложения.

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

2 голосов
/ 17 декабря 2008

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

Решение о том, где их хранить, является реальным решением, которое вам нужно принять. Вам нужно подумать о своих целях:

  • Резервирование оборудования
  • Много дешевого хранения
  • Read-масштабирование
  • Write-масштабирование

Последние два не совпадают и определенно вызовут проблемы.

Если вы уверены, что размер этой библиотеки изображений не будет превышать размер диска, который вы с удовольствием поместите на свои веб-серверы (скажем, 200 ГБ на момент написания, как самый большой высокоскоростной серверный диск, который можно получить; я предполагаю, что вы хотите использовать веб-серверы 1U, чтобы вы не могли хранить больше, чем в raid1, в зависимости от вашего поставщика), тогда вы можете получить очень хорошее масштабирование при чтении, разместив копию всех изображения на каждом веб-сервере.

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

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

«Разделение» данных изображения между многими серверами обеспечит хорошую масштабируемость чтения / записи, но это нетривиальное упражнение. Это также может позволить вам использовать дешевое (ish) хранилище.

Наличие одного центрального сервера (или активной / пассивной пары или чего-либо) с дорогостоящим оборудованием ввода-вывода обеспечит лучшую пропускную способность записи, чем везде использование «дешевого» оборудования ввода-вывода, но тогда вы будете ограничены масштабируемостью чтения.

1 голос
/ 16 декабря 2008

То, что вы ищете, уже существует и называется MogileFS Настройка цели включает mogilefsd, реплицированные базы данных mysql и lighttd / perlbal для обслуживания файлов; Это обеспечит вам отказоустойчивость, точную репликацию файлов (например, вы можете решить дублировать изображения конечного пользователя на нескольких физических устройствах и сохранить только один физический экземпляр миниатюр). Балансировка нагрузки также может быть достигнута довольно легко.

1 голос
/ 16 декабря 2008

Наличие ваших изображений в базе данных не обязательно означает вызов базы данных для каждого; вы можете кэшировать их отдельно на каждом хосте (например, во временных файлах) при их получении. Исходные изображения по-прежнему будут в базе данных, и их будет легко синхронизировать между серверами.

Вам также не нужно добавлять обработчики Apache для обслуживания изображения с помощью PHP-скрипта, сохраняя при этом красивые URL-адреса - вы можете создавать URL-адреса типа http://server/image.php/param1/param2/param3.JPG и читать параметры через $_SERVER['PATH_INFO']. Вы также можете удалить часть «image.php» в URL (если вам нужно), используя mod_rewrite.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...