Object storage vs block storage: quale è migliore?

L'object storage vince per i file caricati dagli utenti, gli asset statici, i backup e gli archivi — essenzialmente qualsiasi cosa accedi tramite HTTP e raramente modifichi in-place. Il block storage vince quando hai bisogno di scritture casuali a bassa latenza: database, volumi di boot, file system ad alta transazione. Per i carichi di lavoro di trasferimento file specificamente, l'object storage è quasi sempre corretto perché scala orizzontalmente, costa 0,015-0,023 $/GB/mese rispetto a 0,08-0,125 $/GB/mese per il block, e gestisce bucket di scala petabyte senza repartitioning.

Come differiscono davvero sotto il cofano

Il block storage espone un dispositivo raw (un LUN o un volume EBS) che il sistema operativo formatta con ext4, XFS o NTFS. Le letture e le scritture avvengono in blocchi di dimensioni fisse, tipicamente 4 KB o 16 KB, su iSCSI, NVMe-oF o SCSI. Il sistema operativo possiede il file system; il dispositivo a blocchi non sa nulla dei file, solo degli offset.

L'object storage espone un'API HTTP (S3, Azure Blob, GCS) dove ogni oggetto ha una chiave, byte e metadati. Non c'è un file system sotto — gli oggetti sono unità atomiche che si inseriscono con PUT e si recuperano con GET per intero. Le scritture generano nuove versioni; non puoi modificare il byte 1.000.000 di un oggetto da 2 GB senza riscrivere l'intero oggetto. Questa immutabilità è una funzionalità: consente la replica multi-regione, il versioning e le regole del ciclo di vita che il block storage non può facilmente eguagliare.

Confronto rapido

| Dimensione | Object Storage | Block Storage | |-----------|----------------|---------------| | API tipica | S3 HTTP REST | POSIX + iSCSI/NVMe | | Costo (AWS hot tier) | 0,023 $/GB/mese | 0,08 $/GB/mese (gp3) | | Unità massima singola | 5 TB per oggetto | 64 TiB per volume EBS | | Latenza | 10-100 ms | Sub-millisecondo | | Lettori concorrenti | Illimitati | Un host alla volta (di solito) | | Rivendicazione di durabilità | 11 nines (S3) | 5-6 nines (EBS) | | Adatto per | File, media, backup | Database, dischi di boot | | Non adatto per | Scritture casuali su file di grandi dimensioni | Scala orizzontale oltre un volume |

Throughput vs latenza: vincitori diversi

Un volume EBS gp3 serve letture da 4 KB in meno di 1 ms; un S3 GET per gli stessi 4 KB richiede 20-80 ms a seconda della regione. Per un write-ahead log di PostgreSQL che fa 5.000 transazioni al secondo, quel gap di latenza è devastante. Per un utente che scarica un archivio .zip da 500 MB, è irrilevante perché il ritardo al primo byte scompare dietro il throughput.

Sul throughput sequenziale, l'object storage spesso vince su scala. S3 può servire un singolo bucket a 5.500 richieste GET/secondo per prefisso, e con il rate partitioning (chiavi con hash prefissato) si va nelle decine di migliaia. Un singolo volume gp3 ha un tetto di 1.000 MB/s e 16.000 IOPS. Per dieci utenti concorrenti che scaricano un file da 10 GB, l'object storage satura la loro banda; il block storage diventa un collo di bottiglia.

Costo su scala

Per 100 TB di media abbastanza freddi:

S3 Standard: 2.300 $/mese
S3 Standard-IA: 1.250 $/mese
S3 Glacier Instant Retrieval: 400 $/mese
S3 Glacier Deep Archive: 99 $/mese
EBS gp3: 8.000 $/mese
EBS st1 (HDD ottimizzato per throughput): 4.500 $/mese

