- Servizio tabella, SQL Azure - inserire. Velocità di interrogazione su grandi quantità di dati

Question

Avevo letto molti post e articoli sul confronto tra SQL Azure e il servizio di tabella e molti di loro hanno detto che il servizio di tabella è più scalabile di SQL Azure.

• http://www.silverlight-travel.com/blog/2010/03/31/azure-table-storage-sql-azure/
• http://www.intertech.com/Blog/post/Windows-Azure-Table-Storage-vs-Windows-SQL-Azure.aspx
• Microsoft Azure Storage vs. Azure SQL Database
• https://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/2fd79cf3-ebbb-48a2-be66-542e21c2bb4d
• https://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
• https://stackoverflow.com/questions/2711868/azure-performance
• http://vermorel.com/journal/2009/9/17/table-storage-or-the-100x-cost-factor.html
• Azure Tables or SQL Azure?
• http://www.brentozar.com/archive/2010/01/sql-azure-frequently-asked-questions/
• https://code.google.com/p/lokad-cloud/wiki/FatEntities

Scusate http, io sono nuovo utente> _ < Ma http://azurescope.cloudapp.net/BenchmarkTestCases/ benchmark dimostra quadro diverso.

Il mio caso. Utilizzo di SQL Azure: una tabella con molti inserti, circa 172.000.000 al giorno (2000 al secondo). Posso aspettarmi una buona perfomance per inserti e selezioni quando ho 2 milioni di record o 9999 .... 9 miliardi di record in una tabella?

Utilizzo del servizio tabella: una tabella con un numero di partizioni. Il numero di partizioni può essere grande, molto grande.

Domanda n. 1: è il servizio di tabella presenta alcune limitazioni o migliori pratiche per la creazione di molte, molte, molte partizioni in una tabella?

Domanda n. 2: in una singola partizione Ho una grande quantità di piccole entità, come nell'esempio SQL Azure sopra. Posso aspettarmi una buona perfomance per inserti e selezioni quando ho 2 milioni di record o 9999 miliardi di entità in una partizione?

Conosco soluzioni di partizione o partizione, ma è un servizio cloud, il cloud non è potente e funziona senza le mie capacità di codice?

Domanda n. 3: Qualcuno può mostrarmi dei benchmark per interrogare una grande quantità di dati per SQL Azure e il servizio tabella?

Domanda n. 4: Potresti suggerire una soluzione migliore per il mio caso.

Answer 1

Risposta breve

1. non ho visto un sacco di partizioni che le tabelle Azure problemi (AZT), ma io non ho questo volume di dati.
2. I più elementi in una partizione, le query più lenti in quella partizione
3. dispiace no, io non hanno i parametri di riferimento
4. Vedi sotto

lungo risposta

Nella tua caso sospetto che SQL Azure non funzioni per te, semplicemente a causa dei limiti delle dimensioni di un database SQL Azure. Se ciascuna di quelle righe che stai inserendo è 1K con indici, il limite di 50 GB sarà raggiunto in circa 300 giorni. È vero che Microsoft sta parlando di database più grandi di 50 GB, ma non ci hanno messo a tempo. SQL Azure ha anche un limite di throughput che non riesco a trovare a questo punto (sono abbastanza sicuro che sia inferiore a quello che ti serve). Potresti essere in grado di aggirare questo partizionando i tuoi dati su più di un database SQL Azure.

Il vantaggio di SQL Azure è tuttavia la possibilità di eseguire query aggregate. In AZT non puoi nemmeno scrivere un select count(*) from customer senza caricare ogni cliente.

AZT ha anche un limite di 500 transazioni al secondo per partizione e un limite di "several thousand" per second per account.

Ho trovato che la scelta di cosa usare per la chiave di partizione (PK) e la chiave di riga dipende (RK) su come stai per interrogare i dati. Se si desidera accedere a ciascuno di questi elementi singolarmente, è sufficiente assegnare a ciascuna riga la propria chiave di partizione e una chiave di riga costante. Ciò significa che hai un sacco di partizione.

Per esempio, se le righe che stavi inserendo erano ordini e gli ordini appartengono a un cliente. Se fosse più comune per te elencare gli ordini per cliente, avresti PK = CustomerId, RK = OrderId. Ciò significherebbe trovare gli ordini per un cliente, è sufficiente eseguire una query sulla chiave di partizione. Per ottenere un ordine specifico è necessario conoscere CustomerId e OrderId. Più ordini aveva un cliente, più lento sarebbe stato trovare un ordine particolare.

Se fosse sufficiente accedere agli ordini solo tramite OrderId, utilizzare PK = OrderId, RK = string.Empty e inserire CustomerId in un'altra proprietà. Mentre puoi ancora scrivere una query che riporta tutti gli ordini per un cliente, perché AZT non supporta indici diversi da PartitionKey e RowKey se la tua query non usa un PartitionKey (e talvolta anche se lo fa a seconda di come scrivi loro) causerà una scansione della tabella. Con il numero di dischi di cui parli sarebbe molto brutto.

In tutti gli scenari che ho riscontrato, avere molte partizioni non sembra preoccupare troppo l'AZT.

Un altro modo in cui è possibile suddividere i dati in AZT, spesso non menzionato, consiste nel mettere i dati in tabelle diverse. Ad esempio, potresti voler creare una tabella per ogni giorno. Se si desidera eseguire una query per la scorsa settimana, eseguire la stessa query su 7 diverse tabelle. Se sei pronto a fare un po 'di lavoro sul client, puoi persino eseguirli in parallelo.