Come regola generale, si desidera evitare scansioni della tabella quando possibile. Sono operazioni molto costose (specialmente se si hanno molte partizioni). non tanto dal punto di vista dello stress da tavolo, ma hanno una latenza aggregata molto elevata (spiegata di seguito). Detto questo, a volte semplicemente non è possibile evitarlo.
Abbiamo aggiornato l'architettura di archiviazione e aumentato alcuni dei limiti di destinazione.
http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
Ogni account di archiviazione è ora 20K IOPS/sec. Ogni partizione ora è 2k/sec
Il modo in cui le partizioni interagiscono è un po 'sottile e dipende dal modo in cui vengono utilizzate (e cambia nel tempo).
Lo storage di Azure ha due fasi: un gruppo di server gestisce gli intervalli, l'altro imposta la memoria effettiva (ovvero le 3 copie). Quando una tabella è fredda, tutte le partizioni possono essere servite da un server. Quando le partizioni vengono sottoposte a stress prolungato, il sistema inizierà a distribuire automaticamente il carico di lavoro (ad esempio shard) su server aggiuntivi. I frammenti sono fatti sui confini delle partizioni.
Per lo stress basso/medio, è possibile che non si raggiunga la soglia per squartare o solo un numero minimo di volte. Anche il modello di accesso avrà un certo impatto (se si aggiunge solo, lo sharding non aiuta). L'accesso casuale a tutti i modelli scalerà di gran lunga il migliore. Quando il sistema si sta riequilibrando, si otterrà una risposta 503 per alcuni secondi e quindi le operazioni torneranno alla normalità.
Se si esegue una scansione della tabella, si effettuano effettivamente più viaggi di andata e ritorno sulla tabella.Quando una query raggiunge la fine di una partizione, la risposta verrà restituita con qualsiasi dato trovato (o nessun dato se i criteri non sono stati soddisfatti) e un token di continuazione. La query viene quindi reinviata (e restituita con w/token) ancora e ancora fino a raggiungere la fine della tabella. Questo è sottratto dall'SDK, ma se hai fatto chiamate dirette al REST lo vedresti.
Dal punto di vista delle prestazioni della tabella, la scansione influirebbe solo sulla partizione in cui è attualmente sottoposta a scansione.
Per velocizzare una query estesa che colpisce più partizioni, è possibile suddividerla in un accesso parallelo multiplo (ad esempio, un thread per partizione) e quindi unire nel client. In realtà dipende dalla quantità di dati che si riceve, dalla grandezza del tavolo, ecc.