Tabelle Azure o SQL Azure?

Question

Sono in fase di progettazione di un'applicazione web che sarà ospitato in Azure con ASP.NET per il sito web e Silverlight all'interno del sito per una ricca esperienza utente. Dovrei usare tabelle Azure o SQL Azure per la memorizzazione dei miei dati applicazione?

Answer 1

Azure Storage Table sembra essere meno costoso di SQL Azure. E 'anche più altamente scalabile di SQL Azure.

SQL Azure è più facile lavorare con se hai fatto un sacco di lavoro di database relazionali. Se tu fossi il porting di un'applicazione che è stata già utilizzando un database SQL, per poi passare a SQL Azure sarebbe la scelta più ovvia, ma che è l'unica situazione in cui lo consiglio.

La principale limitazione sulle Tabelle Azure è la mancanza di indici secondari. Lo ha annunciato in PDC '09 ed è attualmente indicato come in arrivo, ma non v'è stato alcun annuncio arco di tempo. (Vedere http :? //windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes ref = titolo )

Ho visto la proposta di utilizzare un sistema ibrido in cui si usa tavolo e stoccaggio blob per la maggior parte dei vostri dati, ma utilizzare SQL Azure per gli indici, la ricerca e il filtraggio. Tuttavia, non ho avuto la possibilità di provare questa soluzione ancora me stesso.

Una volta che gli indici secondari vengono aggiunti allo stoccaggio tabella, sarà essenzialmente una nuvola basato NoSQL del sistema e sarà molto più utile di quanto non sia ora.

Answer 2

Nonostante i nomi simili SQL Azure Tavoli e Storage Table hanno ben poco in comune.

Qui ci sono due link che potrebbero aiutare a:

• Storage Table, un fattore di costo 100x
• Enti grasso su Storage Table

In sostanza, la prima domanda dovrebbe chiedersi è Fa la mia app davvero bisogno di scala? Se no, poi per SQL Azure.

Answer 3

Per coloro che cercano di decidere tra le due opzioni, assicurarsi di fattore di obblighi di segnalazione nell'equazione. SQL Azure reporting e altri prodotti di reporting supportano SQL Azure, fuori dalla scatola. Se è necessario generare report complessi o flessibili, probabilmente si vorrà evitare Storage Table.

Answer 4

tavoli Azure sono più economici, più semplice e la scala migliore di SQL Azure. SQL Azure è un ambiente SQL gestito, multi-tenant in natura, così si dovrebbe analizzare se i vostri requisiti di prestazione sono in forma per SQL Azure. Una versione Premium di SQL Azure è stato annunciato ed è in anteprima al momento della stesura (vedi QUI ).

Credo che i fattori decisivi per decidere tra le tabelle SQL Azure e Azure sono i seguenti:

• Avete bisogno di fare complessa unisce e utilizzare indici secondari? Se sì, SQL Azure è l'opzione migliore.
• Avete bisogno di stored procedure? Se sì, SQL Azure.
• Avete bisogno di capacità di auto-ridimensionamento? tavoli Azure è l'opzione migliore.
• Righe all'interno di una tabella Azure non può superare i 4 MB di dimensione. Se avete bisogno di memorizzare grandi quantità di dati all'interno di una riga, è meglio conservarlo in deposito blob e fare riferimento URI del blob nella riga della tabella.
• Avete bisogno di memorizzare enormi quantità di dati semi-strutturati? Se sì, tavoli Azure sono vantaggiosi.

Sebbene tabelle Azure sono estremamente vantaggioso in termini di semplicità e costo, ci sono alcune limitazioni che devono essere presi in considerazione. Si prega di consultare qui di qualche indicazione iniziale.

Answer 5

Un'altra considerazione è la latenza. Ci deve essere utilizzato un sito che Microsoft ha corso con microbenchmarks su throughput e latenza di varie dimensioni degli oggetti con negozio tavolo e SQL Azure. Dal momento che il sito non è più disponibile, mi limiterò a darvi una rozza approssimazione da quello che mi ricordo. negozio tabella tende ad avere molto più elevato rendimento rispetto SQL Azure. SQL Azure tende ad avere una bassa latenza (anche del 1 / 5th).

E 'già stato detto che negozio tabella è facile da scala. Tuttavia, SQL Azure in grado di scalare anche con Federazioni . Si noti che le Federazioni (in modo efficace sharding ) aggiunge un sacco di complessità alla vostra applicazione. Sono, inoltre, non sicuro di quanto Federazioni influisce prestazioni, ma immagino ci sia un certo overhead.

Se la continuità del business è una priorità, si consideri che con Azure si ottiene a buon mercato geo-replica per impostazione predefinita. Con SQL Azure, è possibile realizzare qualcosa di simile, ma con più fatica con SQL sincronizzazione di dati . Si noti che SQL di sincronizzazione di dati prestazioni anche incorre in testa in quanto richiede trigger su tutte le tabelle a guardare per le modifiche dei dati.

Answer 6

mi rendo conto che è una vecchia questione, ma ancora molto valida uno, quindi sto aggiungendo la mia risposta ad esso.

CoderDennis e altri hanno fatto notare alcuni dei fatti - Tabelle Azure è più economico, e Tabelle Azure può essere molto più grande, più efficiente, ecc Se siete sicuri al 100% si bastone con Azure, andare con le tabelle.

Tuttavia, questo presuppone che avete già deciso su Azure. Utilizzando le tabelle Azure, ti stai fissando nella piattaforma Azure. Significa scrivere codice molto specifico per le tabelle Azure, che non è solo andare a porta oltre ad Amazon, si dovrà riscrivere le aree del codice. D'altra parte la programmazione per un database SQL con porta volontà LINQ sopra molto più facilmente a un altro servizio cloud.

Questo potrebbe non essere un problema se hai già deciso sulla vostra piattaforma cloud.

Answer 7

Suggerisco guardando Azure cache in combinazione con Azure Table. Tavolo da solo ha 200-300ms latenze, con punte occasionali più elevate, che possono rallentare in modo significativo i tempi di risposta verso il basso / UI interattività. Cache + Tabella sembra essere una combinazione vincente, per me.

Answer 8

Per la vostra domanda, io voglio parlare di come decidere con la logica scegliere SQL Tavolo e che hanno bisogno di usare Azure Table.

Come sappiamo SQL Table è un motore di database relazionale. ma se si dispone di un grande dati in una tabella della tabella di SQL non è applicabile, poiché SQL query di ottenere grandi dei dati è lenta.

In questo momento è possibile scegliere Azure Table, la query Azure Table è così veloce quindi SQL Tabella per i big data, ad esempio, nel nostro sito, qualcuno ha sottoscritto molti articoli, facciamo l'articolo come mangime per l'utente, ogni utente ha una copia del titolo dell'articolo e la descrizione, quindi nella tabella articolo ci sono un sacco di dati, se usiamo SQL tabella, ogni esecuzione della query forse prende più di 30 secondi. Ma in Azure Table convincere gli utenti di alimentazione articolo di PartitionKey e RowKey è così veloce.

Da questo esempio si può sapere come scegliere tra in SQL Azure Table e Tabella.

Answer 9

mi chiedo se stiamo andando a finire con alcune librerie nuvola api "produttore indipendente" a tempo debito?

Answer 10

Credo che bisogna prima definire che cosa i vostri imbuti di utilizzo delle applicazioni sono. Il vostro modello di dati può essere sottoposto a cambiamenti frequenti o si tratta di uno stabile? Devi essere in grado di eseguire inserti ultra veloci e legge non sono così complicate? Avete bisogno di avanzare google come la ricerca? Memorizzazione CHIAZZE?

Queste sono le domande (e non solo) che si deve chiedere e rispondere a se stessi, al fine di decidere se è più probabile intenzione di utilizzare NoSQL o SQL approccio nella memorizzazione dei dati.

Si prega di considerare che entrambi gli approcci possono facilmente coesistere e può essere estesa con una BLOB pure.

Answer 11

entrambe le tabelle Azure e SQL Azure sono due diversi beasts.Both sono pensati per diversi scenari, uno con Azure tabella è che non è possibile spostare da azzurro a qualsiasi altra piattaforma, a meno che non si scrive fornitori nel codice in grado di gestire tali cambiamenti .