Big Data - choose DB

Buna,
incep un proiect care va trebui sa adune statistici si sa faca operatii pe seturi mari de date, e vorba de zeci de mln de intrari.

Ma orientez catre Cassandra si PostgresSQL. Dar nu am experienta nici cu una.
A avut cineva experienta cu asa seturi de date ? Ce as putea alege pentru o procesare cat mai rapida si scalabilitate.

Multumesc.

Sunt mai mute aspecte care trebuiesc luate in calcul:

  • stocarea datelor raw
  • calculul statisticilor (frecventa, repetabilitate, etc)
  • arhivarea datelor raw
  • $$$ investiti in monthly storage (chiar daca solutiile pe care le alegi sunt gratuite la nivel de licentiere, costul stocarii datelor trebuie calucalt inca de la inceput)

Depinde de aplicatia pe care o ai de implementat, insa se recomanda folosirea mai multor storage-uri, fiecare potrivit pentru ce ai nevoie.

1 Like
  • ce inseamna stocarea raw ?
  • e o platforma de advertising, se poate deduce frecventa de aici :slight_smile:

Nu conteaza foarte mult $$$ pt stocare, important este sa ruleze foarte rapid, ceva solutii ? Tehnici de arhitectura, link-uri utile ? Orice ar fi binevenit.

Cu Cassandra nu prea ai cum sa dai gres, parca am vazut recent ca e o versiune rescrisa in C++ de 10 ori mai rapida. Daca mergi pe proiecte Hadoop ai si experti in domeniu.

Eu am folosit https://www.rethinkdb.com la statistici de servere de jocuri si mi se pare genial dar ai query builder-uri si pentru postgresql care fac ceva de genul ca ReQL. (dar eu zic ca e super util sa faca push direct baza de date la schimbari)

Practic iti poti face 99% din ce ai nevoie in aplicatia ta cu ajutorul change feeds.

Nu as folosi PostgreSQL deoarece poate uiti ceva critic din schema la inceput si e mai greu sa corectezi.

1 Like

Tl;dr: o baza de date SQL ar trebui sa fie OK la scara de care vorbesti (cateva zeci de milioane de records, chiar sute/miliarde daca te pui pe tuning si organizare mai buna).

Am folosit pentru o situatie similara SQL Server plus stack-ul Microsoft. Postgres ar trebui sa mearga asemena. Ambele au recent suport pentru column stores, care se preteaza pentru genul asta de work-load-uri foarte bine. Pui tot log-ul de impressions, ad clicks, beacons etc. intr-un tabel columnar si obtii query-uri analitice foarte rapide si footprint pe disk foarte mic din cauza compresiei. Best of both worlds.

Ca idee, in vremurile noastre, trebuie sa incepi sa-ti pui probleme de technologii non-SQL cand ai milioane de request-uri pe ora (sau chiar minut) (bine, putin inainte de volumul asta :slight_smile: ) Solutii precum Cassandra/HBase/BigTable etc sunt mai mult orientate spre partea de serving, decat spre management mare de log-uri / date analitice. Acolo esti mai mult pe partea de HDFS/Hadoop&friends.

O chestie putin apreciata la solutii NoSQL este partea operationala mult mai complexa. Nu poti sa ai pur si simplu Cassandra sau HBase, de exemplu. Trebuie sa ai un cluster ZooKeeper, un cluster HDFS, diverse tool-uri de monitorizare si alertare, poate un cluster task manager etc. Si fireste, lumea dedicata pe partea asta. Mai bine incepi sa folosesti AWS & co, cu ofertele lor managed. Dar daca tot esti acolo, mai bine incepi cu SQL-ul de pe platforma si dup’aia vezi cum cresti, pentru ca e o crestere mai usoara.

Un articol foarte interesant despre exact problema asta e aici. In principiu s-au apucat sa faca un sistem foarte over-engineered, si si-au prins urechile in el. Pana la urma au rezolvat totul cu un program command line care ruleaza odata pe zi.

4 Likes