Quando dovrei usare Sql Azure e quando dovrei usare la tabella Storage?

Question

Quando dovrei usare Sql Azure e quando dovrei usare la tabella Storage? Stavo pensando, utilizzare la memorizzazione della tabella per gli scenari di elaborazione delle transazioni, ad es. tipo di scenario di debit credit account e utilizzare Sql Azure quando i dati non verranno utilizzati a fini di transazione, ad es. reporting. Cosa ne pensi?

Answer 1

Questa è una domanda eccellente e una delle decisioni più difficili da invertire per gli architetti della soluzione quando si progetta per Azure.

esistono dimensioni mutliple da considerare: Sul lato negativo, SQL Azure è relativamente costoso per gigabyte di stoccaggio, non scala super bene e si limita al 150gigs/database tuttavia, e questo è molto importante, ci non ci sono commissioni di transazione contro SQL Azure e i tuoi sviluppatori sanno già come codificarlo.

ATS è un animale diverso tutti insieme. Capace di mega scalabilità, è economico da immagazzinare, ma diventa costoso per accedere frequentemente. Richiede anche una notevole quantità di potenza della CPU dai tuoi nodi da manipolare. Fondamentalmente costringe i tuoi nodi di calcolo a diventare server mini-db mentre la delega di tutte le attività relazionali viene girata su di loro.

Quindi, a mio parere, i dati a cui si accede frequentemente che non richiedono un'enorme scalabilità e che non sono di grandi dimensioni devono essere destinati a SQL Azure, in caso contrario Servizi di tabelle di Azure.

L'esempio specifico, i dati transazionali delle transazioni finanziarie sono un luogo perfetto per ATS, mentre le meta informazioni (profili account, nomi, indirizzi, ecc.) Sono perfette per SQL Azure.

Answer 2

Quando si tratta di transazioni, è solo il contrario: SQL Azure supporta le transazioni; la memoria della tabella non lo fa.

SQL Azure è fondamentalmente SQL Server in esecuzione all'interno di Windows Azure, quindi se avete un un'applicazione esistente che utilizza SQL Server, SQL Azure fornisce un percorso di migrazione buona. Tuttavia, esistono limiti alla quantità di un database che è possibile disporre su SQL Azure (attualmente 150 GB), pertanto esistono limiti a quanto può ridimensionare.

L'archiviazione della tabella, d'altra parte, è estremamente scalabile, ma richiede un modo diverso di pensare. È non un database relazionale. Vedi per es. questo articolo per una bella introduzione: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Answer 3

Igor e Mark hanno dato grandi risposte. Vorrei aggiungere ancora un po 'di più ...

Con il database SQL (precedentemente denominato SQL Azure), ora è possibile avere database fino a 500 GB. Per andare oltre, devi dividere i tuoi dati. Nota: inizialmente suggerivo i frammenti con le federazioni SQL, ma da allora questa funzione è stata ritirata.

ATS offre transazioni a livello di partizione (transazioni di gruppi di entità). Vedere this MSDN article per ulteriori informazioni. Questo non è solido come le transazioni SQL Azure, ma consente operazioni batch in un'unica transazione.

EDIT E 'passato più di un anno da quando questa domanda è stata posta (e ha risposto). Un punto di confronto era sui prezzi. Mentre SQL Azure è ancora più costoso di ATS, il costo di SQL Azure è diminuito significativamente nell'ultimo anno. I database ora hanno prezzi scalari, a partire da $ 4.99 per 100 MB, l'aumento a $ 225 per 150GB (un forte calo dai $ 9.99/GB prezzi rispetto allo scorso anno. Dettagli sui prezzi completi sono here.

EDIT agosto 2014 Un altro anno dopo, un altro aggiornamento. Mentre i livelli web/aziendali continuano a esistere, vengono retrodiffusi (e le federazioni SQL non sono più disponibili) I nuovi livelli Base, Standard e Premium sono ora disponibili (vedere here per dettagli)

Answer 4

Alcune di queste risposte non sembrano complete , quindi aggiungerò i miei 2 cent.

