Назад | Перейти на главную страницу

Что вы делаете, когда ваш сайт настолько масштабируется, что uploaded_media не может поместиться на одном компьютере?

Что вы делаете, когда ваш сайт масштабируется настолько, что ваш uploaded_media (в Django, где хранятся все загруженные от пользователей медиафайлы) не помещается на одном компьютере?

В моем личном случае я использую Django и имею один действительно большой сервер uploaded_media с более чем 600 ГБ памяти (но это место на исходе).

Возможные решения, которые я придумал:
1) Попробуйте построить машину для хранения большего размера.
2) Перейти к более абстрактной системе, где расположение и пути к uploaded_media хранятся в базе данных (каждому файлу дается идентификатор DB, и эта запись базы данных хранит, где файл хранится на нескольких серверах uploaded_media).

Переместите статический носитель в другую подсистему хранения. Это может быть либо большой NAS с экспортом NFS на ваш веб-сервер, либо, предпочтительно, использование хранилища объектов, такого как Amazon S3, для ваших статических носителей. С правильными заклинаниями вы можете заставить браузеры ваших пользователей загружать файлы прямо в S3. Однако, если этого нет в картах, вы можете хранить загруженные файлы локально в течение короткого времени, а затем иметь задание, которое периодически запускается и выгружает элементы в S3 (также обновляя вашу базу данных с указанием их правильного местоположения).

На ум приходят несколько вариантов:

  1. Добавьте дополнительное хранилище (то есть второй жесткий диск) (и, возможно, настройте его как JBOD, чтобы он выглядел смежным с сервером).
  2. Рассмотрим сетевую файловую систему, такую ​​как GlusterFS. Это позволит вам хранить данные на нескольких машинах, и все они будут прозрачно доступны для локального компьютера.
  3. Рассмотрите возможность использования внешнего хранилища данных, такого как Amazon S3. Вы можете смонтировать это как локальное хранилище (например, с помощью S3fuse), и оно будет масштабироваться в соответствии с вашими потребностями (кроме стоимости, в этом сценарии есть небольшое ограничение производительности - он определенно не подходит для чего-то вроде базы данных, но для медиафайлов должно быть вполне адекватно).
  4. Плохой вариант (по крайней мере, на мой взгляд) - использовать сжатую файловую систему (fusecompress, btrfs), чтобы получить немного дополнительного места - в зависимости от типа файлов это может привести к значительной экономии места (например, для документов) или почти ничего (для изображений / музыки / видео). Конечно, это может привести к значительному снижению производительности.

Возможно, удастся объединить некоторые из вышеперечисленных (например, использовать существующее хранилище и S3 поверх GlusterFS для получения бесшовного результата, но чем больше слоев вы добавите, тем хуже будет производительность. Опять же, для настройки, которая в основном хранит файлы, это не может быть важным фактором).