Voglio gestire un set di dati di grandi dimensioni (> 1 miliardo di righe) in SQL Server 2008 R2. Ho sentito che se si imposta "partizionamento" o "partizionamento orizzontale", rende più veloce la gestione di set di dati di grandi dimensioni in quanto suddivide le tabelle in più file.
Hai mai usato il partizionamento o il partizionamento orizzontale prima? In tal caso, potresti suggerire degli schemi che, nella tua esperienza, ottengono risultati migliori rispetto a un unico tavolo massiccio?
Risposte:
Innanzitutto, si noti che 1 miliardo di righe può essere gestita in modo efficace con un'architettura partizionata su un normale hardware server di prodotti. Non saranno necessarie architetture esotiche condivise per questo volume di dati, tuttavia, probabilmente otterrai vantaggi significativi dal partizionamento delle tabelle.
La frammentazione è qualcosa di diverso dal partizionamento orizzontale e implica un'architettura di "nulla condiviso", che non è supportata dalla maggior parte delle versioni di SQL Server 1
SQL Server può supportare il partizionamento orizzontale e un'architettura del disco condivisa sarà adeguata per ~ 1 miliardo di righe.
In SQL Server, si crea una funzione di partizione che seleziona una partizione in base a valori o intervalli di valori in una colonna di una tabella, ad es
create partition function F_AccPrdPart (int)
as range left for values (
180001 -- Dummy value
,199012 ,199112 ,199212 ,199312, 199412 ,199512
,199612 ,199712 ,199812 ,199912 ,200012 ,200112
,200212 ,200312 ,200412 ,200512 ,200612 ,200712
,200812
,200901, 200902, 200903, 200904, 200905, 200906
,200907, 200908, 200909, 200910, 200911, 200912
,201001, 201002, 201003, 201004, 201005, 201006
,201007, 201008, 201009, 201010, 201011, 201012
,201101, 201102, 201103, 201104, 201105, 201106
,201107, 201108, 201109, 201110, 201111, 201112
,202012
,939999 -- Dummy value
)
goQuindi creare uno o più filegroup a cui assegnare le partizioni. Per un set di dati di grandi dimensioni, questi gruppi di file potrebbero essere impostati su diversi volumi fisici. Si noti che lo storage con collegamento diretto sarà molto più veloce di una SAN per questo in quasi tutti i casi. Nell'esempio seguente, avremmo creato 6 filegroup chiamati PartVol1-PartVol6.
Uno o più schemi di partizione possono essere creati per allocare partizioni di tabelle a filegroup in base al valore della funzione di partizione, ad es
create partition S_AccPrdPart as partition F_AccPrdPart
TO ([PRIMARY]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2]
,[PRIMARY]
,[PRIMARY])
goQuesto schema è progettato per partizionare in un periodo contabile. Anche le date sono usate frequentemente per questo, sebbene ogni chiave potrebbe essere usata.
È possibile creare una tabella sullo schema di partizione come se fosse un filegroup, ad es
Create table FooTrans (
FooTransID int identity (1,1) not null
,AccPeriod int not null
,[...]
) on S_AccPrdPart (AccPeriod)
goSi noti che la tabella viene creata sullo schema di partizione anziché su un gruppo di file specificato e la clausola specifica la colonna da utilizzare come chiave di partizione. In base alla chiave di partizione, le righe nella tabella verranno assegnate a uno dei filegroup nello schema di partizione.
Nota: una regola empirica per la progettazione di uno schema di partizionamento è che ogni partizione dovrebbe avere un conteggio delle righe tra i 10 di milioni bassi, diciamo tra 10 e 50 milioni a seconda della larghezza delle righe. Il volume del disco su cui si trova la partizione dovrebbe essere abbastanza veloce da eseguire una scansione di almeno una singola partizione in pochi secondi.
Sistemi di partizionamento, frammentazione e nulla condiviso
Un po 'di terminologia sembra al fine di chiarire alcune delle discussioni su questo argomento.
Un sistema "nulla condiviso" è un sistema parallelo in cui i nodi non dispongono di memoria SAN condivisa, ma utilizzano la memoria locale per il nodo. Il classico esempio di questo tipo di architettura è Teradata. I sistemi non condivisi non si adattano bene a set di dati molto grandi in quanto non hanno colli di bottiglia nell'I / O centrale. Il throughput I / O viene ridimensionato con il numero di nodi nel sistema.
Un sistema a "disco condiviso" è uno in cui uno o più server di database condividono un singolo sottosistema di archiviazione su disco. Il database può essere un singolo server con memoria locale o collegato a una SAN o un cluster di server collegati a una SAN condivisa. Sistemi di questo tipo sono vincolati dalla velocità effettiva disponibile dal sottosistema di archiviazione.
"Frammentazione" è un termine usato per descrivere la suddivisione di un database tra più server fisici in un'architettura nulla condivisa. Diverse piattaforme avranno un supporto maggiore o minore per database frammentati. Nei circoli di Teradata, il termine non viene utilizzato perché Teradata presenta ai client un'immagine trasparente a singolo sistema, anche se l'architettura fisica non è un tipo condiviso.
Le versioni precedenti di SQL Server hanno un supporto limitato per il sharding attraverso viste partizionate distribuite. Microsoft ora crea una versione di SQL Server 2008 R2 che supporta un'architettura nulla condivisa con una singola immagine di sistema, ma questa versione è disponibile solo per gli OEM e può essere acquistata solo in un pacchetto hardware.
Per 1 miliardo di file
Per 1 miliardo di file (a meno che le singole file non siano estremamente larghe) un nulla condiviso o un'architettura frammentata è comodamente nel regno dell'eccesso. Questo tipo di volume può essere gestito su un singolo server con specifiche ragionevoli se ha un sottosistema del disco sufficientemente veloce.
Il disco di collegamento diretto locale è di gran lunga il più conveniente in termini di prezzo per le prestazioni. Un singolo controller RAID SAS può accettare più array e più controller possono essere installati in un server. A seconda della configurazione, un moderno array SAS da 24-25 slot può trasmettere migliaia di IOPS o 1 GB + / sec in prestazioni di streaming; un server con più bus PCI-e e più controller può teoricamente gestirne di più.
Il tipo di prestazioni necessarie per lavorare con un database da 1 miliardo di righe può essere ottenuto in modo abbastanza semplice ed economico con l'hardware del server delle materie prime e lo storage con collegamento diretto di questo tipo. È possibile utilizzare anche una SAN, ma potrebbero essere necessari più controller SAN per ottenere prestazioni equivalenti e è probabile che l'hardware sia un ordine di grandezza più costoso.
Come raccomandazione generale, utilizzare l'archiviazione con collegamento diretto per applicazioni con requisiti di I / O pesanti a meno che non sia necessario un buon tempo di attività. Gli errori di controllo della configurazione e delle modifiche sono una fonte molto più grande di tempi di inattività non programmati rispetto ai guasti hardware nei moderni data center.
Le SAN possono offrire una piattaforma di archiviazione più gestibile se si dispone di un ampio portafoglio di applicazioni in quanto offrono una gamma di strutture di gestione dello storage centralizzate. Tuttavia, questo ha un prezzo elevato e ottenere prestazioni elevate dall'infrastruttura basata su SAN è difficile e costoso.
1 Microsoft crea una versione parallela di SQL Server, ma è disponibile solo tramite canali OEM in bundle con l'hardware. Le versioni disponibili immediatamente non supportano questa funzionalità.