Prestazioni di archiviazione di tabelle di Azure dalla lettura con threading parallelo parallelo

Question

Versione corta: è possibile leggere da dozzine o centinaia di partizioni di tabella in modalità multithreading per aumentare le prestazioni di ordini di grandezza?

Versione lunga: Stiamo lavorando a un sistema che memorizza milioni di righe nell'archivio della tabella di Azure. Partizioniamo i dati in piccole partizioni, ognuna delle quali contiene circa 500 record, che rappresenta un valore giornaliero di dati per un'unità.

Poiché Azure non dispone di una funzione di "somma", per ricavare un valore di dati di un anno, è necessario utilizzare un pre-caching o sommare i dati da soli in un ruolo Web o di lavoro di Azure.

Assumendo il seguente: - Lettura di una partizione non influisce sulle prestazioni di un altro - La lettura di un partizione ha un collo di bottiglia in base a velocità di rete e il recupero di server

Possiamo quindi prendere una congettura che se volevamo per sommare rapidamente un sacco di dati al volo (1 anno, 365 partizioni), potremmo usare un algoritmo fortemente parallelo e scalerebbe quasi perfettamente al numero di thread. Ad esempio, potremmo utilizzare le estensioni parallele .NET con 50+ thread e ottenere un ENORME incremento delle prestazioni.

Stiamo lavorando alla creazione di alcuni esperimenti, ma volevo vedere se questo è stato fatto prima. Dal momento che il lato .NET è sostanzialmente inattivo in attesa di operazioni a latenza elevata, questo sembra perfetto per il multi-threading.

Answer 1

Ci sono dei limiti imposti al numero di transazioni che possono essere eseguite su un account di archiviazione e una particolare partizione o server di archiviazione in un determinato periodo di tempo (circa 500 req/s). In questo senso, esiste un limite ragionevole al numero di richieste che è possibile eseguire in parallelo (prima che inizi a sembrare un attacco DoS).

Inoltre, in fase di implementazione, sarei cauto sui limiti di connessione concomitanti imposti sul client, ad esempio da System.Net.ServicePointManager. Non sono sicuro che il client di archiviazione di Azure sia soggetto a tali limiti; potrebbero richiedere un aggiustamento.