Guida all'architettura di SQL Server

Question

Stiamo progettando una nuova versione del nostro prodotto esistente su un nuovo schema. È un'applicazione Web interna con possibilmente 100 utenti simultanei (max) Questa verrà eseguita su un database SQL Server 2008.

Uno degli argomenti di discussione è se dovremmo avere un singolo database di suddivisione del database per motivi di prestazioni su 2 database separati.

Il database potrebbe crescere ovunque da 50-100 GB su 5 anni.

Siamo sviluppatori e non DBA quindi sarebbe bello avere una guida generale.

[So che la risposta non è semplice, in quanto dipende lo schema, la politica, la quantità di dati di archiviazione, ecc]

Opzione 1 Main unico database [Questa è la mia opzione preferita].

Il piano consisterebbe nell'avere tutte le tabelle in un singolo database e possibilmente utilizzare i gruppi di file e il partizionamento per separare i dati se richiesto su più dischi. [Usa lo schema se appropriato]. Questo dovrebbe riguardare i problemi di prestazioni Uno dei commenti di questo era che un'istanza di un singolo server avrebbe ancora elaborato questi dati, quindi ci sarebbe ancora un collo di bottiglia di elaborazione.

Per la segnalazione potremmo avere un DB di report separato, ma questo è ancora in discussione.

Opzione 2 dividere il database in 2 database separati

DB1 - Clienti, Conti, risorse del cliente ecc

DB2 - Ciò contenere la maggior parte dei dati [vale a dire Dati di tracciamento del veicolo, tabelle di transazioni finanziarie ecc.].

Queste tabelle in genere contengono molti dati. [Potrebbe risiedere su un server separato, se necessario]

Questo piano comporterebbe il mantenimento dei dati principali in un database più piccolo [DB1] e il mantenimento dei dati di tipo di transazione [principalmente] di sola lettura in un DB [DB2] separato. L'interfaccia utente leggerà principalmente da DB1 e quindi sarà più reattivo. [Sono consapevole che questa opzione rende più difficile per l'integrità referenziale da eseguire.]

Punti per conto Dato che siamo in fase di progettazione possiamo almeno fare un uso corretto degli indici per affrontare i problemi di prestazioni di modo che è perché l'opzione 1 per me è attraente e il suo approccio più standard. Per entrambe le opzioni stiamo considerando l'implementazione di un database di archiviazione.

Scuse per la lunga domanda. In sintesi la domanda è 1 DB o 2?

Grazie in anticipo,

Liam

Answer 1

Opzione 1 a mio parere è la strada da percorrere.

CPU è molto improbabile che sia il collo di bottiglia con 100 utenti simultanei che forniscono il carico di lavoro.È possibile acquistare un singolo server multi-socket con capacità CPU aggiuntiva disponibile tramite la tecnologia hot swap per offrire spazio di crescita, se lo si desidera. In base ai requisiti di disponibilità, è possibile anche considerare l'utilizzo di una soluzione di clustering per consentire lo swapping in più risorse CPU di elaborazione mediante fail forzato su un altro nodo.

Le prestazioni del sottosistema del disco saranno la vostra principale preoccupazione. Le tue decisioni di progettazione saranno influenzate dalla soluzione di archiviazione che utilizzi, che presumo sarà la tecnologia SAN.

Come minimo è necessario posizionare i file LOG (RAID 1) e DATA (RAID 10 o 5 dipendenti dal carico di lavoro) su LUN separati.

A seconda del proprio accesso alla tabella, si potrebbe prendere in considerazione la possibilità di inserire Filegroup diversi su LUN separate. Il partizionamento dei dati della tabella potrebbe rivelarsi vantaggioso per te, ma solo per tabelle di grandi dimensioni.

Answer 2

Da 50 a 100 GB e 100 utenti è un database piuttosto piccolo rispetto alla maggior parte degli standard oggi. Non sovraintendere la tua soluzione cercando di risolvere problemi che non hai ancora visto. La suddivisione in due database, in particolare su due server diversi creerà una montagna di mal di testa che faresti meglio senza. Concentra invece i tuoi sforzi sulla creazione di un prodotto utile.

Answer 3

Accetto gli altri commenti affermando che tra 50 e 100 GB è piccolo in questi giorni. Anch'io sono d'accordo sul fatto che non dovresti sovrastimolare.

Ma, se esiste una separazione logica ovvia (o non così ovvia) tra le entità che si memorizzano (come si dice, una in lettura-scrittura e le altre parti principalmente di sola lettura), lo dividerei comunque in diverse dbs. Almeno lo progetterei in un modo che potrei facilmente calcolare un pezzo. La sicurezza sarebbe una delle ragioni, gestione/backup/ripristino di un'altra facilità di manutenzione (perché intrinsecamente il design sarà meglio fattorizzato e le parti meglio isolate l'una dall'altra) e, in SQL Server, la capacità di scalare (o la sua mancanza se è un singolo database). Separare i database di login e di contenuto, ad esempio, ha spesso senso per le applicazioni Web più grandi.

E, se si desidera realmente un progetto audio, separare le entità in un singolo db, utilizzando schemi diversi, mettendo le autorizzazioni appropriate sugli oggetti, si finisce con lo stesso sforzo nei miei occhi.

I prodotti Microsoft come SharePoint, TFS e BizTalk utilizzano tutti diversi database (anche se non pretendo di essere a conoscenza dei motivi/probabilmente solo del risultato del modo in cui organizzano i loro team).

Soprattutto per quanto riguarda il fatto che non è possibile scalare una singola istanza di database su SQL Server (il clustering ha bisogno di più istanze), sarei tentato di dividerlo.

@John: Vorrei mai utilizzare RAID5. Risolve uno scopo diverso dal danneggiare le prestazioni. Sono d'accordo con l'approccio RAID10.

Answer 4

Inserire dati in un altro database non farà la minima differenza in termini di prestazioni. Le prestazioni sono un fattore di altre cose interamente.

Un motivo per creare un nuovo database è per motivi di manutenzione e amministrazione. Ad esempio, se un set di dati richiede una politica di backup e ripristino diversa o ha requisiti di disponibilità più elevati.