Azure database SQL vs MS SQL Server su macchina dedicata

Question

Sono attualmente in esecuzione un'istanza di MS SQL Server 2014 (12.1.4100.1) su una macchina dedicata I affittare a $ 270/mese con le seguenti specifiche:

• Intel Xeon E5-1660 processore (sei core 3.3GHz fisiche + hyperthreading + turbo> 3.9GHz)
• 64 GB registrata DDR3 ECC memoria
• 240GB SSD Intel
• 45000 GB di trasferimento banda

Ho lavorato un po 'con il database SQL di Azure per un po' e ho avuto l'idea di passare alla loro piattaforma. Ho attivato un database SQL di Azure utilizzando il livello di prezzo Premium P2 su un server V12 (solo per testare le cose) e caricato una copia del mio database esistente (dal computer dedicato).

Ho eseguito diverse serie di query affiancate, una contro il database sul computer dedicato e una contro il database SQL Azure P2. I risultati sono stati piuttosto scioccanti: la mia macchina dedicata ha sovraperformato (in termini di tempo di esecuzione) il db Azure di un enorme margine ogni volta. In genere, l'istanza di db dedicata termina in meno di 1/2 a 1/3 del tempo impiegato da Azure db per eseguire.

Ora capisco i numerosi vantaggi della piattaforma Azure. È gestito rispetto alla mia configurazione non gestita sulla macchina dedicata, ha un ripristino point-in-time migliore di quello che ho, il firewall è facilmente configurato, c'è la geo-replica, ecc. Ecc. Ma ho un database con centinaia di tabelle con decine a centinaia di milioni di record in ogni tabella e talvolta devono eseguire query su più join, ecc., quindi le prestazioni in termini di tempo di esecuzione sono davvero importanti. Trovo semplicemente scioccante che un servizio di ~ $ 930/mese si comporti male in prossimità di un noleggio dedicato di $ 270 al mese. Sono ancora abbastanza nuovo per SQL nel suo complesso, e molto nuovo per i server/etc., Ma questo non si aggiunge a qualcun altro? Qualcuno forse ha qualche idea su qualcosa che mi manca o sono le altre caratteristiche "gestite" del database SQL di Azure che si suppone possano compensare la differenza di prezzo?

In conclusione, sto iniziando a superare le capacità della mia macchina dedicata, e speravo davvero che il database SQL di Azure sarebbe stato un bel passo avanti, ma a meno che non mi manchi qualcosa, non lo è. Sono ancora troppo piccolo per fare affari e spendere centinaia di migliaia su un'altra piattaforma.

Qualcuno ha qualche consiglio su se mi manca qualcosa, o è la prestazione che sto vedendo in linea con quello che ti aspetteresti? Dispongo di altre opzioni in grado di produrre prestazioni migliori rispetto alla macchina dedicata attualmente in uso, ma non costano decine di migliaia al mese? C'è qualcosa che posso fare (configurazione/impostazione) per il mio database SQL di Azure che aumenterebbe i tempi di esecuzione? Ancora una volta, ogni aiuto è apprezzato.

EDIT: Consentitemi di rivedere la mia domanda per renderlo un po 'più chiaro: è quello che vedo in termini di prestazioni di esecuzione del tempo puro, in cui un server dedicato @ $ 270 al mese è molto più performante di Azure di Microsoft SQL P2 livello P2 @ $ 930/mese? Ignora gli altri "vantaggi" come gestito o non gestito, ignora l'uso previsto come se Azure sia destinato alla produzione, ecc. Devo solo sapere se mi manca qualcosa con il DB SQL di Azure, o se dovrei davvero ottenere MOLTO meglio prestazioni da una singola macchina dedicata.

Answer 1

C'è un'alternativa da Microsoft per Azure SQL DB:

“Fondo di una macchina virtuale di SQL Server in Azure”

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/

Una spiegazione dettagliata delle differenze tra le due offerte: “ La comprensione di database SQL Azure e SQL Server in macchine virtuali Azure”

https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

Una differenza significativa tra il server SQL standalone e il database SQL di Azure è che con DB SQL si stanno pagando alti livelli di disponibilità, che si ottiene eseguendo più istanze su macchine diverse. Sarebbe come noleggiare 4 delle macchine dedicate e eseguirle in un gruppo di disponibilità AlwaysOn, che cambierebbe sia i costi che le prestazioni. Tuttavia, poiché non hai mai menzionato la disponibilità, suppongo che questo non sia un problema nel tuo scenario. SQL Server in una VM può corrispondere meglio alle tue esigenze.

Answer 2

(Disclaimer: lavoro per Microsoft, anche se non su Azure o SQL Server).

