Если вы используете S3 для хранения данных из пользовательских загрузок, особенно в распределенной среде, одним из важных соображений является тот факт, что S3 «в конечном итоге согласован» (хотя некоторые регионы согласованы для чтения после записи). Следствием этого является то, что вы можете успешно загрузить файл, но если вы проверите его существование сразу после этого, может оказаться, что он не существует. Эта проблема более заметна для таких сценариев, как обновления или удаления, где даже согласованность чтения после записи не поможет.
Вышеуказанное будет применяться к вашим загрузкам на S3 независимо от выбранного вами подхода. Фактически, это справедливо для большинства проблем, которые можно ожидать от S3 - это не столько подход, который используется для хранения данных, сколько ограничения S3, которые, вероятно, будут наиболее проблематичными.
S3fs использует API S3 - как и PHP (или другой) SDK. Более того, S3 разработан для обработки достаточно высоких уровней параллелизма - поэтому (кроме проблем с согласованностью) не должно быть проблем с монтированием его на нескольких экземплярах (учитывая, что это не традиционная файловая система - такие проблемы, как блокировка, и т. д. обрабатываются на стороне S3).
Тем не менее, есть некоторые потенциальные преимущества и недостатки каждой реализации:
S3fs:
- Отсутствует поддержка частичных / частичных загрузок (насколько я знаю) - поэтому вы должны загрузить полный файл, чтобы прочитать любую его часть - вероятно, не проблема, если вы просто используете его для хранения (и обслуживания) загрузок.
- Написано на C ++ возможное повышение производительности
- Ваше приложение получает выгоду от любых обновлений s3fs
- Реализует кэширование (как полных файлов, так и файловой информации) - может немного улучшить скорость и снизить затраты
- Ограничено функциями, которые выставляет предохранитель
SDK:
- Предоставляет полный набор функций, которые S3 может предложить - в зависимости от вашего варианта использования этого может быть достаточно для использования SDK
- Потенциально более тесная интеграция с вашим приложением - возвращенные ошибки и т. Д. Могут позволить вашему приложению сделать более обоснованный (и, следовательно, более точный) выбор
- Любые возможные преимущества должны быть закодированы - ваше приложение должно использовать их и быть в курсе будущих изменений в S3
- Больше сложности и накладных расходов на ваш код
С точки зрения «безопасности» вы можете иметь в виду «предотвращение повреждения данных» или «предотвращение несанкционированного доступа». Что касается первого, SDK может немного помочь для решения возможных проблем (в форме более подробных ошибок), но базовое хранилище остается тем же, и я ожидаю, что различия будут незначительными. Что касается контроля доступа - вы можете использовать IAM для создания ограниченной учетной записи, но для этой учетной записи все еще потребуется доступ на чтение / запись к вашим файлам S3. Оба должны быть в достаточной степени безопасными, в любом случае ваша система должна быть скомпрометирована для получения доступа к вашей корзине S3 - однако я бы предположил, что с S3fs (поскольку учетные данные обычно хранятся вне webroot и вообще не доступны через PHP) там немного лучше безопасность.
Личное мнение: я бы предпочел s3fs для случая, когда существует один каталог для загрузки (например, один сайт, использующий его) и где доступ будет довольно простым (просто нужно загружать файлы и иногда обновлять / удалять). Если вам потребуется более сложный доступ (например, частичная загрузка, несколько сегментов и т. Д.) Или вы собираетесь использовать S3 SDK для других целей, то я бы также использовал SDK для загрузки.