SGBD orientat pe coloane - Column-oriented DBMS

Un SGBD orientat pe coloane sau SGBD pe coloane este un sistem de gestionare a bazelor de date (SGBD) care stochează tabele de date pe coloană mai degrabă decât pe rând. Utilizarea practică a unui magazin de coloane față de un magazin de rânduri diferă puțin în lumea SGBD relațională . Ambele baze de date coloane și rânduri pot utiliza limbaje tradiționale de interogare a bazelor de date, cum ar fi SQL, pentru a încărca date și a efectua interogări. Atât bazele de date rând, cât și coloanele pot deveni coloana vertebrală într-un sistem care servește date pentru instrumente comune de extragere, transformare, încărcare (ETL) și vizualizare a datelor . Cu toate acestea, prin stocarea datelor în coloane mai degrabă decât în ​​rânduri, baza de date poate accesa mai precis datele de care are nevoie pentru a răspunde la o interogare, mai degrabă decât scanarea și eliminarea datelor nedorite în rânduri.

Descriere

fundal

Un sistem de gestionare a bazelor de date relaționale oferă date care reprezintă un tabel bidimensional, de coloane și rânduri. De exemplu, o bază de date ar putea avea acest tabel:

RowId EmpId Nume Nume Salariu
001 10 Smith Joe 60000
002 12 Jones Maria 80000
003 11 Johnson Cathy 94000
004 22 Jones Bob 55000

Acest tabel simplu include un identificator de angajat (EmpId), câmpuri de nume (Prenume și Prenume) și un salariu (Salariu). Acest format bidimensional este o abstracție. Într-o implementare reală, hardware-ul de stocare necesită serializarea datelor într-o formă sau alta.

Cele mai scumpe operațiuni care implică hard disk sunt căutări . Pentru a îmbunătăți performanța generală, datele aferente ar trebui stocate într-un mod care să minimizeze numărul de căutări. Aceasta este cunoscută sub numele de localitate de referință , iar conceptul de bază apare în mai multe contexte diferite. Hard diskurile sunt organizate într-o serie de blocuri de dimensiuni fixe, suficient de obicei pentru a stoca mai multe rânduri ale tabelului. Prin organizarea datelor tabelului astfel încât rândurile să se încadreze în aceste blocuri și gruparea rândurilor aferente pe blocuri secvențiale, numărul blocurilor care trebuie citite sau căutate este minimizat în multe cazuri, împreună cu numărul de căutări.

Un sondaj realizat de Pinnecke și colab. acoperă tehnici de hibridizare coloană / rând începând cu 2017.

Sisteme orientate pe rânduri

O metodă obișnuită de stocare a unui tabel este serializarea fiecărui rând de date, astfel: 

001:10,Smith,Joe,60000;
002:12,Jones,Mary,80000;
003:11,Johnson,Cathy,94000;
004:22,Jones,Bob,55000;

Pe măsură ce datele sunt inserate în tabel, i se atribuie un ID intern, rowidcare este utilizat intern în sistem pentru a se referi la date. În acest caz, înregistrările au secvențiale rowidindependente de cele atribuite de utilizator empid. În acest exemplu, SGBD folosește numere întregi scurte pentru a stoca rowids. În practică, se utilizează în mod normal numere mai mari, pe 64 de biți sau pe 128 de biți.

Sistemele orientate pe rânduri sunt proiectate pentru a returna în mod eficient date pentru un rând întreg sau pentru a înregistra în cât mai puține operațiuni posibil. Aceasta se potrivește cu cazul de utilizare obișnuit în care sistemul încearcă să recupereze informații despre un anumit obiect, să spună informațiile de contact ale unui utilizator într-un sistem rolodex sau informațiile despre produs pentru un sistem de cumpărături online . Prin stocarea datelor înregistrării într-un singur bloc de pe disc, împreună cu înregistrările aferente, sistemul poate prelua rapid înregistrări cu un minim de operații pe disc.