"SQL di Azure" non è equivalente a "SQL Server" - e personalmente desidero offrire un tipo di "server SQL ospitato" anziché SQL di Azure.

Sulla superficie i due sono gli stessi: sono entrambi i sistemi di database relazionali con la potenza di T-SQL per interrogarli (beh, entrambi, sotto-the-hood usano lo stesso DBMS).

Azure SQL è diverso dal fatto che l'idea è che si dispone di due database: un database di sviluppo che utilizza un SQL Server locale (idealmente 2012 o successivo) e un database di produzione su SQL di Azure. Non è necessario (mai) modificare direttamente il database SQL di Azure e in effetti si scoprirà che SSMS non offre strumenti di progettazione (Progettazione tabelle, Progettazione viste, ecc.) Per Azure SQL. Invece, si progetta e si lavora con il proprio database SQL Server locale e si creano file "DACPAC" (o speciali file XML "di modifica", che possono essere generati da SSDT) ​​che quindi modificano il DB di Azure in modo tale da copiare il proprio DB di sviluppo, un tipo del sistema "replica design".

In caso contrario, come avete notato, Azure SQL offre built-in resilienza, i backup, amministrazione semplificata, ecc

quanto riguarda le prestazioni, è possibile ti mancava indici o altre ottimizzazioni? È anche possibile notare una latenza leggermente superiore con Azure SQL rispetto a un SQL Server locale, ho visto i tempi di ping (da una VM di Azure a un host SQL di Azure) di circa 5-10 ms, il che significa che è necessario progettare la propria applicazione in modo chatty o per parallelizzare le operazioni di recupero dei dati al fine di ridurre i tempi di caricamento della pagina (supponendo che questa sia un'applicazione web che stai costruendo).

Answer 3

SQL DB ha disponibilità incorporata (che può influire sulle prestazioni), funzionalità di ripristino point-time e funzionalità DR. Hai la possibilità di ridimensionare il tuo DB in base al tuo utilizzo per ridurre i costi. È possibile migliorare le prestazioni della query utilizzando la query globale (dati shard). SQl DB gestisce aggiornamenti e patch automatici e migliora notevolmente la storia della gestibilità. Potrebbe essere necessario pagare un piccolo premio per questo. Il caching a livello di applicazione/la distribuzione uniforme del carico, il downgrade a freddo ecc. Possono aiutare a migliorare le prestazioni del database e ottimizzare i costi.

Answer 4

Perf e la disponibilità da parte, ci sono molti altri fattori importanti da considerare:

• Costo totale: il vostro $ 270 costo del noleggio è solo uno dei tanti fattori di costo. Spazio, energia e hvac sono altri costi fisici. Poi c'è il costo dell'amministrazione.Pensa al lavoro che devi fare ogni patch martedì e quando Windows o SQL Server vengono forniti con un service pack o un aggiornamento cumulativo. Anche se non li collaudi prima del lancio, ci vuole ancora tempo e fatica. Se esegui il test, c'è una seconda macchina e duplica l'istanza del prodotto e il carico di lavoro per il test.
• Sicurezza: c'è un LOT scritto su quanto sia pericoloso, pericoloso e rischioso archiviare tutti i dati che ti interessano nel cloud. Personalmente, ho visto peggiorare le implementazioni e i processi di sicurezza con i server locali (anche nelle banche e nelle agenzie federali) rispetto a quelli che ho visto con i principali fornitori di cloud (Microsoft, Amazon, Google). È molto lavoro per sistemare le cose, quindi lavorare ancora di più per farle stare bene. Inoltre, è possibile visualizzare e controllare i propri SLA di sicurezza (vedere Azure a).
• Scalabilità: non solo la scalabilità grezza ma il costo e lo sforzo di scalabilità. Il DB SQL di Azure ha recentemente rilasciato l'enorme edizione P11 che ha 7 volte la capacità di calcolo della P2 testata. Scalare su e giù non è istantaneo, ma veramente facile e ragionevolmente veloce. La parte migliore è (per me comunque), può essere urtato ad un'edizione superiore quando eseguo query di grandi dimensioni o operazioni di reindicizzazione e poi di nuovo giù per carichi "normali". Questo è difficile da fare con un normale SQL Server su bare metal: affittare o acquistare una scatola veramente grande che rimane inattiva il 90% delle volte o richiedere tempi di fermo per spostarsi. Leggermente più facile se in una VM; è possibile aumentare la memoria online, ma è comunque necessario rimbalzare l'istanza per aumentare la CPU; il DB SQL di Azure rimane online durante le operazioni di aumento/diminuzione della scala.