Ghidul unui inginer de date pentru stocarea de date netradițională

Ingineria datelor

Odată cu creșterea big data și a științei datelor, multe roluri de inginerie sunt provocate și extinse. Un rol din noua era este ingineria datelor .

Inițial, scopul ingineriei datelor a fost încărcarea surselor de date externe și proiectarea bazelor de date (proiectarea și dezvoltarea conductelor pentru colectarea, manipularea, stocarea și analiza datelor).

De atunci, a crescut pentru a suporta volumul și complexitatea datelor mari. Deci, ingineria datelor încapsulează acum o gamă largă de abilități, de la accesarea cu crawlere pe web, curățarea datelor, calcularea distribuită și stocarea și recuperarea datelor.

Pentru ingineria datelor și inginerii de date, stocarea și recuperarea datelor este componenta critică a conductei, împreună cu modul în care datele pot fi utilizate și analizate.

În ultima vreme, au apărut multe tehnologii noi și diferite de stocare a datelor. Cu toate acestea, care este cel mai potrivit și are cele mai potrivite caracteristici pentru ingineria datelor?

Majoritatea inginerilor sunt familiarizați cu bazele de date SQL, cum ar fi PostgreSQL, MSSQL și MySQL, care sunt structurate în tabele de date relaționale cu stocare orientată pe rând.

Având în vedere cât de omniprezente sunt aceste baze de date, nu le vom discuta astăzi. În schimb, explorăm trei tipuri de stocări alternative de date care cresc în popularitate și care au introdus abordări diferite pentru tratarea datelor.

În contextul ingineriei datelor, aceste tehnologii sunt motoarele de căutare, magazinele de documente și magazinele cu coloane.

• Motoarele de căutare excelează la interogări de text. În comparație cu potrivirile de text din bazele de date SQL, cum ar fi LIKE , motoarele de căutare oferă capabilități mai mari de interogare și performanțe mai bune.
• Depozitele de documente oferă o mai bună adaptabilitate a schemei de date decât bazele de date tradiționale. Prin stocarea datelor ca obiecte de document individuale, adesea reprezentate ca JSON, acestea nu necesită predefinirea schemei.
• Magazinele pe coloană sunt specializate în interogări cu o singură coloană și agregări de valori. Operațiunile SQL, cum ar fi SUM și AVG , sunt considerabil mai rapide în magazinele cu coloane, deoarece datele din aceeași coloană sunt stocate mai aproape una de cealaltă pe hard disk.

În acest articol, explorăm toate cele trei tehnologii: Elasticsearch ca motor de căutare, MongoDB ca magazin de documente și Amazon Redshift ca magazin cu coloane.

Înțelegând stocarea alternativă a datelor, putem alege cea mai potrivită pentru fiecare situație.

Pentru a compara aceste tehnologii, vom examina modul în care indexează, fragmentează și cumulează datele.

Fiecare strategie de indexare a datelor îmbunătățește anumite interogări în timp ce le împiedică pe altele.

A ști care interogări sunt utilizate cel mai des poate influența ce depozit de date să adopte.

Sharding, o metodologie prin care bazele de date își împart datele în bucăți, determină modul în care infrastructura va crește pe măsură ce sunt ingerate mai multe date.

Alegerea uneia care se potrivește cu planul și bugetul nostru de creștere este esențială, iar acest lucru se aplică oricărei firme de știință a datelor, indiferent de dimensiune.

În cele din urmă, aceste tehnologii își adună fiecare datele în mod foarte diferit.

Când avem de-a face cu gigaocteți și terabytes de date, o strategie de agregare greșită poate limita tipurile și performanța rapoartelor pe care le putem genera.

În calitate de ingineri de date, trebuie să luăm în considerare toate cele trei aspecte atunci când evaluăm diferite stocări de date.

Concurenți

Motor de căutare: Elasticsearch

Elasticsearch a câștigat rapid popularitate în rândul colegilor săi pentru scalabilitatea și ușurința de integrare. Construit pe Apache Lucene, oferă o funcționalitate puternică de căutare și indexare a textului. Pe lângă sarcinile tradiționale ale motorului de căutare, căutarea textului și interogările cu valori exacte, Elasticsearch oferă și capabilități de agregare stratificată.

Magazin de documente: MongoDB

În acest moment, MongoDB poate fi considerată baza de date NoSQL. Ușurința sa de utilizare și flexibilitatea și-au câștigat rapid popularitatea. MongoDB acceptă interogări bogate și adaptabile pentru săparea în documente complexe. Câmpurile solicitate adesea pot fi accelerate prin indexare, iar atunci când se agregează o bucată mare de date, MongoDB oferă o conductă în mai multe etape.

