Cum parsezi 25tb date?

Dacă ați avea un DB de 25tb, cum ați aborda sortarea sau căutarea? (eu unul recunosc că m-aș uita ca broasca la bordură și n-aș avea habar ce să fac)

Using AWK and R to parse 25tb

6 Likes

Eu as folosi clientul CLI pe care cam toate bazele de date il pun la dispozitie. Cu xargs si si alte comenzi poti face lucrurile simplu si eficient :slight_smile:


PS: awk este rapid si este un limbaj de programare in toata regula. Am implementat cativa algoritmi in el :stuck_out_tongue:

1 Like

Păi da, asta a făcut și autorul, dar un query dura 8 minute (și nici măcar nu erau toate datele). Deci clientul CLI pică din start.

1 Like

Atunci facem si noi cum a facut nenea ala in articol :slight_smile:

Am ce sa discut cu colegul din diagonala maine :smiley:

Ma intreb cum s-ar comporta un NoSQL gen MongoDB pe un astfel de scenariu, sau un serviciu gen BigQuery de la Google, despre awk nu stiu prea multe doar ca e un utilitar UNIX daca citesc tutoriale cu el inteleg dar am o repulsie fata de acest tool, 25tb e nivelul de date produs de useri pe o platforma cunoscuta gen booking.com, twitter.com, etc intr-o zi, oricum acolo au niste procese automatizate.

ElasticSearch/BigQuery sau altceva de genul asta, maybe? PostgreSQL, de exemplu, are foreign data wrapper pt ElasticSearch. Infrastructura pentru asa ceva, insa, va fi probabil foarte scumpa :slight_smile:

as cauta pe Google cum se face :upside_down_face:

Presupun ca problema ta nu permite o optimizare a structurii bazei de date, ci efectiv cere o solutie in contextul actual. Eu as imparti problema in 2: partea care depinde de structura bazei de date si (presupun ca) este inflexibila la modificari, si partea de client de cod care ar suporta ajustari in whatever language. In functie de ce fel de date ai o nevoie sa sortezi/cauti eu mi-as face niste queryuri la distanta optima dintre eficienta si rapiditate pentru baza de date. Dupa ce am gasit aceasta formula, presupunand ca ma pot folosi de cod, as jongla cu chunkuri si procesarea de date astfel incat sa obtin datele cu o viteza acceptabila pentru contextul pe care il am.
Sper ca ideea mea te-a ajutat.

Later edit: mai este si situatia in care datele nu se actualizeaza des, caz in care poti sa descarci datele local, odata la # zile (si sa folosesti ceva algoritm care apoi descarca numai ce s-a modificat), si efectuezi citirile local. Sau descarci permanent pe chunkuri din baza de date timp in care procesezi datele din chunkurile deja descarcate.
25 TB este foarte mult. Sunt convins ca exista frameworkuri sau aplicatii pentru asta, dar inainte de alegi ceva trebuie sa stii care se potriveste cel mai bine la problema ta.

1 Like

Să nu uităm de JSONB (document storage) cu indexare și chiar full text search/indexing. În acestă prezentare aflăm că performanța poate să fie superioară alternativelor NoSql dacă implementarea este corectă

1 Like

Acum imi dau seama ca nu prea exista “local” care sa poata suport 25 TB descarcati. Deci ar mai ramane sa descarci pe chunkuri si in timp ce descarci pe cel curent, sa-l procesezi pe anteriorul apoi sa stergi chunkul pentru care s-a terminat procesarea pentru a face loc urmatorului.
Interesanta problema :wink:

1 Like

Ceva asemanator am întâlnit într-un proiect, in 2015, dar nu m-am ocupat eu de partea asta.

Problema era următoarea: 43.000 de elevi au colectat date de mediu cu niște aparate IoT timp de 2 zile, rezultând aproximativ 4 PB de date (petabytes - ca sa nu se înțeleagă greșit - adică 4000 TB).

Developerii au ales Cassandra pentru stocare. Au creat cateva clustere de servere si apoi elevii au uploadat datele.

Ulterior s-au putut executa diverse operațiuni de citire a datelor. Nu știu cat dura o operațiune, pentru ca n-am avut acces la partea asta, dar s-au creat statistici bazate pe toate datele.

In concluzie, Cassandra este foarte buna pentru managementul bazelor de date largi, iar local exista o limita de capacitate (memorie, procesor, disponibilitate stocare) care nu permite astfel de operațiuni.

7 Likes

In functie de use-case, ai putea folosi si Amazon Athena.