Si consiglia di utilizzare SQL Server come database per applicazioni scalabili in modo massiccio?

Supponiamo che tu stia progettando di creare un sito Web della scala di Facebook (se ho intenzione di citare il nome di un sito Web, perché non Facebook ?!). Si consiglia di utilizzare SQL Server come database per tali applicazioni?

Sto ponendo questa domanda perché molti miei colleghi dicono che SQL Server non dovrebbe essere usato tali applicazioni. Preferiscono invece Oracle o MySQL.

Sì , SQL Server è stato progettato per un utilizzo intenso, incluso il Web. Ha la capacità di essere messo in molte configurazioni diverse come istanze di memoria accoppiate con istanze di una cpu e una SAN come memoria.

Chiedi consigli al tuo integratore o evangelista Microsoft locale.

Puoi trovare molte risorse per quanto riguarda le funzionalità di ridimensionamento di SQL Server sul Web e come antipasto ecco un bel post sul blog del team di SQL Server sull'argomento: http://blogs.msdn.com/b/sqlcat/archive/ 2008/06/12 / sql-server-scala-out.aspx

Assicurati di controllare in che modo Azure fornisce SQL Server nel cloud.

SQL Server è la corrispondenza per qualsiasi altro database per questo tipo di lavoro, ma se stai pensando di fare qualcosa a quel tipo di scala, potresti lavorare meglio con un sistema di archiviazione di tabelle cloud anziché con un database relazionale convenzionale in termini di scalabilità o la progettazione di un sistema eterogeneo che utilizza l'archiviazione delle tabelle per la gestione dei dati su larga scala e un database per i luoghi in cui sono necessarie le strutture relazionali o transazionali che offrono.

Non dovresti usare i tradizionali motori di database se hai bisogno di autentiche capacità scalabili su vasta scala.

Database tradizionali SQL fanno scala abbastanza bene (troverete un sacco di esempi di grandi siti utilizzando MySQL, SQL Server o Orcale), ma ad un certo punto si sarà raggiunto il limite di scalabilità. Esattamente quando ciò accade dipenderà dal livello della domanda, dalla complessità dei requisiti dell'applicazione, da quanto sei disposto a spendere per server costosi e da quanto sei in grado di ottimizzare l'utilizzo del database. Molti siti non raggiungeranno mai questo limite, ma se lo fai allora è piuttosto doloroso e dovrai affrontare una grande sfida ingegneristica per risolvere il problema.

Oltre a questo punto, hai davvero bisogno di un database NoSQL completamente distribuito , ad esempio qualcosa come Cassandra , che in realtà è stato sviluppato su Facebook per risolvere alcune delle loro sfide relative ai big data. I database NoSQL sacrificano esplicitamente alcune delle tradizionali funzionalità del database SQL (solitamente attorno a transazioni, blocco ed eventuale coerenza) al fine di consentire una scalabilità orizzontale effettivamente illimitata.

Nel complesso, il mio consiglio sarebbe di capire se hai davvero bisogno di un'enorme scalabilità e di scegliere di conseguenza il tuo percorso tecnologico.

Sì. Credo che Microsoft Live.com sia basato su SQL Server.

Essendo un fan di Linux / PostgreSQL, lasciami dire che puoi creare Facebook con qualsiasi tecnologia di oggi, specialmente SQL Server.

Se non prevedi di avere un numero di utenti pari a Facebook (500 M), la maggior parte dei siti Web (rete Stack Overflow) è costruita su .Net e SQL Server.

Come strumento potresti essere in grado di utilizzare SQL Server, ma ricorda che i siti come Facebook non sono costruiti solo nella parte superiore di un database. Usano varie tecnologie per svolgere l'attività, controlla i video di Yahoo per scoprire come Facebook gestisce i log da solo e ti accorgerai che DB è solo una parte dell'enorme architettura scalabile. A circa 10000 righe di aggiornamento al secondo ho visto sia SQL Server che Oracle DB essere molto lenti dopo alcuni giorni su una buona macchina di configurazione. Il mio problema è che non potevo usare il calcolo distribuito. Pertanto è importante esaminare i sistemi di supporto che un DB o un'architettura scalabile può fornire.

Non posso rispondere per MySQL (!) Ma ho esperienza nel supportare i clienti che scegliamo se usare SQLServer o Oracle. Finora, abbiamo scoperto che generalmente non c'è alcuna differenza tra loro, ma quando le cose arrivano al limite, Oracle è di gran lunga il prodotto migliore. Ad esempio, stiamo attualmente eliminando il nostro sistema mission-critical 24 ore su 24, 7 giorni su 7, per eliminare un carico di record dal momento che SQL Server ha deciso che ci sarebbero volute molte ore per eseguire questa attività durante l'esecuzione (in un ambiente con mirroring). Abbiamo riscontrato problemi con il log shipping di un set di dati di grandi dimensioni attraverso un collegamento WAN che non è mai stato del tutto risolto. Cose come queste ci rendono sempre felici di supportare i clienti che girano su Oracle, dove non abbiamo mai avuto problemi del genere.

Quindi, se stai cercando un sistema altamente scalabile, è allora che è probabile che tu trovi questi problemi. Oracle è noioso, difficile e fastidioso, ma funziona davvero.