… so realistically, there’s nothing it’s good at, and a bunch of stuff it’s outright bad at. And these bulletpoints are facts, not ‘just your opinion’. You can go out and verify them yourself.
Varianta tl;dr:
Never use a database because ‘everybody else does’, do your own research as to the advantages and drawbacks of a particular database. Popularity is largely subject to hype, and with the right marketing team, it’s not hard to popularize an inferior solution.
Confirm o parte din cele scrise acolo. Am folosit CouchBase “la greu”, in sensul ca l-am dus pana la limita. Cnad vreti sa testati orice fel de baza de date, recomand sa scrieti un sistem de logging care varsa datele acolo si pe urma sa cautati dupa “ceva”. Se vede orice limitare in scurt timp.
Din pacate a trebuit sa trecem la Mongo in alte proiecte. Am ajuns pana acolo incat sa invat pentru certificare, noroc ca m-am oprit la timp. E o diferenta de la cer la pamant in defavoarea Mongo. E ca si cum ai conduce un Logan dupa ce te-ai dat jos din Maserati [insert your favorite car].
Am ajuns la concluzia personala ca e bun la prototyping, dar inferior pentru sisteme live.
Articolul este destul de slab iar trimiterile pe care le face mi se par subiective. MongoDB is no silver bullet. Clar are o gramada de probleme, dar n-as zice ca nu are nici un avantaj sau ca nu e util in anumite scenarii. Cred ca MongoDB devine un soi de PHP al bazelor de date, si i se aplica si lui zicala aia despre limbaje de programare: there are 2 types, the ones people bitch about and the ones nobody uses.
ma indoiesc ca l-ar mai folosi lumea daca nu face chiar nimic cum trebuie. absolut toate db-urile au dezavantajele lor si absolut niciuna nu se potriveste in absolut orice caz.
O sa fiu putin offtopic. Si mie imi place SQLul “clasic”. Sunt insa scenarii care cer o abordare non-relationala. Prototipizarea e cea care imi place cel mai mult. Dureaza fizic mai mult sa faci setup la un SQL cu o structura standard. Cand am scris un pic de cod care face si el “ceva” si imi dau seama ca de fapt imi trebuie putin altfel structura, trebuie sa fac o migrare a DBului, etc. Pe cand in NoSQL inserez date cu noua structura si gata. Dupa ce exista un prototip functional, care impacheteaza un set stabil de features, se trece la o stabilizare, moment in care e bine de pus pe lista si baza de date, ca sa existe posibilitatea inlocuirii sale inainte de a merge live. Am plecat de la premisa ca cel care face prototipul abstractizeaza pe cat posibil sistemul de stocare, ca sa fie usurat acest pas. Promovez intotdeauna punctul de vedere al lui Uncle Bob, de a scoate baza de date din centrul sistemului si a face alegerea cat mai tarziu.
Eu il folosesc si in productie pana acum maxim am ajuns la 500 request-uri/s si cauta la fiecare request intr-o colectie de 60mil documente. Timp raspuns mediu: 30ms
Toata treaba e un replica set de 3 masini cu cate 15gb rami, write-ul se face pe primary iar read-urile de pe secondary.
Smecheria consta in indecsi, sa incapa toti in ram. Cu versiunea 3 a aparut un nou sistem de storage care face compresie mai buna decat cel default si a scazut la jumate spatiul ocupat (si pe hdd si in ram)
La inceputuri avea o problema cu locking-ul (la creatul unui indecs de ex. bloca write/read pe intreaga baza de date) dar acum lock-ul se face la nivel de colectie iar pe un replica set poti scoate oricand un nod temporar, crea index acolo, apoi bagat inapoi in replica set.
Daca pica un nod subit, primary-ul e reales in cateva secunde si sistemul merge fara downtime. Cand nodul revine, face sincronizare automata.
Inca n-am ajuns la sharding dar nu cred ca e mai mare bataia de cap decat oricare alt database.
Request-uri HTTP in aplicatia care are in spate mongo. Necache-uite pt ca e nevoie de realtime.
Intr-un request sunt mai multe operatii care se fac in mongo. Aici un grafic cu nr. si tipul de operatii facute/s
Daca as avea acces la date as incerca migrarea spre postgres combinat cu JSONB si GIN/GIST indexes (where applicable) doar sa vad diferenta de perf. pe langa the usual SQL niceties. e.g.:
If your project involves user accounts, or any kind of relationship between two records, then you should use a relational database
Am inceput sa lucrez la un proiect personal dar incerc tehnologii noi pentru mine. Flask pe backend pentru un API, React pe frontend. In cazul asta ma gandeam sa folosesc NoSQL dar e posibil sa ma complic.
Pentru relatii one-to-one si one-to-many este ok Couchbase sau raman cu Postgresql+JSON?
Aplicatia va avea “useri”, “user”-ul va avea mai multe “dispozitive”, fiecare dispozitiv va genera loguri/rapoarte(cate o scriere la fiecare 5 secunde) ce vor fi afisate/downloadate de pe front-end.
Postgres e the safe choice, mongo e mai ok acum cu tranzacții.
Couchbase nu e straight forward de întreținut, chiar dacă pare că are un environment decent, nu șterge datele și îți crește utilizarea memoriei exponențial de vrei, de nu vrei.
despre ce date vorbesti, ce anume nu sterge? Pana acum am auzit de bine despre el, chiar si pe proiectul de la munca se muta ceva din Postgre in Couchbase, tocmai pentru ca are ceva clustering built-in si e mai usor de scalat (tipul asta in cateva minute creeaza doua data-center-uri cu replicare in ambele sensuri)
Ma refer ca tot ce stergi cu remove de fapt se marcheaza deleted=True, desigur poti face purge periodic dar va mentine metadata 3 zile pentru replicare.
Eu sunt direct impotriva Couchbase, e varianta comerciala la CouchDB, API compatibil din cate imi amintesc. Am studiat acest sistem un anumit timp si mi se parea interesant.
Poate isi permite o firma uriasa sa mute cu asistenta date din Postgres in Couchbase, nimeni altcineva nu are nevoie si nici nu isi permite complexitatea uriasa pe care o presupune couchbase. O fi simplu dintr-un video si screenshot-uri, dar cand ai o problema si iti trebuie documentatie sau vrei sa intelegi sistemul ai dat din lac in put. Documentatia la couchbase nu imi inspira deloc incredere cu exemplele lor de ruby si php fara code highlighting.
