Qual è il modo migliore per gestire un gran numero di tabelle in MS SQL Server?

Question

Questa domanda è collegata ad un'altra:
Avere più filegroup aiuterà ad accelerare il mio database?

Il software che stiamo sviluppando è uno strumento analitico che utilizza MS SQL Server 2005 per archiviare i dati relazionali. L'analisi iniziale può essere lenta (poiché stiamo elaborando milioni o miliardi di righe di dati), ma ci sono requisiti prestazionali nel richiamare rapidamente le analisi precedenti, quindi "risparmiamo". risultati di ciascuna analisi.

Il nostro approccio attuale è quello di salvare i risultati dell'analisi in una serie di "quotazioni specifiche" tabelle e l'analisi è abbastanza complessa da poter arrivare a 100 tabelle per analisi. Di solito queste tabelle consumano circa duecento MB per analisi (che è piccola rispetto alle nostre centinaia di GB, o talvolta a TB multipli, di dati di origine). Ma nel complesso, lo spazio su disco non è un problema per noi. Ogni set di tabelle è specifico di un'analisi e in molti casi ciò ci fornisce enormi miglioramenti delle prestazioni rispetto al riferimento ai dati di origine.

L'approccio inizia a fallire una volta accumulati abbastanza risultati di analisi salvati - prima di aggiungere una più solida capacità di archiviazione / pulizia, il nostro database di test è salito a diversi milioni . Ma non è un tratto per noi avere più di 100.000 tavoli, anche in produzione. Microsoft pone un limite teorico piuttosto grande sulla dimensione degli oggetti di sistema (~ 2 miliardi), ma una volta che il nostro database supera i 100.000 o giù di lì, semplici query come CREATE TABLE e DROP TABLE possono rallentare notevolmente.

Abbiamo un po 'di spazio per discutere il nostro approccio, ma penso che potrebbe essere difficile farlo senza più contesto, quindi voglio porre la domanda più in generale: se siamo costretti a creare così tanti tavoli, qual è il migliore approccio per gestirli? Filegroup multipli? Schemi / proprietari multipli? Database multipli?

Un'altra nota: non sono elettrizzato all'idea di "semplicemente lanciare l'hardware al problema" (ad es. aggiunta di RAM, potenza della CPU, velocità del disco). Ma non lo escluderemo neanche, soprattutto se (per esempio) qualcuno può dirci definitivamente quale effetto avrà l'aggiunta di RAM o l'utilizzo di più filegroup sulla gestione di un grande catalogo di sistema.

Answer 1

Abbiamo finito per suddividere il nostro database in più database. Quindi il database principale contiene un "database" tabella che fa riferimento a una o più "run" database, ognuno dei quali contiene serie distinte di risultati dell'analisi. Quindi il principale "esegui" tabella contiene un ID database e il codice che recupera un risultato salvato include il prefisso del database pertinente su tutte le query.

Questo approccio consente al catalogo di sistema di ciascun database di essere più ragionevole, fornisce una migliore separazione tra le tabelle core / permanenti e le tabelle dinamiche / di esecuzione e rende inoltre più gestibili i backup e l'archiviazione. Ci consente anche di dividere i nostri dati su più dischi fisici, anche se lo avrebbe fatto anche l'uso di più filegroup. Nel complesso, sta funzionando bene per noi, dati i nostri attuali requisiti e, in base alla crescita prevista, riteniamo che ridimensionerà bene anche per noi.

Abbiamo anche notato che SQL 2008 tende a gestire grandi cataloghi di sistema meglio di SQL 2000 e SQL 2005. (Non abbiamo effettuato l'aggiornamento al 2008 quando ho pubblicato questa domanda.)

Answer 2

Senza prima vedere l'intero sistema, la mia prima raccomandazione sarebbe quella di salvare le esecuzioni storiche in tabelle combinate con un RunID come parte della chiave - un modello dimensionale potrebbe anche essere rilevante qui. Questa tabella può essere partizionata per migliorare, il che ti permetterà anche di dividere la tabella in altri filegroup.

Un'altra possibilità è quella di mettere ogni esecuzione nel proprio database e quindi staccarli, collegandoli solo se necessario (e in forma di sola lettura)

CREATE TABLE e DROP TABLE probabilmente funzionano male perché i database master o modello non sono ottimizzati per questo tipo di comportamento.

Consiglio anche di parlare con Microsoft della scelta del design del database.

Answer 3

Le tabelle sono tutte strutture diverse? Se hanno la stessa struttura potresti cavartela con una singola tabella partizionata.

Se si tratta di strutture diverse, ma solo sottoinsiemi dello stesso insieme di colonne di dimensioni, è comunque possibile memorizzarle in partizioni nella stessa tabella con valori nulli nelle colonne non applicabili.

Se questo è analitico (forse calcoli dei prezzi derivati?) potresti scaricare i risultati di una corsa di calcolo in file flat e riutilizzare i tuoi calcoli caricando dai file flat.

Answer 4

Questo sembra essere un problema / applicazione molto interessante con cui stai lavorando. Mi piacerebbe lavorare su qualcosa del genere. :)

Hai una grande area problematica e questo rende difficile iniziare ad aiutare. Esistono diversi parametri di soluzione che non sono evidenti nel tuo post. Ad esempio, per quanto tempo si prevede di mantenere le tabelle di analisi della corsa? Ci sono MOLTE altre domande che devono essere poste.

Avrai bisogno di una combinazione di data warehousing serio e partizionamento di dati / tabelle. A seconda della quantità di dati che desideri conservare e archiviare, potresti dover iniziare a de-normalizzare e appiattire le tabelle.

Questo sarebbe piuttosto un caso in cui contattare direttamente Microsoft può essere reciprocamente vantaggioso. Microsoft ottiene un buon caso per mostrare agli altri clienti e ottenere assistenza direttamente dal fornitore.