Tabele și indexuri partiționate

Partiționarea de tabele sau indexuri mari poate oferi următoarele avantaje în ceea ce privește gestionarea și performanța.

Aceasta vă permite să transferați rapid și eficient subseturi de date și să le accesați, păstrând în același timp integritatea setului de date. De exemplu, o operație, cum ar fi încărcarea datelor din OLTP într-un sistem OLAP, se efectuează în câteva secunde, nu în minute și ore, ca în cazul datelor nepartiționate.







Operațiile de întreținere pot fi efectuate mai rapid cu una sau mai multe secțiuni. Operațiile sunt mai eficiente, deoarece ele sunt efectuate numai cu subseturi de date, și nu cu întreaga masă. De exemplu, puteți comprima datele într-una sau mai multe secțiuni sau puteți reconstrui una sau mai multe secțiuni ale indexului.

Puteți îmbunătăți viteza executării interogării, în funcție de interogările care sunt adesea efectuate în configurația hardware. De exemplu, optimizatorul de interogări poate efectua rapid interogări la egi-join-ul a două sau mai multe tabele partiționate dacă aceleași coloane de partiționare se află în aceste tabele, deoarece puteți să vă alăturați secțiunilor.

La sortarea datelor pentru operațiile I / O SQL Server, mai întâi, datele sunt sortate după secțiune. SQL Server poate accesa un singur disc la un moment dat, ceea ce poate degrada performanța. Pentru a accelera sortarea datelor, este recomandat să distribuiți fișierele de date în secțiuni pe mai multe hard disk-uri, creând RAID. Astfel, deși datele sunt sortate pe secțiuni, SQL Server poate accesa simultan toate hard-discurile fiecărei partiții.

În plus, puteți îmbunătăți performanța prin aplicarea de încuietori la nivel de secțiune, mai degrabă decât întregul tabel. Acest lucru poate reduce numărul de conflicte de blocare pentru tabel.

Următorii termeni se aplică partiționării tabelelor și indexurilor.

Un obiect de bază de date care determină distribuirea rândurilor de tabele sau indexuri pe secțiuni pe baza valorilor anumitor coloane, numite coloane de partiționare. Aceasta înseamnă că funcția de partiție determină numărul de partiții din tabel și modul în care vor fi definite limitele partițiilor. De exemplu, un tabel care conține date de comandă de vânzări poate necesita divizarea tabelului în 12 secțiuni lunare, pe baza valorilor coloanei datetime. de exemplu după data vânzării.

Un obiect de bază de date care săruri secțiuni ale funcției de partiție la un set de grupuri de fișiere. Principalul motiv pentru care secțiunile sunt împărțite în diferite grupuri de fișiere este nevoia de backup independent a acestor partiții, deoarece este întotdeauna efectuată separat pentru fiecare grup de fișiere.

Coloana din tabel sau indexul utilizat de funcția de partiție pentru a împărți tabelul sau indexul. Coloanele calculate care participă la funcția de partiție trebuie să fie marcate în mod explicit ca PERSISTED. Toate tipurile de date care sunt valabile pentru a fi utilizate ca coloane index pot fi folosite ca coloane de partiționare, cu excepția timestampului. Tipurile de date Ntext nu pot fi specificate. text. imagine. XML. varchar (max). nvarchar (max) și varbinar (max). De asemenea, nu puteți specifica un tip de date definit de utilizator pentru CLR și coloane Microsoft .NET Framework pentru tipul de date alias.

Un index creat pe baza aceleiași scheme de partiționare ca și tabelul corespunzător. Dacă tabela și indexurile acesteia sunt aliniate, SQL Server poate trece rapid dintr-o secțiune la alta, păstrând în același timp structura de partiție atât a tabelului, cât și a indexurilor acestuia. Pentru alinierea la tabela de bază, indexul nu trebuie să utilizeze funcția de partiție cu același nume. Cu toate acestea, nici o funcție trebuie să partiție tabelul index și baza variază semnificativ, adică 1) argumentele funcției de partiție trebuie să aibă același tip de date, 2), funcțiile trebuie să definească același număr de secțiuni și 3) funcția trebuie să stabilească pentru secțiunile aceleași valori limită.

Indicele este împărțit independent de tabelul corespunzător. Adică, indexul are o schemă de partiționare diferită sau nu se află în grupul de fișiere unde se află masa de bază. Crearea unui indice partajat neparticipat poate fi util în următoarele cazuri:







Tabela de bază nu este divizată.

Cheia index este unică și nu conține o coloană de partiționare a tabelului.

Tabela de bază este necesară pentru a participa la asocierea aliniată cu tabelele care utilizează alte coloane de cuplare.

Procesul în care optimizatorul de interogări accesează numai anumite secțiuni în conformitate cu filtrul de interogare.

Un nou număr maxim de secțiuni (15.000) afectează memoria, operațiile indexului partiționat, comenzile DBCC și interogările. Această secțiune arată modul în care performanța afectează crearea a mai mult de 1.000 de secțiuni și cum se pot rezolva problemele. Creșterea numărului maxim de secțiuni la 15 000 vă permite să stocați date mai mult. Cu toate acestea, este recomandat să stocați datele exact cât timp este necesar și să mențineți un echilibru între performanță și numărul de secțiuni.

Utilizarea memoriei și recomandările