Punti buoni del tavolo azzurro:

• Punto di forza è la sua capacità di memorizzare molti piccoli dati; tavolo Azure si basa su Azure Blob, ma è orientata verso i dati più piccoli
• molto meno costosa di Azure SQL Server
• Ogni volta che si conosce sia la chiave di partizione e la chiave fila, l'accesso ai dati è molto veloce.
• Entity transactions sono possibili se si inseriscono due "schemi" diversi nella stessa chiave di partizione.
• Dove la dimensione totale di riga è inferiore a 980K (SQL Row)
• Dove ogni proprietà è inferiore a 64 K (SQL Colonna)
• può agire come SQL di un uomo povero.

punti negativi della tabella Azure:

• SQL è il punto debole. Non aspettarti di usarlo su una tabella SQL di grandi dimensioni o subirai problemi di prestazioni.
• limitata SQL è disponibile, non aspettatevi si unisce di qualsiasi tipo, oltre a ciò che si sceglie di implementare in LINQ
• Azure Table SQL non scala così come la sua capacità di memorizzare una quantità infinita di dati
• Ogni volta che si non specificare sia una chiave di partizione e la chiave di fila in una clausola WHERE, si aspettano una scansione della tabella lento a verificarsi
• aspettatevi tabella prestazioni di scansione a degradare quando si aggiungono più righe
• non aspettatevi query tabella Azue di essere veloce come si aggiungono più righe
• In conclusione, se si utilizza Azure Table per agire come SQL non aggiungere un sacco di d ata. Se disponi di molti dati (gigabyte), non pianificarti di ottenere query SQL ad alte prestazioni su di esso. Potrai risparmiare denaro se non hai bisogno di quelle funzioni SQL standard.

Answer 5

La vera risposta è "Prova davvero a non utilizzare Archiviazione tabella di Azure". Ogni volta che si passa da un DB relazionale a un DB no-sql, è ovvio che si dovrà cambiare il modo in cui si pensa all'architettura di archiviazione. Ma i problemi con ATS vanno molto oltre la semplice necessità di "pensare in modo diverso". Come altri hanno sottolineato, non si tratta solo di un data store "No-SQL", è un'istanza particolarmente stentata, priva di handicap e con funzionalità molto basse di un negozio No-SQL. Non si tratta di dover "pensare in modo diverso" all'ATS; è una questione di ATS che non ti dà gli strumenti di cui hai bisogno per fare il tuo lavoro - strumenti che altri archivi dati no-sql danno do.

L'unica cosa buona di ATS è che è possibile inserire molti e molti dati in esso molto rapidamente e con costi di archiviazione minimi.Tuttavia, non puoi sperare di ottenere di nuovo quei dati di nuovo, a meno che tu non abbia la fortuna di avere un caso d'uso che corrisponde magicamente al suo modello di archiviazione Partition-Key/Row-Key. Se non lo fai, e sospetto che poche persone lo facciano, eseguirai molte scansioni della partizione e elaborerai tu stesso i dati.

Oltre a ciò, Azure Table Storage sembra essere un punto morto in termini di sviluppo. Se si guarda alla richiesta di "Supporto indici secondari" sul forum di feedback Azure (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), si può vedere che il supporto per gli indici secondari è stato promesso fin dal 2011, ma è stato fatto alcun progresso. Né sono stati compiuti progressi in nessuna delle altre principali richieste di archiviazione delle tabelle.

Ora, so che Scott Guthrie è un ragazzo di qualità, quindi la mia speranza è che tutta questa stagnazione sul fronte di Storage Table sia una prefazione di Azure che la fissa e che crea qualcosa di veramente interessante. Questa è la mia speranza (anche se ho zero prove che è il caso). Ma per ora, a meno che tu non abbia una scelta, ti consiglio vivamente contro Azure Table Storage. Utilizzare SQL di Azure; utilizzare la propria istanza di MongoDB o qualche altro DB No-SQL; o utilizzare Amazon DynamoDB. Ma non utilizzare Archiviazione tabella di Azure.