Обслуживать большое количество маленьких изображений в ext4

Я прочитал какой-то похожий вопрос, но все еще немного запутался в моей ситуации.

Мой сайт позволяет пользователям загружать огромное количество больших изображений (сканировать страницы книги). Мой сервер будет автоматически размещать и сохранять эти изображения. Таким образом, каждая страница станет 10 тысяч маленьких листов (каждое изображение размером 128px*128px, занимает 2k места). У меня есть около 100 ГБ изображений, и сейчас они уже заполняют всю таблицу инодов.

Вот несколько моих мыслей и понимания, пожалуйста, поправьте меня, если я ошибаюсь.

  1. MySQL Blob

    верх: больше не нужно беспокоиться о структуре каталогов inode /.

    недостаток: медленное обслуживание изображений и может замедлить всю базу данных

  2. файловая система

    верх: более быстрая передача изображений

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

  3. mongoDB BinData с base64 (я не знаком с этим, но, похоже, это хороший вариант)

  4. Amazon S3

    верх: они обо всем позаботятся

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

    (ОБНОВЛЕНИЕ: я могу не разрешить использовать стороннего поставщика, но я все еще буду жить здесь, так как это может быть хорошим решением для других людей, согласно предложению @Niels.)

  5. Другая магия Отличное решение.

Поэтому мне интересно, что лучше в моей ситуации и почему. Спасибо за помощь

Источник

2 ответа

Насколько я знаю, в существующей файловой системе нет способа настроить число inode.

Если вы можете восстановить файловую систему, вы можете использовать -N возможность указать большее число inode для новой FS

Источник

Я бы определенно пошел на S3, если у вас нет тысяч очень активных пользователей... И даже если вы делаете пожертвования или реклама должна покрывать расходы. Хранение S3 действительно очень дешево по сравнению с вашим собственным сервером. Хранение 100 ГБ данных обойдется вам примерно в 9 долларов США в месяц при высоком уровне избыточности. Это означает зеркалирование как минимум в 4 хранилищах с гарантированной транзакционной долговечностью 99,9999%, что обойдется вам без реальной покупки одного сервера в течение 3 лет. Трафик может быть дорогостоящим, но вы платите это с каждым провайдером колокейшн, поэтому никакой разницы нет, если вы не доберетесь до больших номеров.

S3 - это высоко оптимизированный строковый словарь, способный хранить миллионы, если не миллиарды связанных файлов.

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

Кроме того, если использование полосы пропускания действительно астрономическое, рассмотрите возможность использования вашего веб-сервера в качестве "пограничного" сервера. В большинстве сценариев массового хранения 1% контента запрашивается в 99% случаев (например, фотографии на Facebook). Некоторые сценарии, которые локально отражают 1 ГБ недавно запрошенных изображений и очищаются к моменту последнего доступа, должны быть простыми в исполнении и, вероятно, сохраняют затраты на пропускную способность S3 в пределах бесплатного уровня.

Источник
Другие вопросы по тегам