Sistemele orientate pe rânduri nu sunt eficiente în efectuarea operațiunilor la nivelul întregului tabel, spre deosebire de un număr mic de înregistrări specifice. De exemplu, pentru a găsi toate înregistrările din tabelul de exemplu cu salarii între 40.000 și 50.000, SGBD ar trebui să scaneze complet prin întregul tabel în căutarea înregistrărilor potrivite. În timp ce exemplul de tabel prezentat mai sus se va potrivi într-un singur bloc de disc, un tabel cu chiar câteva sute de rânduri nu ar fi și ar fi necesare mai multe operații pe disc pentru a recupera datele și a le examina.

Pentru a îmbunătăți performanța acestor tipuri de operații (care sunt foarte frecvente și, în general, scopul utilizării unui SGBD), majoritatea SGBD acceptă utilizarea indexurilor bazei de date , care stochează toate valorile dintr-un set de coloane, împreună cu rowidindicatorii înapoi în tabel original. Un index din coloana salarială ar arăta cam așa: 

55000:004; 
60000:001;
80000:002;
94000:003;

Deoarece stochează doar date individuale, mai degrabă decât rânduri întregi, indexurile sunt în general mult mai mici decât magazinele principale de tabelă. Scanarea acestui set mai mic de date reduce numărul de operații pe disc. Dacă indexul este utilizat intens, poate reduce dramatic timpul pentru operațiuni obișnuite. Cu toate acestea, menținerea indexurilor adaugă cheltuieli generale sistemului, mai ales atunci când datele noi sunt scrise în baza de date. Înregistrările nu numai că trebuie stocate în tabelul principal, ci și orice index atașat trebuie actualizat.

Principalul motiv pentru care indicii îmbunătățesc dramatic performanța pe seturile de date mari este că indexurile bazelor de date de pe una sau mai multe coloane sunt de obicei sortate după valoare, ceea ce face ca operațiunile de interogare pe intervale (cum ar fi cele de mai sus, „găsiți toate înregistrările cu salarii între 40.000 și 50.000” de exemplu) rapid ( complexitate temporală mai mică ).

O serie de baze de date orientate pe rânduri sunt concepute pentru a se potrivi în întregime în RAM , o bază de date în memorie . Aceste sisteme nu depind de operațiile de pe disc și au acces în timp egal la întregul set de date. Acest lucru reduce nevoia de indexuri, deoarece necesită aceeași cantitate de operații pentru scanarea completă a datelor originale ca un index complet în scopuri de agregare tipice. Astfel de sisteme pot fi, prin urmare, mai simple și mai mici, dar pot gestiona numai baze de date care se vor potrivi în memorie.

Sisteme orientate pe coloane

O bază de date orientată pe coloane serializează toate valorile unei coloane împreună, apoi valorile coloanei următoare și așa mai departe. Pentru tabelul nostru de exemplu, datele vor fi stocate în acest mod: 

10:001,12:002,11:003,22:004;
Smith:001,Jones:002,Johnson:003,Jones:004;
Joe:001,Mary:002,Cathy:003,Bob:004;
60000:001,80000:002,94000:003,55000:004;

În acest aspect, oricare dintre coloane se potrivește mai bine cu structura unui index într-un sistem orientat pe rânduri. Acest lucru poate provoca confuzie care poate duce la convingerea greșită că un magazin orientat pe coloane „este într-adevăr” un magazin cu rânduri cu un index pe fiecare coloană. Cu toate acestea, cartografierea datelor diferă dramatic. Într-un sistem indexat orientat pe rând, cheia principală este rândul care este mapat din datele indexate. În sistemul orientat pe coloane, cheia principală este datele, care sunt mapate din rânduri. Acest lucru poate părea subtil, dar diferența se poate observa în această modificare comună a aceluiași magazin în care cele două articole „Jones”, de mai sus, sunt comprimate într-un singur articol cu ​​două rânduri: 

…;Smith:001;Jones:002,004;Johnson:003;…