Magazin Columnar: Amazon Redshift

Pe lângă creșterea popularității NoSQL, și bazele de date cu coloane au atras atenția, în special pentru analiza datelor. Prin stocarea datelor în coloane în locul rândurilor obișnuite, operațiunile de agregare pot fi executate direct de pe disc, crescând foarte mult performanța. În urmă cu câțiva ani, Amazon și-a lansat serviciul găzduit pentru un magazin cu coloană numit Redshift.

Indexarea

Capacitatea de indexare a Elasticsearch

În multe privințe, motoarele de căutare sunt depozite de date specializate în indexarea textelor.

În timp ce alte depozite de date creează indici bazați pe valorile exacte ale câmpului, motoarele de căutare permit regăsirea doar cu un fragment din câmpul (de obicei text).

În mod implicit, această preluare se face automat pentru fiecare câmp prin analizoare.

Un analizor este un modul care creează mai multe chei de index evaluând valorile câmpului și împărțindu-le în valori mai mici.

De exemplu, un analizor de bază ar putea examina „vulpea maro iute a sărit peste câinele leneș” în cuvinte, cum ar fi „cel”, „rapid”, „maro”, „vulpe” și așa mai departe.

Această metodă permite utilizatorilor să găsească datele căutând fragmente în cadrul rezultatelor, clasificate în funcție de câte fragmente se potrivesc cu aceleași date de document.

Un analizor mai sofisticat ar putea utiliza distanțele de editare, n-gramele și filtrarea după cuvinte oprite, pentru a construi un index de regăsire cuprinzător.

Capacitatea de indexare a MongoDB

Ca magazin de date generic, MongoDB are multă flexibilitate pentru indexarea datelor.

Spre deosebire de Elasticsearch, acesta indexează numai câmpul _id în mod implicit și trebuie să creăm manual indici pentru câmpurile interogate frecvent.

În comparație cu Elasticsearch, analizatorul de text MongoDB nu este la fel de puternic. Dar oferă multă flexibilitate cu metodele de indexare, de la compus și geospațial pentru interogare optimă la TTL și rară pentru reducerea stocării.

Capacitatea de indexare a lui Redshift

Spre deosebire de Elasticsearch, MongoDB sau chiar bazele de date tradiționale, inclusiv PostgreSQL, Amazon Redshift nu acceptă o metodă de indexare.

În schimb, își reduce timpul de interogare prin menținerea unei sortări consistente pe disc.

În calitate de utilizatori, putem configura un set ordonat de valori de coloană ca cheie de sortare a tabelului. Cu datele sortate pe disc, Redshift poate sări peste un întreg bloc în timpul recuperării dacă valoarea acestuia se încadrează în intervalul interogat, sporind puternic performanța.

Sharding

Capacitatea de fragmentare a lui Elasticsearch

Elasticsearch a fost construit pe partea de sus a Lucene pentru a se scala orizontal și a fi gata de producție.

Scalare se realizează prin crearea mai multor instanțe Lucene (shard-uri) și distribuirea lor pe mai multe noduri (servere) într-un cluster.

În mod implicit, fiecare document este direcționat către fragmentul respectiv prin câmpul său _id .

În timpul recuperării, nodul principal trimite fiecărei fragmente o copie a interogării înainte de a le agrega și a le clasifica pentru ieșire.

Capacitatea de fragmentare a MongoDB

Într-un cluster MongoDB, există trei tipuri de servere: router, config și shard.

Prin scalarea routerului, serverele pot accepta mai multe solicitări, dar sarcinile grele au loc la serverele shard.

Ca și în cazul Elasticsearch, documentele MongoDB sunt direcționate (în mod implicit) prin _id către fragmentele lor respective. La momentul interogării, serverul de configurare notifică routerul, care fragmentează interogarea, iar serverul routerului distribuie apoi interogarea și adună rezultatele.

Capacitatea de fragmentare a lui Redshift

Un cluster Amazon Redshift este format dintr-un nod lider și mai multe noduri de calcul.

Nodul lider se ocupă de compilarea și distribuirea interogărilor, precum și de agregarea rezultatelor intermediare.

Spre deosebire de serverele de router MongoDB, nodul lider este consistent și nu poate fi scalat pe orizontală.

În timp ce acest lucru creează un blocaj, permite, de asemenea, stocarea eficientă în cache a planurilor de execuție compilate pentru interogările populare.

Agregarea

Capacitatea de agregare a Elasticsearch

Documentele din Elasticsearch pot fi grupate după valori exacte, variate sau chiar temporale și de geolocație.

