Ati folosit sisteme de tip NoSQL?
Daca da, de ce ati ales NoSQL in defavoarea clasicului?
Eu am gasit un articol foarte simpatic, dar voiam sa aflu si ceva pareri “la cald”.
Din: http://nosql-database.org/ am folosit redis si elasticsearch.
Redis pentru increments
Elasticsearch pentru cautare (faceturi + viteza)
Postgres HStore or its native JSON support or both.
Am inceput sa folosesc NoSQL pentru ca aveam date complexe de salvat si am preferat in loc sa fac join-uri intre zeci de tabele sa salvezi totul intr-un singur loc.
Alt motiv este ca imi place sa incerc si tehnologii noi. De curand am inceput sa ma joc putin cu Neo4j (graph database)
Daca nu ai o aplicatie ce genereaza un load imens pe DB (atat de mare incat ai nevoie de clusters si etc.) nu ai de ce sa folosesti NoSQL.
Poti avea toata functionalitatea NoSQL insa intr-un mediu ACID compliant => Postgres.
NoSQL nu mai este tehnologie noua de ceva timp, ciudat insa ca hype-ul este inca up si inca vad aplicatii minuscule folosind MongoDB pt. ca este cool si oamenii nu vor sa faca join-uri.
Neo4j in schimb pt. anumite use cases este un life saver.
1 Like
- Si ce ai folosit pentru NoSQL?
- Pentru ce tip de date ai folosit neo4j?
Am folosit la Qalendra MongoBD ca sa salvez evenimentele, au structura complexa de genul:
- locatii
- date calendaristice
- lista de taguri
Si m-a atras ca pot sa salvez direct array-uri in structura (fara sa salvez stringjson_encodesau join-uri de tabele). Mi s-a parut potrivit pentru tipul de date pe care le salvez.
L-am folosit in paralel cu MySQL in care am facut restul implementarilor (useri, categorii)
pentru ca mi-a fost frica sa il folosesc peste tot in loc deMySQL.
Alt proiect este Catalist cu Solr. Solr la baza este un search engine cu persistenta dar se comporta bine si ca baza de date 
(don’t bash me)
Folosit iarasi in paralel cu MySQL.
Acum mai am un proiect inca in faza de development la care am renuntat complet la MySQL si totul este in MongoDB scris pe Laravel.
MongoDB se comporta foate bine si pe trafic putin ridicat (atat am putut sa testez pana acum) cautarile pe index sunt sub 2ms.
Neo4j am folosit la baza de date in care poti sa modelezi un proces, workflow.
Un alt client cu care lucrez creaza un engine de cautare pentru oameni scris pe baza Neo4j si este destul de bun ca performanta si ca rezultate.
Un MVP pe tehnologia lor PeopleGraph
3 Likes
Am folosit:
- Redis - key:value format, small short lifecycle messages - sesiuni, tokens (are expire date), sync sessions (pub/sub on data change)
- MongoDB - flexibilitate in document schema, are un API foarte usor de inteles
- Riak - pt. un sistem care necesita distributed and persistend data, la fel flesibilitate in documente
- LevelDB - key:value format, embeded database (nu ai nevoie de un serviciu extern), very nice for small projects
1 Like
Recunoasteti ca toti ati gasit prima data “nevoia” ca sa implementati ceva nou. In real world, inca n-am gasit aplicatia care sa ceara expres noSQL. Bazele de date relationale se preteaza la 99% din cazuri, daca nu mai mult.
@AdrianBasalic eu am folosit noSQL de nevoie. Chestia cu joaca m-a ocolit in ultimii ani.
@AdrianBasalic Primul proiect cu date complexe a fost pe Solr si atunci era deja un proiect inceput pe tehnologia asta, trebuia sa il continuu tot asa.
Apache Cassandra pentru generarea unui “graph” in care se stocau diferite relatii intre utilizatori (prieteni, notificari, posturi, requesturi, countere …), lucruri care se obtineau destul de greoi prin intermediul MySQL.
Practic un cache persistent de diferite chei primare care se puteau parcurge in diferite directii cu un anumit range si cu data de expirare in unele cazuri.
Dupa extractie le foloseam pentru a interoga MySQL direct pe cheia primara pentru a evita o gramada de join-uri / union samd.
Se putea obtine si cu Redis lucrul asta insa Cassandra este “no single point of failure” si parea mai potrivit pentru cloud in acel moment.
1 Like
Quick question: cum invalidai datele din cache? in afara de auto expire. Pentru ca altfel ai avea perioade cu stale data.
EDIT: partea cu “no single point of failure” este un pic irelevant pentru un cache
Practic un cache persistent de diferite chei primare
Nu trebuia sa-l invalidez pentru ca era persistent, un garbage collector stergea ceea ce consideram ca nu mai e necesar dupa niste reguli stabilite …
Nu e irelevant, trebuia sa fie tot timpul available 
Am inteles, adica aplicatia nu functiona fara el, in cazul acesta nu cred ca mai este cache. 
Nu, nu functiona fara din pacate.
Am zis … un fel de cache doar ca sa se inteleaga rolul lui 
M-ai indus in eroare! :))
Oricum interesant btw. ce era atat de slow (SQL wise) incat a fost nevoie sa scrii un
"garbage collector"[0] si sa duplici cheile primare in alt datastore? (asta pe langa noile dependente)
[0] cu ghilimele, pentru ca nu sunt sigur daca ai implementat o varianta simplificata a unui GC sau este iarasi “un fel de GC”
Eh, cum spuneam (prieteni, prietenii prietenilor, notificari, posturi, friend request …) zeci sau sute de milioane de row-uri pentru fiecare dintre entitati care trebuiau parcurse in sens descrescator in general si cu limit si skip, sau join-uri intre ele care la un numar asa mare de row-uri era cam greoi …
Inspirat initial de aici: https://github.com/twissandra/twissandra
“un fel de GC”, ai dreptate …un cron periodic adica … sunt sigur ca toata lumea foloseste asa ceva.
I moved a post to a new topic: MySql 5.6 - NoSql cu ajutorul memcached
zeci sau sute de milioane de row-uri
Did you actually measure it? Intre zeci si sute de milione este o diferenta mare. In mod normal daca nu te apuci sa faci chestii recursive in graf precum sa testezi daca un sub-graf este inclus in altul atunci SQL basic optimisations si Redis/Memcache in fata should do just fine.
Always measure.
Postgres hstore