Indiferent dacă un sistem orientat pe coloane va fi mai eficient în funcționare depinde în mare măsură de volumul de lucru automatizat. Operațiile care recuperează toate datele pentru un anumit obiect (întregul rând) sunt mai lente. Un sistem orientat pe rând poate prelua rândul într-un singur disc citit, în timp ce numeroase operații pe disc pentru a colecta date din mai multe coloane sunt necesare dintr-o bază de date coloană. Cu toate acestea, aceste operații pe întregul rând sunt în general rare. În majoritatea cazurilor, se recuperează doar un subset limitat de date. Într-o aplicație rolodex, de exemplu, colectarea numelor și prenumelor de pe mai multe rânduri pentru a construi o listă de contacte este mult mai obișnuită decât citirea tuturor datelor pentru orice adresă. Acest lucru este cu atât mai adevărat pentru scrierea datelor în baza de date, mai ales dacă datele tind să fie „rare” cu multe coloane opționale. Din acest motiv, magazinele de coloane au demonstrat performanțe excelente în lumea reală, în ciuda numeroaselor dezavantaje teoretice.

Partiționarea , indexarea , stocarea în cache, vizualizările, cuburile OLAP și sistemele tranzacționale, cum ar fi înregistrarea în avans sau controlul simultan multiversiune, afectează în mod dramatic organizarea fizică a oricărui sistem. Acestea fiind spuse, sistemele RDBMS orientate către procesarea tranzacțiilor online (OLTP) sunt mai orientate pe rând, în timp ce sistemele orientate spre procesarea analitică online (OLAP) sunt un echilibru între orientate pe rând și orientate pe coloane.

Beneficii

Comparațiile între bazele de date orientate pe rânduri și bazele de date orientate pe coloane sunt de obicei preocupate de eficiența accesului la hard disk pentru o anumită sarcină de lucru, deoarece timpul de căutare este incredibil de lung în comparație cu celelalte blocaje din computere. De exemplu, un hard disk tipic Serial ATA (SATA) are un timp mediu de căutare între 16 și 22 de milisecunde, în timp ce accesul DRAM pe un procesor Intel Core i7 durează în medie 60 de nanosecunde, de aproape 400.000 de ori mai rapid. În mod clar, accesul la disc este un blocaj major în gestionarea datelor mari. Bazele de date coloane sporesc performanța prin reducerea cantității de date care trebuie citite de pe disc, atât prin comprimarea eficientă a datelor coloane similare, cât și prin citirea numai a datelor necesare pentru a răspunde la interogare.

În practică, bazele de date coloane sunt potrivite pentru încărcări de tip OLAP (de exemplu, depozite de date ) care implică de obicei interogări foarte complexe asupra tuturor datelor (eventual petabyte ). Cu toate acestea, trebuie făcute unele lucrări pentru a scrie date într-o bază de date coloană. Tranzacțiile (INSERT) trebuie separate în coloane și comprimate pe măsură ce sunt stocate, făcându-le mai puțin potrivite pentru încărcările de lucru OLTP. Bazele de date orientate pe rânduri sunt potrivite pentru sarcini de lucru de tip OLTP, care sunt mai încărcate cu tranzacții interactive. De exemplu, preluarea tuturor datelor dintr-un singur rând este mai eficientă atunci când datele sunt situate într-o singură locație (minimizarea căutărilor de disc), ca în arhitecturile orientate pe rând. Cu toate acestea, sistemele orientate pe coloane au fost dezvoltate ca hibrizi capabili atât de operații OLTP, cât și de operații OLAP. Unele dintre constrângerile OLTP, cu care se confruntă astfel de sisteme orientate pe coloane, sunt mediate utilizând (printre alte calități) stocarea de date în memorie . Sistemele orientate pe coloane, potrivite atât pentru rolurile OLAP, cât și pentru cele OLTP, reduc efectiv amprenta totală a datelor prin eliminarea nevoii de sisteme separate.

Comprimare