Il block storage non ha livelli. Paghi il prezzo di accesso peak per i dati che tocchi una volta all'anno. Le regole del ciclo di vita dell'object storage spostano gli oggetti automaticamente: hot per 30 giorni, Standard-IA per 60, Glacier dopo 90. Per un servizio di trasferimento file che archivia gli upload con scadenza di 7 giorni, l'object storage con una regola Expiration è drasticamente più economico dell'esecuzione di un server con backend EBS.

Consistenza e concorrenza

S3 ora fornisce strong read-after-write consistency per PUT e DELETE, globalmente. Azure Blob e GCS corrispondono. Questo ha rimosso una delle critiche storiche all'object storage — un tempo si vedevano sorprese di "eventual consistency" dove un file appena caricato restituiva 404 per alcuni secondi.

Ma i writer concorrenti contano ancora. Il block storage di solito assume un singolo writer; esistono modalità multi-attach ma aggiungono complessità. L'object storage consente a un milione di client di fare PUT simultaneamente, con semantica last-writer-wins (o versioning per tenerli tutti). Per un sistema di condivisione file in cui due utenti potrebbero caricare file diversi con la stessa chiave, il versioning sul bucket preserva entrambi.

Quando le app di trasferimento file necessitano comunque del block storage

Il caveat: l'applicazione che serve l'object storage spesso gira su host con backend a blocchi. Un'API di upload di file ha bisogno di un disco locale per lo spooling temporaneo (chunk multipart, scansione antivirus), storage dei metadati (di solito in PostgreSQL su EBS) e log. Gli oggetti stessi vanno su S3/R2/Blob; il macchinario che li gestisce vive su block.

Per gli upload in streaming ad alto throughput, le pipeline in-memory battono il disco. Le librerie come aws-sdk-js e boto3 supportano upload multipart in streaming che non toccano mai il disco locale. Un servizio di upload ben ottimizzato può inviare un file da 5 GB dal client all'object storage con meno di 500 MB di RAM e zero file temporanei.

Metadati: la differenza nascosta

L'object storage porta i metadati con ogni oggetto: metadati di sistema (dimensione, mtime, etag), metadati utente (coppie chiave-valore arbitrarie, header x-amz-meta-*) e tag. Puoi cercare per metadati tramite S3 Object Lambda, report di Inventory o abbinandoli a DynamoDB. Il block storage lascia i metadati interamente al file system, il che significa che taggare 10 milioni di file richiede un database personalizzato.

Per un'app di trasferimento che deve rispondere a "trova tutti i file sopra 100 MB caricati la settimana scorsa da utenti in Francia" immediatamente, i metadati degli oggetti più un inventario Parquet ti permettono di interrogare con Athena in secondi. La stessa domanda su un volume block montato su NFS è un comando find che richiede ore.

Crittografia e controllo degli accessi

Entrambi i tipi di storage supportano la crittografia a riposo con AES-256. L'object storage rende facile il controllo degli accessi per oggetto: policy bucket, presigned URL, ACL degli oggetti e condizioni IAM. L'accesso al block storage è più grossolano — l'intero volume è collegato o no.

Per la condivisione sicura di file con link di download a tempo limitato, le presigned URL S3 (valide al massimo 7 giorni) sono il pattern standard. Per i trasferimenti senza esposizione di testo in chiaro lato server, la crittografia lato client prima dell'upload funziona con qualsiasi object store. HexaTransfer cifra con AES-256-GCM nel browser e archivia solo testo cifrato — il backend degli oggetti vede byte privi di significato.

La regola decisionale semplice

Poni tre domande:

Accedi ai dati tramite un'API di file system (POSIX, SMB, NFS)? Se sì, block o file storage.
Accedi tramite HTTP, li modifichi raramente e vuoi scalabilità illimitata? Se sì, object storage.
Il dataset supera i 10 TB ed è in crescita? Quasi sempre object storage.

Per i carichi di lavoro di trasferimento file, la risposta a (2) è sempre sì. Usa S3, R2, Azure Blob o GCS per i file stessi, e riserva il block storage per il database e il web tier che li gestiscono.

Prova su https://hexatransfer.com — gratuito, senza account, max 10 GB.