Cu un număr mare de partiții utilizate, se recomandă utilizarea a cel puțin 16 GB de memorie RAM. Dacă sistemul nu are suficientă memorie, instrucțiunile Limbaj de procesare a datelor (DML), instrucțiunile DDL (Language Definition Language) și alte operații pot eșua din cauza lipsei de memorie. În sistemele cu memorie RAM de 16 GB și un număr mare de procese care utilizează intensiv memoria, operațiile care operează pe un număr mare de secțiuni pot eșua din cauza lipsei de memorie. Prin urmare, cu cât aveți mai multă memorie de peste 16 GB, cu atât este mai puțin probabil să aveți o problemă cu performanța și memoria.

Limitările RAM pot afecta performanța sau capacitatea de a crea un index partiționat. Acest lucru se întâmplă, de exemplu, când indicele nu este aliniat la tabela de bază sau la indexul grupat, dacă există în tabel.

Operațiuni cu indexuri partajate

Limitările RAM pot afecta performanța sau capacitatea de a crea un index partiționat. Acest lucru este valabil mai ales pentru indicii nealiniate. Crearea și reconstruirea indexurilor nealiniate pentru un tabel cu un număr de secțiuni mai mari de 1000 este posibilă, dar nu este acceptată. Acest lucru poate duce la degradarea performanțelor sau la consumul excesiv de memorie în timpul acestor operațiuni.

Crearea și rearanjarea indexurilor aliniate poate dura mai mult timp când crește numărul de secțiuni. Nu este recomandat să executați mai multe comenzi pentru crearea și reconstrucția indexului în același timp, deoarece există probleme de performanță și de memorie.

Atunci când o componentă SQL Server efectuează sortarea pentru a crea indexuri partiționate, mai întâi creează un tabel de sortare pentru fiecare secțiune. Apoi, creează tabele de sortare în grupul de fișiere corespunzător fiecărei secțiuni sau în tempdb. dacă este specificat parametrul SORT_IN_TEMPDB. Toate tabelele de sortare necesită o cantitate minimă de RAM. Atunci când se construiește un index partiționat, aliniat la tabela de bază, tabelele de sortare sunt create unul câte unul, economisind dinamic din memorie. Cu toate acestea, atunci când creați un index nepartiționat partajat, tabelele sunt create în același timp. Ca rezultat, aveți nevoie de o cantitate suficientă de memorie RAM pentru a le procesa în paralel. Cu cât este mai mare numărul de secțiuni, cu atât este necesară mai multă memorie RAM. Pentru fiecare secțiune, dimensiunea tabelului de sortare este de cel puțin 40 de pagini, câte 8 kilobyte fiecare. De exemplu, pentru un index nepartizat partiționat, împărțit în 100 de secțiuni, veți avea nevoie de cantitatea de RAM pentru sortarea simultană a 4 000 de pagini (40 * 100). Dacă această cantitate de memorie este disponibilă, operația de creare va reuși, dar performanța poate suferi. Dacă această cantitate de memorie nu este disponibilă, operația de construire va eșua. Pentru un index aliniat partiționat împărțit în 100 de secțiuni, sunt necesare doar 40 de pagini pentru sortare, deoarece sortarea nu este efectuată simultan.

Atât pentru indexurile aliniate cât și pentru cele nealiniate, este posibil să aveți nevoie de mai mult RAM dacă SQL Server utilizează gradul de paralelism pentru operația de creare pe un computer multiprocesor. Cu cât gradul de paralelism este mai mare, cu atât este nevoie de mai mult RAM. De exemplu, dacă SQL Server stabilește gradul de paralelism la 4, atunci un indice nealiniat partiționat cu 100 de secțiuni va necesita multă memorie, astfel încât patru procesoare să poată sorta simultan 4000 de pagini, adică 16000 de pagini. Dacă indexul partiționat este aliniat, cerințele RAM sunt reduse la 40 de pagini pentru fiecare dintre cele patru procesoare, adică 160 de pagini (4 * 40). Utilizând parametrul index MAXDOP, puteți reduce manual gradul de paralelism.

Comenzile DBCC

Cu mai multe secțiuni, execuția comenzilor DBCC poate dura mai mult pe măsură ce crește numărul de secțiuni.

Solicitările care utilizează funcția de eliminare a pieselor pot avea performanțe comparabile sau mai mari cu un număr mare de secțiuni. Întrebările care nu utilizează funcția de ștergere a secțiunilor pot dura mai mult cu creșterea numărului de secțiuni.

Să presupunem tabel are 100 de milioane de rânduri și coloane A. B și C. în exemplul din tabelul 1 este împărțit în 1000 secțiuni ale coloanei A. In exemplul din tabelul 2 este împărțit în secțiuni, în coloana 10,000 A. Tabelul Query cuprinde unde suma licitată filtrată prin coloană A. execută funcția de eliminare a secțiunilor și scanează o secțiune. Aceeași cerere se poate face mai rapid în Exemplul 2, deoarece mai puține linii în secțiunea de scanare. O interogare care include o clauză WHERE cu un filtru în coloana B va scana toate secțiunile. In exemplul 1, această cerere poate fi făcută mai rapid decât în ​​exemplul 2, deoarece, în acest caz, mai multe secțiuni pentru scanare.

Solicitările în care operatorii precum TOP sau MAX / MIN sunt utilizați pentru orice coloană, altele decât coloanele de partiționare, pot avea performanțe reduse atunci când se împarte, deoarece toate secțiunile trebuie să fie calculate.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: