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

Файловая стратегия AWS при чтении больших файлов, которые не часто меняются

У нас есть веб-приложение (Rails), в которое администраторы могут загружать небольшое количество довольно больших (1-10 МБ) файлов бизнес-логики. Файлы содержимого будут меняться не часто, возможно, раз в неделю.

Когда пользователи взаимодействуют с приложением, другой экземпляр EC2 серверной части (Java) часто (несколько раз в минуту) должен обрабатывать содержимое одного и того же (одного) файла.

Я рассматриваю возможность использования корзины S3 для хранения файлов и использования AWS SDK для извлечения файлов.

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

Подходит ли здесь чистый S3? Должен ли я сам реализовать кэширование в Java, предотвращая запрос S3? Или здесь следует использовать другой подход AWS?

Вроде бы кеширование в памяти было бы уместно. Я просто прочитал это в структуру данных в памяти. В качестве альтернативы вы можете использовать сервер memcached / redis, если, например, у вас есть много ГБ данных, которые вы не хотите хранить в ОЗУ каждого сервера приложений. В памяти Java было бы быстрее.

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

Чтение из S3, вероятно, будет медленнее, чем чтение из тома EBS, я действительно не вижу в этом никакого преимущества.