Datele coloanei sunt de tip uniform; prin urmare, există unele oportunități pentru optimizarea dimensiunii stocării disponibile în datele orientate pe coloane, care nu sunt disponibile în datele orientate pe rând. De exemplu, multe scheme populare de compresie moderne, cum ar fi codificarea LZW sau lungimea de rulare , folosesc similaritatea datelor adiacente cu comprimarea. Valorile lipsă și valorile repetate, frecvente în datele clinice, pot fi reprezentate printr-un marker pe doi biți. În timp ce aceleași tehnici pot fi utilizate pe date orientate pe rând, o implementare tipică va obține rezultate mai puțin eficiente.

Pentru a îmbunătăți compresia, sortarea rândurilor poate ajuta, de asemenea. De exemplu, folosind indici bitmap , sortarea poate îmbunătăți compresia cu un ordin de mărime. Pentru a maximiza beneficiile de compresie ale ordinii lexicografice în ceea ce privește codificarea pe lungime de rulare , este mai bine să utilizați coloane cu cardinalitate redusă ca primele taste de sortare. De exemplu, având în vedere un tabel cu coloane sex, vârstă, nume, cel mai bine ar fi să sortați mai întâi pe valoarea sexului (cardinalitatea a două), apoi vârsta (cardinalitatea <128), apoi numele.

Compresia pe coloane realizează o reducere a spațiului pe disc în detrimentul eficienței recuperării. Cu cât este realizată o compresie adiacentă mai mare, cu atât mai dificil poate deveni accesul aleatoriu, deoarece datele pot fi necomprimate pentru a fi citite. Prin urmare, arhitecturile orientate pe coloane sunt uneori îmbogățite cu mecanisme suplimentare menite să minimizeze nevoia de acces la date comprimate.

Istorie

Magazinele de coloane sau fișierele transpuse au fost implementate încă din primele zile ale dezvoltării SGBD. TAXIR a fost prima aplicație a unui sistem de stocare a bazelor de date orientat pe coloane, cu accent pe recuperarea informațiilor în biologie în 1969. Datele clinice din evidența pacienților cu multe mai multe atribute decât ar putea fi analizate au fost prelucrate în 1975 și ulterior printr-un sistem de baze de date orientat pe timp (TODS). Statistics Canada a implementat sistemul RAPID în 1976 și l-a folosit pentru procesarea și recuperarea recensământului canadian al populației și locuințelor, precum și alte câteva aplicații statistice. RAPID a fost împărtășit cu alte organizații statistice din întreaga lume și utilizat pe scară largă în anii 1980. Acesta a continuat să fie folosit de Statistics Canada până în anii 1990.

O altă bază de date orientată pe coloane a fost SCSS.

Pachetele ulterioare de baze de date orientate pe coloane au inclus:

Începând cu anul 2004 au existat implementări suplimentare open source și comerciale. MonetDB a fost lansat sub licență open-source la 30 septembrie 2004, urmat îndeaproape de acum defunctul C-Store .

C-store a fost un proiect universitar care, în cele din urmă, cu membrii echipei Michael Stonebraker , a dus la Vertica , pe care a cofondat-o în 2005.

Proiectul X100 legat de MonetDB a evoluat în VectorWise . Druid este un magazin de date orientat pe coloane, care a fost deschis la sfârșitul anului 2012 și este acum utilizat de numeroase organizații.

SGBD relațional clasic poate utiliza strategii orientate pe coloane, amestecând tabele orientate pe rând și orientate pe coloane. În ciuda complexității SGBD, această abordare sa dovedit a fi valoroasă din anii 2010 până în prezent. De exemplu, în 2014 Citusdata a introdus tabele orientate pe coloane pentru PostgreSQL și McObject a adăugat suport pentru stocarea în coloană odată cu lansarea eXtremeDB Financial Edition în 2012, care a fost apoi utilizat pentru a stabili un nou standard de performanță pentru benchmark-ul STAC-M3 auditat independent.

Vezi si

Referințe

linkuri externe