SQL SERVER e Performance con molte tabelle

lunedì 25 giugno 2012 - 12.38

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags SQL Server 2008 R2 | SQL Server 2008 | SQL Server 2005 | SQL Server 2000 | SQL Server Express

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: lun 25 giu 2012 - 12:38

Qualcuno ha riferimenti o conoscenza su come degradano le prestazioni di Microsoft SQL Server al crescere del numero di tabelle?

La domanda che mi sto ponendo è la seguente:

Mi conviene gestire un'unica tabella da 30.000.000 righe usando il partizionamento e gli indici (lasciando fare tutto a sql) oppure aiutarlo spezzando la tabellona in 300 tabelle da 100.000 righe e poi costruendoci gli indici sopra?

Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/
http://yadamp.unisa.it/ - YADAMP CMS -

dinoxet Profilo | Senior Member

484 messaggi | Data Invio: lun 25 giu 2012 - 12:48

A mio avviso meglio un unica tabella partizionata che 100 tabelle anche se ben indicizzate.

SQL ha una discreta gestione delle tabelle partizionate non a livello di oracle ma quasi ...

DINOXET
__________________________________________
impossible is only a word

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: lun 25 giu 2012 - 13:49

quindi mi consigli di rifarmi sempre e comunque alle partizioni...
la gestione di come utilizzarle poi è affidata al motore sql giusto?

la mia perplessità nasceva da quest'ulteriore domanda:

se io mantengo X partizioni della tabellona... e magari un sottoinsieme Y è usato molto più spesso rispetto a un insieme Z ... SQL ottimizza la partizione per restituire i risultati più velocemente quando vengono effettuate query che coinvolgono X?

Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/
http://yadamp.unisa.it/ - YADAMP CMS -

dinoxet Profilo | Senior Member

484 messaggi | Data Invio: lun 25 giu 2012 - 14:05

Se hai dei sottoinsiemi diciamo Y che vengono maggiormente interrogati perchè non fare delle viste materializzate,
che trattandole appunto come tabelle le puoi ottimizzare al meglio...

DINOXET
__________________________________________
impossible is only a word

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: lun 25 giu 2012 - 14:08

>perchè non fare delle viste materializzate,
mi spieghi un po' meglio?
non sono pratico di SQL ... mi fermo ai classici create table, alter index ... ;(
Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/
http://yadamp.unisa.it/ - YADAMP CMS -

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 25 giu 2012 - 15:24

Ciao,
intervengo solo per dare maggiori info

>quindi mi consigli di rifarmi sempre e comunque alle partizioni...
>la gestione di come utilizzarle poi è affidata al motore sql giusto?
considera che le partizioni sono gestite da una partition function che fa da smistatore delle richieste, e, in base alla chiave che passi per cercare, si occupa di considerare solamente le partizioni interessate.
Ovvio che fare query cross partizione è più pesante che rendere le ricerche mutualmente esclusive. Se puoi cerca di isolare sottoinsiemi in modo tale per cui le ricerche vanno solo su una partizione.

>Se hai dei sottoinsiemi diciamo Y che vengono maggiormente interrogati
>perchè non fare delle viste materializzate,
>che trattandole appunto come tabelle le puoi ottimizzare al meglio...
il problema qui potrebbe essere il fatto che ci perdi in termini di parallelizzazione. Poi ovviamente dipende sempre dal tipo di accesso che hai, se le partizioni diciamo "vecchie" diventano readonly, mi piace di più utilizzare le partizioni perchè puoi fare un filegroup per ogni partizione in maniera più semplice e quindi poi gestire i backup su filegroup in maniera piuttosto elastica. Se invece continui a scrivere molto e le partizioni diventano tante, beh, in quel caso ogni soluzione è da provare, per vedere quale strada è la migliore. Dipende sempre tutto dal caso reale. E dall'hardware che hai sotto, io su certe tabelle ho centinaia di milioni di record, e mi basta un buon indice (o più di uno) ben manutenuto per tenere sempre buone le prestazioni. Ma ho anche un server molto carrozzato.
Dipende da tante cose. In ambito di alta disponibilità potresti anche pensare a database federati, ovvero viste partizionate, ma ripeto, andrebbe analizzato molto bene il caso reale.
In un ambiente di test riesci a fare qualche prova con ogni metodo suggerito?
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: lun 6 ago 2012 - 17:10

>Ciao,
>intervengo solo per dare maggiori info
Ciao e grazie per la risposta così ben strutturata.

>>quindi mi consigli di rifarmi sempre e comunque alle partizioni...
>>la gestione di come utilizzarle poi è affidata al motore sql giusto?
>considera che le partizioni sono gestite da una partition function
>che fa da smistatore delle richieste, e, in base alla chiave
>che passi per cercare, si occupa di considerare solamente le
>partizioni interessate.
Fin qui mi sembra ottimo per quello che voglio fare...
(anche se la funzione di smistamento è u collo di bottiglia per come è descritta...) ??

>Ovvio che fare query cross partizione è più pesante che rendere
>le ricerche mutualmente esclusive. Se puoi cerca di isolare sottoinsiemi
>in modo tale per cui le ricerche vanno solo su una partizione.
E questo vincolo e soddisfatto... nessun join e nessun accesso fuori la partizione...
farei una suddivisione per "anni" quindi tutto sarebbe confinato nel range 200x0101 20xx1231

>>Se hai dei sottoinsiemi diciamo Y che vengono maggiormente interrogati
>>perchè non fare delle viste materializzate,
>>che trattandole appunto come tabelle le puoi ottimizzare al meglio...
Non conosco nessun concetto di quelli espressi ;) dovresti definirmi vista materializzata
(se non si tratta di una vista standard)

