Se si utilizza S3 per l'archiviazione dei dati dai caricamenti degli utenti, in particolare in un ambiente distribuito, una grande considerazione è il fatto che S3 è "eventualmente coerente" (sebbene, alcune regioni siano coerenti lettura-scrittura-scrittura). La conseguenza di ciò è che è possibile caricare correttamente un file, ma se si verifica la sua esistenza immediatamente dopo, è possibile che non esista. Questo problema è più pronunciato per scenari come aggiornamenti o eliminazioni, in cui anche la coerenza read-after-write non aiuta.
Quanto sopra verrà applicato ai tuoi caricamenti su S3 indipendentemente dall'approccio adottato. In realtà, questo è vero per la maggior parte dei problemi che ci si potrebbe aspettare da S3 - non è tanto l'approccio utilizzato per archiviare i dati in quanto sono i limiti di S3 che saranno probabilmente i più problematici.
S3fs utilizza l'API S3, proprio come fa l'SDK di PHP (o altro). Inoltre, S3 è progettato per gestire livelli di concorrenza abbastanza elevati, quindi (oltre ai problemi di coerenza) non dovrebbe esserci un problema a montarlo su più istanze (tenendo presente che non è un file system tradizionale - problemi come il blocco, ecc. sono gestiti dal lato S3).
Detto questo, ci sono alcuni potenziali vantaggi e svantaggi di ogni implementazione:
S3fs:
- Nessun supporto per download parziali / in blocco (per quanto ne so) - quindi è necessario scaricare il file completo per leggere qualsiasi parte di esso - probabilmente non è un problema se lo si sta semplicemente utilizzando per archiviare (e servire) i caricamenti.
- Scritto in C ++ possibili miglioramenti delle prestazioni
- L'applicazione beneficia di eventuali aggiornamenti a s3fs
- Implementa la memorizzazione nella cache (sia dei file completi che delle informazioni sui file): ha il potenziale per migliorare un po 'la velocità e ridurre i costi
- Limitato alle funzioni che il fusibile espone
SDK:
- Espone il set completo di funzionalità che S3 ha da offrire - a seconda del caso d'uso, questo potrebbe essere sufficiente per meritare l'uso dell'SDK
- Integrazione potenzialmente più stretta con l'applicazione: gli errori restituiti, ecc. Possono consentire all'applicazione di effettuare scelte più informate (e quindi più precise)
- È necessario codificare tutti i possibili vantaggi: l'applicazione deve trarne vantaggio ed essere aggiornata con le future modifiche a S3
- Più complessità e sovraccarico per il tuo codice
In termini di "sicurezza", si potrebbe intendere "prevenire la corruzione dei dati" o "impedire l'accesso non autorizzato". Per quanto riguarda il primo, l'SDK potrebbe aiutare un po 'a gestire l'eventuale coerenza (sotto forma di errori più dettagliati), ma l'archiviazione sottostante è la stessa e mi aspetto che le differenze siano minori. Per quanto riguarda il controllo degli accessi - puoi usare IAM per creare un account limitato, ma quell'account avrà ancora bisogno dell'accesso in lettura / scrittura ai tuoi file S3. Entrambi dovrebbero essere adeguatamente sicuri, in entrambi i casi, il tuo sistema deve essere compromesso per ottenere l'accesso al tuo bucket S3 - suggerirei tuttavia che con S3fs (poiché le credenziali sono in genere archiviate all'esterno del webroot e non sono accessibili affatto tramite PHP) c'è una sicurezza leggermente migliore.
Opinione personale: preferirei s3fs per un caso in cui esiste una singola directory di upload (ad esempio un sito che ne fa uso) e in cui l'accesso sarà abbastanza semplice (è sufficiente caricare i file e occasionalmente aggiornare / eliminare). Se hai bisogno di un accesso più complesso (ad es. Download parziali, più bucket, ecc.) O utilizzerai l'SDK S3 per altri scopi, allora rimarrei con l'SDK anche per i caricamenti.