Informazioni sul modo in cui gli snapshot BLOB accumulano addebiti

La creazione di uno snapshot, una copia di sola lettura di un BLOB, può dar luogo a costi di archiviazione dei dati aggiuntivi sul conto. Quando si progetta un'applicazione, è importante tenere presente l'eventuale incremento di tali spese per ridurre al minimo i costi non necessari.

Considerazioni di fatturazione importanti

Nell'elenco seguente sono inclusi i punti principali da considerare quando si crea uno snapshot.

• Le spese sono generate per blocchi o pagine univoche, indipendentemente dal fatto che si trovino nel Blob o nello snapshot. Non sono previsti costi aggiuntivi per gli snapshot associati a un BLOB finché il BLOB su cui si basano non viene aggiornato. Una volta aggiornato, il Blob di base è diverso dai relativi snapshot, pertanto verranno addebitati i blocchi o le pagine univoche in ogni Blob o snapshot.

• Quando si sostituisce un blocco all'interno di un BLOB in blocchi, tale blocco viene successivamente addebitato come blocco univoco. Ciò è vero persino se il blocco ha lo stesso ID blocco e la stessa data che ha nello snapshot. Quando si esegue di nuovo il commit del blocco, esso è diverso dalla relativa controparte nello snapshot, pertanto ne verranno addebitati i dati. Lo stesso rimane vero per una pagina in un BLOB di pagine che viene aggiornata con dati identici.

• La sostituzione di un BLOB in blocchi chiamando il metodo UploadFile, UploadText, UploadStream o UploadByteArray sostituisce tutti i blocchi del BLOB. Se è presente uno snapshot associato al Blob, tutti i blocchi nel Blob e nello snapshot di base saranno diversi e verranno addebitati tutti i blocchi in entrambi i Blob. Questo vale persino se i dati nel BLOB di base e nello snapshot restano identici.

• Il servizio BLOB di Azure non dispone dei mezzi per determinare se due blocchi contengono dati identici. Ogni blocco che viene caricato e inviato viene trattato come univoco, persino se contiene gli stessi dati e ha lo stesso ID blocco. Poiché le spese aumentano per blocchi univoci, è importante considerare che l'aggiornamento di un Blob con uno snapshot genererà altri blocchi univoci e spese aggiuntive.

Scenari di fatturazione degli snapshot

Gli scenari seguenti dimostrano in che modo aumentano i costi per un BLOB in blocchi e i relativi snapshot. Nello scenario 1 il Blob di base non è stato aggiornato dopo l'esecuzione dello snapshot, pertanto le spese vengono addebitate solo per i blocchi univoci 1, 2 e 3:

Scenario 1: spese incrementate solo per i blocchi 1, 2 e 3.

Nello scenario 2 è stato aggiornato il Blob di base, ma non lo snapshot. Il blocco 3 è stato aggiornato, e sebbene contenga gli stessi dati e lo stesso ID, non è lo stesso del blocco 3 nello snapshot. Di conseguenza, all'account vengono addebitati quattro blocchi:

Scenario 2: spese incrementate per i blocchi 1, 2 e 3 nel Blob di base e il blocco 3 nello snapshot.

Nello scenario 3 il BLOB di base è stato aggiornato, ma lo snapshot non lo ha. Il blocco 3 è stato sostituito con il blocco 4 nel BLOB di base, ma lo snapshot continua a riflettere il blocco 3. Di conseguenza, all'account vengono addebitati quattro blocchi:

Scenario 3: spese incrementate per i blocchi 1, 2, 3 e 4.

Nello scenario 4 il Blob di base è stato completamente aggiornato e non contiene nessuno dei blocchi originali. Di conseguenza, all'account vengono addebitati tutti gli otto blocchi univoci. Questo scenario può verificarsi se si sta usando un metodo di aggiornamento come UploadFile, UploadText, UploadFromStream o UploadByteArray, in quanto questi metodi sostituiscono tutto il contenuto di un BLOB.

Scenario 4: spese incrementate per i blocchi 1, 2, 3, 4, 5, 6, 7 e 8.

Vedere anche

Utilizzo del servizio di archiviazione BLOB
Come usare il servizio di archiviazione code
Creazione di uno snapshot di un BLOB