>il problema qui potrebbe essere il fatto che ci perdi in termini
>di parallelizzazione.
Perchè?

>Poi ovviamente dipende sempre dal tipo
>di accesso che hai, se le partizioni diciamo "vecchie" diventano
>readonly, mi piace di più utilizzare le partizioni perchè puoi
>fare un filegroup per ogni partizione in maniera più semplice
mi ero dimenticato di dire all'inizio che i dati che volevo partizionare (o suddividere in db) sono totalmente readonly

>Dipende da tante cose. In ambito di alta disponibilità potresti
>anche pensare a database federati, ovvero viste partizionate,
>ma ripeto, andrebbe analizzato molto bene il caso reale.
>In un ambiente di test riesci a fare qualche prova con ogni metodo
>suggerito?
Purtroppo no... avevano urgenza di alleggerire i db principale e "al momento" ho partizionato a mano in database diversi ma come soluzione mi sembra troppo "sporca"

>--
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://www.alessandroalpi.net
>http://blogs.dotnethell.it/suxstellino
>http://mvp.microsoft.com/profiles/Alessandro.Alpi

Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/
http://yadamp.unisa.it/ - YADAMP CMS -

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 8 ago 2012 - 14:24

>Fin qui mi sembra ottimo per quello che voglio fare...
>(anche se la funzione di smistamento è u collo di bottiglia per
>come è descritta...) ??
No, diciamo che perdi qualcosina nelle operazioni, perchè un livello si deve occupare di capire in che partizione devi andare a parare. Ma non dovresti avere problemi, soprattutto se il server è messo bene.
L'unica è provare e valutare l'impatto secondo le operazioni che devi fare. Dipende sempre dal traffico che poi hai sulle tabelle, non esiste una regola, anche perchè se il partizionamento ti risolve il problema, qualche microsecondo lo puoi perdere

>E questo vincolo e soddisfatto... nessun join e nessun accesso
>fuori la partizione...
>farei una suddivisione per "anni" quindi tutto sarebbe confinato
>nel range 200x0101 20xx1231
allora in effetti la partizione potrebbe veramente aiutarti tanto.

>Non conosco nessun concetto di quelli espressi ;) dovresti definirmi
>vista materializzata (se non si tratta di una vista standard)
è una vista con un indice clustered creato che consente di persisterla come una tabella, avendo uno schema bound con gli oggetti che la formano.

>>il problema qui potrebbe essere il fatto che ci perdi in termini
>>di parallelizzazione.
>Perchè?
perchè se interroghi distintamente i dati, la parallelizzazione è meglio che interrogare una vista indicizzata che sta solo in un posto.

>mi ero dimenticato di dire all'inizio che i dati che volevo partizionare
>(o suddividere in db) sono totalmente readonly
ok allora puoi anche fare più database ed una vista "federata" che punta a più tabelle di più database. Ma qui perdi in leggibilità e manutenzione. Essendoci le partizioni, ragionerei in quel senso se la tua licenza sql te lo consente.

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

luigidibiasi Profilo | Guru

1.077 messaggi | Data Invio: mer 8 ago 2012 - 17:13

Generosissimo e chiarissimo.
Grazie

Luigi Di Biasi

http://www.dibiasi.it/
http://netsell.dibiasi.it - ecomm software -
http://blogs.dotnethell.it/luigidibiasi/
http://yadamp.unisa.it/ - YADAMP CMS -

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !