Archiviazione tabelle di Azure: quanto velocemente posso eseguire la scansione delle tabelle?

Question

Tutti avvertono di non eseguire query su oggetti diversi da RowKey o PartitionKey in Azure Table Storage (ATS), per evitare di essere costretti a eseguire scansioni di tabelle. Per un po ', questo mi ha paralizzato nel cercare di trovare esattamente il giusto PK e RK e creare indici pseudo-secondari in altre tabelle quando avevo bisogno di interrogare qualcos'altro.

Tuttavia, mi viene in mente che eseguirò la scansione delle tabelle in SQL Server quando ho ritenuto opportuno.

Quindi la domanda diventa, quanto velocemente posso eseguire la scansione di una tabella di Azure. Si tratta di una costante in entità/secondo o dipende dalla dimensione del record, ecc. Esistono alcune regole pratiche su quanti record sono troppi per eseguire scansioni di tabelle se si desidera un'applicazione reattiva?

Answer 1

Il problema di una scansione della tabella ha a che fare con l'attraversamento dei confini della partizione. Il livello di prestazioni garantito è impostato in modo esplicito a livello di partizione. pertanto, quando si esegue una scansione completa della tabella, a) non è molto efficiente, b) non ha alcuna garanzia di prestazioni. Questo perché le partizioni stesse sono impostate su nodi di archiviazione separati e quando si esegue una scansione di partizione trasversale, si stanno consumando quantità potenzialmente massicce di risorse (vincolando più nodi contemporaneamente).

Credo che l'effetto di oltrepassare questi limiti porti anche a continuazione di token, che richiedono ulteriori round-trips per lo storage per recuperare i risultati. Ciò si traduce in una riduzione delle prestazioni e in un aumento dei conteggi delle transazioni (e successivamente dei costi).

Se il numero di partizioni/nodi che si attraversano è piuttosto piccolo, è probabile che non si notino problemi.

Ma per favore non citatemi su questo. Non sono un esperto di Archiviazione di Azure. In realtà è l'area di Azure di cui sono meno esperto. : P

Answer 2

Penso che il Brent sia al 100% sui soldi, ma se senti ancora di volerlo provare, posso solo suggerire di eseguire alcuni test per scoprirlo. Prova a includere partitionKey nelle tue query per evitare di attraversare le partizioni perché alla fine della giornata è il killer delle prestazioni.

Answer 3

tabelle Azure non sono ottimizzati per le scansioni di tabella. La scansione della tabella potrebbe essere accettabile per un lavoro in background di lunga durata, ma non lo farei quando è necessaria una risposta rapida. Con una tabella di qualsiasi dimensione ragionevole, dovrai gestire i token di continuazione quando la query raggiunge un limite di partizione o ottiene risultati di 1k.

Il team di archiviazione di Azure ha un great post which explains the scalability targets. Il target di throughput per una singola partizione di tabella è 500 entità/sec. L'obiettivo generale per un account di archiviazione è 5.000 transazioni al secondo.

Answer 4

La risposta è Impaginazione. Utilizzare top_size - numero massimo di risultati o record nel risultato - in combinazione con next_partition_key e next_row_key i token di continuazione. Ciò comporta una differenza di prestazioni significativa persino fattoriale. Per uno, i risultati sono statisticamente più propensi a provenire da una singola partizione. I risultati chiari mostrano che i set sono raggruppati per la chiave di continuazione della partizione e non per la riga continua.

In altre parole, è anche necessario pensare all'interfaccia utente o all'uscita del sistema. Non preoccupatevi di restituire più di 10 a 20 risultati max. 50. L'utente probabilmente non utilizzerà o esaminerà più.

Suoni folli. Fai una ricerca su Google per "cane" e nota che la ricerca restituisce solo 10 elementi. Non piu. I prossimi record sono disponibili per te se ti preoccupi di premere 'continua'. La ricerca ha dimostrato che quasi nessun utente si avventura oltre quella prima pagina.

il select (restituendo un sottoinsieme dei valori-chiave) può fare la differenza; ad esempio, utilizzare select = "PartitionKey,RowKey" o 'Name' qualunque sia il minimo necessario.

"Credo, che l'effetto di attraversare questi confini si traduce anche in gettoni continuazione, che richiedono ulteriore round-viaggi in stoccaggio per recuperare i risultati. Ciò si traduce quindi nella riduzione prestazioni, così come un aumento dei conteggi delle transazioni (e costi successivi). "

... è leggermente errato. il token di continuazione non viene utilizzato a causa dei confini di attraversamento, ma perché le tabelle azzurre non consentono più di 1000 risultati; quindi i due token di continuazione sono usati per il prossimo set. default top_size è essenzialmente 1000.

Per il piacere della visualizzazione, ecco la descrizione per le query sulle entità azure python api. gli altri sono più o meno gli stessi.

''' 
    Get entities in a table; includes the $filter and $select options. 

    table_name: Table to query. 
    filter: 
    Optional. Filter as described at 
    http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx 
    select: Optional. Property names to select from the entities. 
    top: Optional. Maximum number of entities to return. 
    next_partition_key: 
    Optional. When top is used, the next partition key is stored in 
    result.x_ms_continuation['NextPartitionKey'] 
    next_row_key: 
    Optional. When top is used, the next partition key is stored in 
    result.x_ms_continuation['NextRowKey'] 
    '''