MongoDB Pro și Contra

Asa se apar noi topic-uri din off topic-uri la fel cum a aparut si acest vs. :smile:

si ca sa revin on-topic: To what extent are ‘lost data’ criticisms still valid of MongoDB? interesant acel bug din 2013

Lets add some gasoline on this versus: “Postgres Outperforms MongoDB and Ushers in New Developer Reality”[0]

[0] - http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-ushers-in-new-developer-reality/

3 Likes

Ok, but MongoDB still was more performant than PostgreSQL. I said it was, because since version 9.4 of PostgreSQL that became history: recent benchmarks show that PostgreSQL is now way faster than MongoDB dealing with JSON data types. I never compared PostgreSQL with TokuMX, but given that both are now more performant than MongoDB, I think you got my point here.

http://www.itexto.com.br/devkico/en/?p=60

2 Likes

Thread-ul in care Marian vorbeste cu el insusi :sunny:

2 Likes

blank answer :smile:

Interesant topic. Mai ales ca despre NoSQL nu am stiut mare lucru pana de curand.
Cat despre postul lui @dakull in care spune ca

Consistency / Mongo nu este ACID compliant - try doing joins and transactions in it and enjoy shooting yourself in the foot.

i.e. nu sunt consistenti nici macar in propriul FAQ (pun intended)

Redis in schimb il folosesc mai tot timpul fie ca un cache store, session store sau message passing.[quote=“alescx, post:1, topic:471, full:true”]
si uite asa o sa mai apara un rand de habarnisti care o sa foloseasca tehnologii pe care nu le inteleg doar pentru ca au citit ei pe undeva ca mysql-ul suge.
nu ma intelegeti gresit, mongodb si asemanatoarele sunt ok. doar ca exemplul cu blogul e extrem de neinspirat.
[/quote]

Daca ai in vedere ca MongoDB e mai mult pentru citit, cand iti faci structura, nu o normalizezi si nu te bazezi pe strategii valabile in SQL. Nu vei avea niciodata nevoie de join. Vei avea informatie redundanta la un moment dat, dar o citesti si o apelezi destul de usor.

Nu ca m-as pricepe… Ca nu am lucrat cu Mongo sau NoSQL. Dar daca as lucra, e evident ca e musai sa nu privesc problema cu abordare de DB relational. Iti faci design sa nu ai niciodata nevoie de chestiile specifice de SQL. Nu stiu cum as face, dar precis se poate. Iar aici, probabil e diferenta dintre cei care stiu sa foloseasca o tehnologie si cei care au auzit ca tehnologia aia exista…

Mie unu mi-ar placea sa aud parerile unora dintre cei care au folosit NoSQL si sa spuna de ce au facut asa ceva. Eu e clar ca raman pe MySQL. Ca de… fiecare paste iarba pe care o cunoaste.

Lucrez pe o baza de date MongoDB care nu a fost proiectata de mine, si intra-devar nu o proiectezi ca pe o baza relationala, nu o normalizezi la fel, desi am gasit mici exceptii cand exista referinta dintr-o colectie in alta pe baza unui ObjectId, ceea ce e echivalentul unui Primary Key in relational, asa zis-ul JOIN il faci din back end C#, nu am facut nici un curs pe MongoDB University, cel care a proiectat baza de date si cu care lucrez pe back end C# a facut cursul de DBA si Developer si si-a luat certificarile.