Aceste găleți pot fi grupate în continuare în granularitate mai fină prin agregare imbricată.

Valorile, inclusiv mediile și abaterile standard, pot fi calculate pentru fiecare strat, ceea ce oferă posibilitatea de a calcula o ierarhie de analize într-o singură interogare.

Fiind o stocare bazată pe documente, suferă de limitarea comparațiilor câmpurilor intra-document.

De exemplu, deși este bun la filtrarea dacă un câmp de urmăritori este mai mare de 10, nu putem verifica dacă adepții este mai mare decât un alt câmp care urmează .

Ca alternativă, putem injecta scripturi ca predicate personalizate. Această caracteristică este excelentă pentru analize unice, dar performanța are de suferit în producție.

Capacitatea de agregare a MongoDB

Conducta de agregare este puternică și rapidă.

După cum sugerează și numele, funcționează pe datele returnate într-o manieră pe etape.

Fiecare pas poate filtra, agrega și transforma documentele, poate introduce noi valori sau poate anula grupurile agregate anterior.

Deoarece aceste operațiuni sunt efectuate într-o manieră în etape și, asigurându-vă că documentele și câmpurile sunt reduse la doar filtrate, costul memoriei poate fi minimizat. În comparație cu Elasticsearch și chiar Redshift, Aggregation Pipeline este o modalitate extrem de flexibilă de a vizualiza datele.

În ciuda adaptabilității sale, MongoDB suferă aceeași lipsă de comparație a câmpurilor intra-document ca și Elasticsearch.

În plus, unele operațiuni, inclusiv $group , necesită ca rezultatele să fie transmise nodului principal.

Astfel, ele nu folosesc calculul distribuit.

Cei care nu sunt familiarizați cu calculul conductei pe etape vor găsi anumite sarcini neintuitive. De exemplu, însumarea numărului de elemente dintr-un câmp matrice ar necesita doi pași: mai întâi, $unwind și apoi operația $group .

Capacitatea de agregare a Redshift

Beneficiile Amazon Redshift nu pot fi subestimate.

Agregările frustrant de lente pe MongoDB în timp ce se analizează traficul mobil sunt rezolvate rapid de Amazon Redshift.

Suportând SQL, inginerii tradiționali ai bazelor de date își vor migra cu ușurință interogările către Redshift.

Lăsând deoparte timpul de integrare, SQL este un limbaj de interogare dovedit, scalabil și puternic, care acceptă cu ușurință comparațiile de câmpuri intra-document/rând. Amazon Redshift își îmbunătățește și mai mult performanța prin compilarea și stocarea în cache a interogărilor populare executate pe nodurile de calcul.

Ca bază de date relațională, Amazon Redshift nu are flexibilitatea schemei pe care o au MongoDB și Elasticsearch. Optimizat pentru operațiuni de citire, suferă lovituri de performanță în timpul actualizărilor și ștergerilor.

Pentru a menține cel mai bun timp de citire, rândurile trebuie sortate, adăugând eforturi operaționale suplimentare.

Adaptat celor cu probleme de dimensiunea unui petabyte, nu este ieftin și probabil că nu merită investiția decât dacă există probleme de scalare cu alte baze de date.

Alegerea Câștigătoarei

În acest articol, am examinat trei tehnologii diferite – Elasticsearch, MongoDB și Amazon Redshift – în contextul ingineriei datelor. Cu toate acestea, nu există un câștigător clar, deoarece fiecare dintre aceste tehnologii este un lider în categoria de tip de stocare.

Pentru ingineria datelor, în funcție de cazul de utilizare, unele opțiuni sunt mai bune decât altele.

• MongoDB este o bază de date de pornire fantastică. Oferă flexibilitatea pe care o dorim atunci când schema de date este încă de determinată. Acestea fiind spuse, MongoDB nu depășește cazurile de utilizare specifice în care sunt specializate alte baze de date.
• În timp ce Elasticsearch oferă o schemă fluidă similară cu MongoDB, este optimizat pentru mai mulți indici și interogări de text în detrimentul performanței de scriere și al dimensiunii de stocare. Astfel, ar trebui să luăm în considerare migrarea la Elasticsearch atunci când ne aflăm menținând numeroși indici în MongoDB.
• Redshift necesită o schemă de date predefinită și îi lipsește adaptabilitatea pe care o oferă MongoDB. În schimb, depășește alte baze de date pentru interogări care implică doar coloane individuale (sau câteva). Când bugetul o permite, Amazon Redshift este o armă secretă grozavă atunci când alții nu pot gestiona cantitatea de date.