Până la urmă care ar fi o utilizare cât de cât rezonabilă pentru nosql? Eu mă pot gândi doar la un sistem complet nerelațional, de genul unui logging system. Orice altceva mi se pare overkill.
Sunt multe cazuri pentru nosql. Avantajele la relational apare în set de date complexe și fragile. Orice altceva poate fii folosit cu nosql.
Și sunt mult mai multe aplicații decât logging. De exemplu noi am folosit nosql pentru a salva refresh tokens bazat pe access tokens, pentru a reînnoi când e cazul. Structura datelor e triviala dar aplicația asta era foarte importanta. Iar sa folosești SQL pentru un tabel care e non-rational e overkill.
Și evident, poți oricând face un data management layer care îți mimica relational structure.
Sunt cazuri și cazuri. Exemplul din articol e doar un caz.
Aplicația făcea doar asta sau ați folosit SQL pentru restul bazei de date?
Baza de date principală, gen lista de useri, lista de produse ce le vindeam și totul ce e intre, era relational.
Nu eu am luat decizia, dar mi se pare corect sa folosești SQL când ai un număr mare de relații sensibile intre obiecte.
Dar asta nu înseamnă că nu am folosit nosql. Multe aplicații de suport foloseau nosql, inclusiv exemplul de mai sus.
Si de ce este overkill sa stochezi date simple intr-un server sql? Care-i criteriu aici, rogu-te?
Uite un overkill adevarat: “poți oricând face un data management layer care îți mimica relational structure” - cand ai deja un sistem foarte bine pus la punct in SQL.
Apoi ai mai spus Avantajele la relational apare în set de date complexe și fragile. Orice altceva poate fii folosit cu nosql. O fi adevarat ce spui, dar, in experienta ta, ce aplicatie nu va ajunge sa contina date complexe si fragile? Asa… dupa tine. Eu cred ca foarte putine. Si daca asta la randul ei e adevarata, nu inseamna de fapt ca nosql este mai potrivit aplicatiilor triviale?
1 Like
Mă bucur că ai spus că n-a fost decizia ta pentru că părerea mea vizavi de ce s-a făcut acolo este: niște hipsteri au decis să folosească ceva tehnologii pentru că sunt la modă și scrie pe internet despre ele. Mi se pare aberant să folosești un cu totul alt engine de bază de date doar pentru a stoca niște token-uri.
Am analizat asta destul de mult, iar răspunsul a fost că nu prea există așa ceva. OK, poți să te forțezi să utilizezi noSQL, dar nu înțeleg care ar fi motivul pentru asta.
1 Like
Îți răspund pe rand:
-
De ce crezi ca exista nosql în primul rand? Ca e mai rapid în general și mai simplu de întreținut. Sau vrei să-mi explici ca toată lumea își pierde vremea cu nosql?
-
Foarte multe aplicații. Cred ca majoritatea ce nu folosesc auth de nici un fel. Și apoi mai e faza ca deși aplicația în sine e SQL, pot fii multe sub-sisteme scrise cu nosql. Gen exemplul ce l-am dat mai sus.
1 Like
Hai, scuză-mă, nu doar hipsterii folosesc nosql, ce prostie vorbești.
Ce e asa aberant sa folosești nosql sa stochezi token uri? Cum ai face altfel? Creezi un tabel singurel în SQL care n-are nici o relație cu celelalte date? Ce rost are?
Dacă datele nu sunt relational, nu folosi o baza de date SQL, simplu.
Asa de curiozitate, ce ai cu hipsterii ăștia?
Eh nu. Firebase a fost cumpărat de Google tocmai fiindcă nu poți construi aplicații cu el, ce sa zic…
1 Like
PostgreSQL’s JSONB datatype with proper indexes is faster than some, if not most of NoSQL alternatives (for normal apps). Yes, scaling is still an issue but worth the benefits of a full ACID compliant db-engine
2 Likes
nosql o fi mai rapid si mai simplu de intretinut, dar astea nu pot fi toate considerentele luate in vizor, altfel ai fi stocat cele token-uri in fisiere CSV. Rapiditatea si simplitatea intotdeauna vin cu un cost - lipsa unei scheme si a verificarilor integritatii de date, in special. Aplicatii cu date complexe sau critice n-au de gand sa plateasca asta. Si n-am spus ca toata lumea-si pierde timpul cu nosql.
Ai mai spus asta “Dacă datele nu sunt relational, nu folosi o baza de date SQL, simplu”. Laitmotivul articolelor anti-nosql este dificultatea schimbarii de la nosql la sql, din moment ce bajetii isi dau seama ca aplicatia a trecut un anumit prag de complexitate. Da, este usor sa stochezi date simple in nosql, dar risti sa te trezesti intr-un cleste tehnologic din care greu iesi. Asa ca unii prefera sa inceapa chiar si cu date simple direct in sql.
1 Like
Scuza-ma, dar nu e mai rapid sau mai comod sa folosești CSV. Deloc.
Bun, pai asta zic și eu.
Uneori știi clar ca nu o sa fie complexitate în plus fiindcă e un scop clar și simplu. Atunci folosești nosql. Nu ma lua cu chestii abstracte gen “în timp toate aplicațiile cresc inevitabil” fiindcă un log sistem rămâne un log sistem și peste 10 ani.
TLDR sunt se acord cu tine, nu știu ce vrei să-mi spui.
1 Like
Asta ar sugera faptul ca CSV-ul ar fi mai rapid fata de o baza de date (sql sau nosql), lucrul cu fisiere este cel mai lent. Majoritate bazelor de date tin informatiile in ram, iar citirea este mult mai rapida.
Articolu initial este despre MongoDB, dar toti va referiti la nosql. Nosql sunt si memcached si redis, iar majoritatea aplicatiilor complexe le folosesc pt caching.
Apropo ce inseamna aplicatie complexa?
Cum ar arata o structura pe sql pentru un catalog online (produse si atribute)?
1 Like
Vrei să spui în vreun fel, chiar și pe departe, că utilizarea NoSQL ar fi o idee bună în situația asta? 
Dacă stai să te gândești, ajungi la concluzia că e chiar ideal să faci asta, având în vedere cât de simplu ar fi să stochezi în aceeași colecție atât un telefon mobil cât și o rochie de seară, cu tot cu specificațiile lor tehnice. Imaginează-ți numai cât de simplă și rapidă ar fi apoi filtrarea produselor, de exemplu.
- poți include rochiile în colecții?
- poți lista variante de culoare pentru rochia X?
- poți adăuga recomandări de accesorii (pantofi, genți, bijuterii etc.) la rochia X?
Și probabil mai pot scoate vreo câteva întrebări
Răspunsul este un DA cât se poate de mare și de clar la toate întrebările de mai sus, fără nici un fel de compromis!
Dacă nu știi să faci chestiile astea banale în Mongo, îmi pare rău, dar nu ești în măsură să comentezi unde, cum sau de ce este sau nu este bun Mongo.
2 Likes
Dacă la întrebarea 1 era evident că răspunsul este „Da”, zi-mi, te rog, la 3 cum faci fără niciun fel de compromis.
Nici n-am zis că sunt în măsură să fac asta. Sunt doar un hater care a intrat în discuție pentru că i se pare aberant să folosești două sisteme de baze de date pentru aceeași aplicație, dar în același timp sunt 99% convins că în practica de zi cu zi mai devreme sau mai târziu te vei lovi de relații între elementele din baza de date și atunci o să fie nasol cu NoSQL-ul. Că există workarounds, sunt de acord, dar nu știu cât de OK e să fii nevoit să apelezi la așa ceva.
Ba mai mult, dacă reușești/reușiți să veniți cu răspunsuri practice la ce întreb eu p-aici e cu atât mai bine, poate mă determinați să folosesc și eu Mongo la o mini-aplicație în curând. 
Ca să nu mai vorbim de faptul că avem cu toții de învățat dintr-o astfel de discuție.
1 Like
-
articolul are 3 ani. multe s-au schimbat (in bine) under the hood (gen improvement major (pt rata de scriere/citire) de la o versiune la alta pastrand acelasi hardware
-
consider ca din start idea lor de a folosi mongo e una neinspirata de aici si problemele pe care le povestesc ei
-
mongo e marketat ca un nosql cu valente de sql (chiar am dat de multe articole cum sa faci X in mongo folosind logica de sql) dar pentru rezultate ok trebuie folosit strict ca un nosql
Se poarta multiplele tipuri de baza de date pe aceeasi aplicatie de cativa ani chiar. Poti vedea aici http://highscalability.com/blog/category/example exemple de ahitecturi si dai foarte des de aplicatii cu cate 3-4-5 sisteme de baza de date. Logic ca nu sunt intercalate in asa fel incat intr-o pagina sa ai query-uri de la fiecare ci se folosesc in microservicii.
Gandirea de a folosi strict una vine cand esti one man show si te gandesti la tot ce presupune administrarea lor dar intr-un colectiv e cineva care se ocupa de backp-uri, replicare, availability strategy
Pana la urma asta e ideea de a fi considerat un programator, sa combini toate variantel posibile in asa fel incat sa scoti viteza mai buna/ cost mai bun/ timp de dezvoltare mai scurt decat competitorii.
5 Likes
La 3 as folosi http://templates.prediction.io/PredictionIO/template-scala-parallel-complementarypurchase sau ceva asemanator.
Ideea e de right tool for the job.