A da vidis sta tek Microsoft kaze o svojim platformama... Mongo moze da bude i skracenica od "for Mongoloids", if you know what I mean :-)

Da budem iskren dunno what you mean :-) Ali me zanima sta M$ ima da izjavi
na ovu temu?

Bilo bi korisno da analiziramo koje to industruje su vec prihvatile NoSQL
model i koliko to prednosti donosi na trzistu.

Trenutno imam jednu core aplikaciju koja upisuje podatke u MongoDB. Uskoro
testiram horizontalnu skalabilnost dodavanjem drugih node-ova tj. shradding
prema hash modelu.
Mislim da je za prljave podatke dinamicka shema sjajna stvar, kao i ceo
dokument orijentisani pristup naspram tradicionalnih RDBMS.

Ne mozemo se sporiti oko toga da je za prljave podatke dinamicka shema sjajna stvar, to je ocigledno. I to jeste veoma naspram RDBMS, koji pretpostavljaju da podaci ne smeju da budu prljavi. Sad razgovaram sa kolegama i neko priupita "A cemu sluzi baz u kojoj su podaci prljavi? Mora da ima neki catch u tome" :-)

Sta MS ima da kaze na ovu temu. Nista na ovu temu. Link koji si postavio je Mongo sajt i naravno da ce oni da kazu sve najbolje o svom proizvodu. To isto radi MS, samo je proizvod malkice drugaciji, zove se Share Point i ima donekle slicnu ulogu - documant manager i collaboration manager. Djoja, firme do sada nisu znale kako se kolaborira na poslu, pa ce sada SHare Point to da im omoguci i da ih nauci. KAd procitas o toma na MS sajtu, sve med i mleko, kad se pomeris malo dalje i slika postane malo drugacija, mleko s eukiseli a nije postalo jogurt.

Generalno, treba biti oprezan sa shemama tipa 'open concetpt, anything goes, no need for constraints of any kind' jer to lici na lekove za rast kose, svako malo pa se reklamira carobna vodica koja muskarcima vraca kosu koja ih je napustila.

U svakom slucaju, good luck :-)

Gde nadje ovu firmu ...Kada reklamiras MongoDB uputis na http://www.mongodb.com/customers ...

SQL i NoSQL su dva sveta koja lepo koegzistiraju svako u svome domenu. Nece nikad zameniti jedan drugog. Ako neznas zasta ce ti NoSQL - onda ti zaista i ne treba nimalo!

MongoDB nije jedini NoSQL ! Ko preferira Oracle u odnosu na MySQL, nece se zamajavati ni sa MongoDB. Ima Oracle igračku za takvu decu! Malo skupu , kao i sve kod Oracla. Čak ni u svetu free softvera, nije MongoDB jedini, ali je definitivno u ogromnom ubrzanju i mnogo obecava. Mnogo je love upumpano ovde. Cak i kod nas u Srbiji ima dosta programera koji zajahali na ovaj val ...

Mongo je jako zgodno resenje za neke stvari. Ja ga vidim, pre svega, kao perzistentni key-value store, pre svega za cuvanje velike kolicine kljuceva. Recimo drugi nivo kesiranja, gde je prvi nivo npr. Redis. Jako je zgodan za to.

P.S. Zgodan je i za druge stvari, naravno. Tipa, cuvanje i analiza npr. apache logova, posebno ako ti ne smeta da izgubis poneki podatak.

Koju firmu? MetLife?
Ako pazljivije procitas ceo prvi post videces da sam naveo i sajt MongoDB.

Ko je rekao da je Mongo jedini NoSQL? U naslovu stoji vodeci - izgleda si fail-ovao i naslov da procitas do kraja ali nema veze

"Ko preferira Oracle..." srecno mu bilo To nije tema ovde.
Igracke, mala deca? idi begaj sta nam naprica Evo idem da se stidim u cosku sto sam pipnuo Mongo.... oh izvini veliki Larry sto plovis svojom velikom jahtom po svetu i vodis Orakl, nece se ponoviti

Hajmo malo argumentacije na temu i realnih primera umesto ovakve price.



Tacno tako, paradigma RDBMS je da su podaci uredjeni i cisti. Ali sta kada imamo situaciju koja se dogadja dosta cesto u praksi a to su necisti podaci, raznorodne baze/izvori, a potrebna je konsolidacija svih izvora na jedno mesto? Cak i za proces ciscenja podataka se koriste NoSQL baze, pa ako se uspesno sve ocisti i poveze onda moze da se prespe u klasicnu 2D tabelu.


Link koji sam postavio nije samo Mongo sajt. Ima mnogo ozbiljnija analiza - case study u prvom linku, pogledaj vrlo je korisno.
Ja te potpuno razumem za M$, ali kinda njihova mantra je najjaca koju je svet ikada video (sad im Apple parira verovatno), ali ova prica oko Mongo i NoSQL proistice iz poslovnih potreba - dakle to je zahtev trzista.
MetLife je dve godine i kusur pokusavao da napravi ovo: http://gigaom2.files.wordpress...creen-shot_active-contract.png na tradicionalnim RDBMS, i naravno da nije islo jer se ispostavilo da je ETL proces konsolidacije i punjenja iz preko 70 raznorodnih izvorista nemoguca misija cak i u silikonskoj dolini. Zahvaljujuci promeni paradigme i upotrebom Mongo/NoSQL taj proces su pustili u produkciju za cca 3 meseca (kompletan deploy i obuka korisnika).


Naravno, ali zato se i radi testiranje Meni je MongoDB za konkretan projekat zavrsio posao kao nista do sada. View se renderuje na aplikativnom nivou, a u bazu moze da legne ama bas sve.







_{[Ovu poruku je menjao Mister Big Time dana 02.10.2013. u 09:14 GMT+1]}

A samo sam pokusao malo da rasirim temu i zainteresujem ljude koji nisu u ovim vodama. A ispalo je : ja sam rekao, a onda si ti rekao mada ja o tome nista nisam rekao ... Veruj da me ne interesuje leksicka analiza i dokazivanje da niko u Srbiji nije cuo za MetLife. Prihvatam i ne sporim da je 'vodeci'. Jel tebi problem da prihvatis da 'nije jedini' ?

Inace MS je advans partner MongoDB sto podrazumeva bar milionce ulozeno u taj brend.

I da, znam da niko nije rekao da Azure nije optimizovan za implementaciju MongoDB - izgleda sam fail-ovao i ovo da procitam do kraja ali nema veze ... odo i ja u cosak. :-)

Moj problem sa MongoDB-om je asinhroni rad, pre svega - i nedostatak pouzdanosti koju imam sa bazama tipa MySQL. E sad, sve dok u tome cuvam neke logove, gde mi je, realno, 99% sempl podjednako dobar, ili dok ga koristim za kesiranje - mongo je sjajan. Jedina zamerka koju imam je sto ne bi koristio isti za trajno cuvanje podataka, niti za smestanje bitnih podataka.

S'druge strane, popakujes u mongo, iskoristis ga za analizu, pa prepakujes rezultate - to radi sjajno i za to je fantastican! Planiram da uskoro probam i TokuMX, koji bi trebalo da je jos brzi, plus ACID compliant, sto zvuci apsolutno fenomenalno. Cekam na jedno 3 masine za lep replica set, pa da to malo ozbiljnije probam.

OK, napravi aplikaciju koja radi insert 100000 recorda u Mongo (može mali PHP script). Onda uradi isto za MySQL. Izmeri vreme izvršavanja i zauzceće resursa servera. Zašto je tako i zašto se svi kunu u Mongo, nije mi jasno...

Ljudi su lepo objasnili - koristis Mongo kad ti trebaju prljavi podaci i da nije mnogo pouzdan sistem.



Znaci, kad ti trebaju prljavi podaci, koji nisu bitni, i da nije mnogo pouzdano, ali ih jako brzo popakujes i analizras, ako ti ne smeta da izgubis poneki podatak. :-)

Ovo mi lici na deljenje s nulom u matematici. Ako dozvolis da se deli s nulom, mozes da doakzes i da su bilo koja dva broja jednaka, sto je jako zgodno. Na primer, kreditna kartica ti je u minusu a ti dokazes da je u stvari u plusu, i posle se izgube ti podaci o minusu na kartici. Pa zar nije zgodno :-)

Nije BAS tako. Pazi, semplovanje je dobra metoda rada. Ako brojis konekcije, da bi stavljao limit, na primer - greska od 5% i nije toliko bitna. Ako radis analizu posetilaca sajta, za potrebe statistike, prodaje ili skoro bilo cega sem forenzike, opet, lepi rezultati stizu vec sa 10% semplom.

Pri tom mongo ne gubi podatke, osim u slucaju havarije. Samo radi asinhrono, pa moze da bude problem ako nesto pukne.

NoSQL baze su nastale pre svega da rese problem skaliranja upisa, posto je to jako tesko uraditi kod relacionih. Zasto? ACID.
NoSQL su zasnovane na drugom modelu, BASE (basically available, scalable, eventually consistent).

Samim tim je jasno da nisu pouzdane kao i relacione, i u tom smislu ne verujem da cete koristiti neko NoSQL bazu u banci na primer za transakcionu obradu - nisu za to ni pravljenje. Sa druge strane FB, twitter i ostale socijalne mreze su promovisale NoSQL kao resenje za problem skaliranja upisa posto to relacione nisu u stanju.

Aplikacije koje su profile centric (kao FB) vrlo prirodno cuvaju podatke u dokument based bazi, posto vi tu i nemate relacija, sve vam je nakaceno na profil. One relacije koje su izmedju profila mozete da cuvate u graph based bazi (Neo4j), gde imate daleko siru mogucnost search-a nego u relacionim. Imate jos dosta primera gde relaciona baza prosto ne moze adekvatno da odgovori potrebi, i tu ne govorim samo o broju upisa, recimo funkcionalnost koja je tipicna za web shop, korisnici koji su gledali ovaj proizvod su takodje pogledali/kupili i ovaj, ili sve one veze na linkedin-u...

Mongo recimo ne podrzava cross document transakcije, ali ako vam treba tako nesto - ili vam model nije dobar, ili vam mongo ne radi posao.

I za kraj, da spomenem da mongo ima i optimizovani store za velike/binarne fajlove - GridFS. Sa ovim dosta brzo mozete da napravite CDN resenje.

Sto se tice apache logova, ne znam koliki su fajlovi u pitanju ali ono sto sam ja video je uvek bio hadoop - znaci pricam o tracking pixelima za ad serving networks.

Uglavnom, NoSQL baze nisu tu da zamene relacione, stvorene su da rese odredjene probleme i limite relacionih baza gde neki od ACID principa ne moraju da budu 100% zadovoljeni.

mongodb je odlican sistem koji ima svoju nisu gde je odlican, najveci neprijatelji mongodb-a su ljudi koji pokusavaju da ga gurnu svuda (ista prica je i sa mysql-om i pgsql-om i sqlite i .. guranje mysql-a npr tamo gde mu nije mesto je ucinilo mnogo loseg za isti te mu onda npr osporavaju i ono u cemu jeste mnogo dobar, ista prica i sa ostalim open rdbms ) .. mnogo je poznatih primera gde je nosql probao da zameni rdbms pa su posle 2 godine ulaganja ogromne kolicine vremena i para na kraju vratili staro resenje .. da ne spominjem problem ljudi koji guraju i reklamiraju mongo bez dobrog poznavanja istog, mongo "moze" da cuva prljave podatke (vidi moze i bilo koji rdbms, stavis mu autoinc key + blob i eto, cuvas prljave podatke, eno ti ga mysql ima rest interface, memcached interface, mozes da pricas sa njim kao sa bilo kojim key-value store sistemom pa opet ne moze da zameni mongodb tamo gde je mongodb-ova nisa kao sto ni mongodb ne moze da zameni rdbms gde god ti je potrebno bilo koje slovo iz ACID skracenice) i u tome je isto los koliko i bilo koji drugi database system (npr mysql ili pgsql sa autoinc/uuid + blob ) ... prednost nosql-a, posebno mongodb-a je ako imas poznatu strukturu (dakle vrlo suprotno od "prljavih podataka" i "no-schema" arhitekture) onda moze da bude extremno brz i extremno skalabilan i extremno koristan ... u varijanti kada su podaci prljavi i bez seme onaj ko je dizajnirao sistem treba da ide malo u skolu i nauci kako se dizajniraju sistemi a ne da pokusava da napravi novu tehnologiju kojom ce da izleci svoje neznanje

dakle ako treba da cuvas "prljave podatke" - lose si dizajnirao sistem i niti ce ti pomoci nosql niti bilo koje drugo softwersko resenje, problem treba da resis prvo izmedju stolice i racunara ..

inace sto se tice toga da je mongodb vodeci nosql ne znam po kom kriterijumu je vodeci? nije prvi, nije najnoviji, nema najveci broj instalacija (tu ga sije memcached za par redova velicine), ne drzi najvecu kolicinu date u sebi (tu ga komercijalna resenja siju isto za par redova velicine), ne zaradjuje najvise para, nema najvise developera koji ga prave, nema najvise developera koji ga koriste, nema najbolje performanse, nema najveci/najsiri dijapazon funkcija, nije u njega upucano najvise para..?!?!?! u cemu vodi? mongodb je kao nekad amiga, on se ne koristi on se voli .. ima grupu extremno fanaticnih sledbenika koji mu cine mnogo vise stete nego koristi ...

Amin! Recenica za pamcenje!

Znaci, svaku si mi uzeo iz usta. Prosto je neverovatno koliko iracionalnih zahteva za MongoDB dobijam na projektima, da je to otislo van svake pameti. A sve neki priuceni web developeri, reko bih boze me sacuvaj da nisam ateista.

Zasto svi polaze od permise da su oni koji razvijaju neki softver/sistem i vlasnici podatka? Ako covek sam pravi sve od nule normalno da mu ne treba ni Mongo ni noSQL... ali sta raditi kada dobijate tudje djubre od podataka koje morate da obradjujete? Neko je rekao BLOB, dodao bih moze i JSON unutar jednog polja... a to je pa silovanje klasicne SQL baze.



Verovatno da ima i toga. Meni su npr. svojevremeno trazili da jedan sajt male firme bude izradjen iskljucivo u Java tehnologiji (JSP). Kada smo ustanovili realne potrebe, njima je i PHP sajt bio misaona imenica jer su imali najprostackiju staticku html prezentaciju bez DB-a.
To je ono - vidl'a zaba...

Sa druge strane ako je zahtev - objedini 70 izvora podataka gde je mozda jedan jedini elemenat moguca veza izmedju svih izvora (npr. JMBG), ne znam kako bi to moglo lako i brzo da se uradi bez Monga :)

ako ne znas sta je u podacima ne mozes da ih obradis abitno od toga koju tehnologiju koristis za cuvanje istih




cuvanje date u mongu bez strukture tih podataka ne pravi nikakvu razliku u odnosu na to da si ih stavio u sql unutar blob/text/json polja



isto kao sto se to decenijama radilo pre mongo-a, napravis predprocesor za svaki izvor

Slažem se sa svima koji tvrde da sy SQL i NoSQL rešenja koja tretiraju različite oblasti i tako ih treba i posmatrati.

Pošto je tema MongoDB, ja ću sada pričati o njemu i njegovim dobrim stranama bez prejudiciranja preferencija prema MongoDB ili MySQL, dakle, statusno neutralno :D *bljuv*.

Ono za šta je MongoDB dobar je skoro svaka interpretacija realnog sveta u digitalnom svetu. Dakle sve što ne predstavlja strogo struktuirane podatke, a to je gotovo sve osim bankarstva i finansija je dobro predstavljati u MongoDB jer je koncept kolekcija i dokumenata mnogo bliži ljudskom (barem mom, ako ničijem drugum) poimanju sveta nego (My)SQL.

Ono za šta je MongoDB odličan je kao baza podataka za društvene mreže. Tu SQL nema šta da traži. Najbolji primer je foursquare.com koji koristi MongoDB. A tu je on posebno zgodan pošto ima ugrađen geo-tagging, što je osnovna priča kod 4sq.com

Ono što će lansirati MongoDB u web svetu je Node.js, a posebno Meteor.js . Kod Meteora ima jedna fantastična stvar, a to je što i client side i server side i DB govore isti jezik - JavaScript. MongoDB-ov native jezik je JavaScript. Ko ne zna šta je meteor.js, neka obavezno potraži i neka odgleda demo video - to je fantastično. Vi iz frontenda tražite podatke direktno iz baze koja vam šalje nazad javascript objekat. Tu ste preskočili nekoliko koraka transpozicije podataka iz strogostrukuriranih tabela, u npr. PHP objekte, pa odatle u JSON, pa to šalji u frontend, pa onda tamo izvlači i rendaj HTML.

Tu na scenu stupa takozvani MEAN stack, koji zamenjuje LAMP, odnosno WAMP stack. MEAN je MongoDB, Express.js, Angular.js, Node.js, pogledajte www.mean.io
Kada imate na umu da je Angular.js Google-ov proizvod koji se intenzivno razvija i Google celom težinom stoji iza njega. Angular vrlo lepo sarađuje sa Node.js i Node.js se najčešće koristi kao backend za Angular.js, a Node.js opet najbolje funkcioniše sa MongoDB jer pričaju istim jezikom.

Sve u svemu, voleli vi MongoDB ili ne - it's here to stay i biće sve veći igrač na tržištu - budite uvereni u to.

da bre, mongo je WEB SCALE ;)



zato je najveca drustvena mreza na svetu pored stotine miliona dolara ulozenih u nosql resenje bacila isto i vratila se na RDBMS, zato je druga najveca drusvetva mreza na svetu posle ulozenih desetina miliona dolara i full prelaska na noSQL resenje odbacila isto i vratila se na staro RDBMS resenje, i zato je treca najveca drustvena mreza na RDMBS-u ?!



mongoDB ima mnogo dobar mnogo brz geo-tagging, skidam kapu, mega dobro resenje (jedan od razloga sto ga koristim u nekoliko projekata)



ah ti si od ovih "programera" sto "kompajlira" svoj kod u javascript ... to mnogo govori



a google je inace poznat kao neko ko open source zajednici nesto daje a ne iskoristava istu za svoju cistu dobit?! i ne radi na tome da aplikacije prebaci komplet u SAS rezim sa varijantom ako je nekako moguce da ih oni hostuju a da se izvrsavaju na njihovim thin klijentima .. to sto su te aplikace za 2-3 reda velicine sporije i trose 2-3 reda velicine vise resursa nego sto je potrebno to neme veze, klijenti ce da plate i resurse i retardirane skirptere ubedjene da znaju "da programiraju"



niko to ne spori, mongoDB je odlican sistem koji ima vise nego veliku upotrebnu vrednost i naravno da je tu da ostane kao i cela gungula drugih noSQL resenja, sto komercijalnih sto open source... komercijalna resenja su tu odavno, sada se mongo sa ekipom prikazao kao uporediv open source projekat sa zavidnom funkcionalnoscu i performansom .. cak je istina (tuzna i zalosna) da ce sve vise aplikacija koristiti to smece od javascripta no sta je tu je .. a i nije tema .... za mongo, to sto radi radi extra, ja sam za sada vrlo zadovoljan, no bojim se da ti imas manjak znanja oko baza podataka te da svojim komentarima doticnom pravis vecu stetu nego korist .. mozda gresim ali iz ovog tvog komentara se tako da zakljuciti

Ja inace upravo razmisljam da li da nekome preporucim mongo za storage dokumenata, umesto nfs-a. OK, ne mongo, toku i to verovatno ne jedan vec neki lep replica set, ali sve jedno, slican princip.

Razmisljam da mi je mongo bolje resenje, ako ne mogu da imam pristojan storage u doglednoj buducnosti. Cisto mi treba nesto kao CDN, ka internom sistemu, pa razmisljam....

Ne znam čime je ovo izazvano i šta je imalo za cilj, ali nije vaspitano.



Šta Gugl radi ili ne radi, i da li nekoga iskorišćava je : a) njihov problem; b) stvar pogrešne percepcije i potpunog neshvatanja kako funkcioniše kapitalizam kome imamo da zahvalimo ove uređaje koje koristimo da bi se dopisivali preko ove mreže koju takođe imamo da zahvalimo kapitalizmu.



Tačno je da nisam ekspert za baze podataka, ali kao što sam i rekao u prvom postu nije mi cilj da promovišem ovu ili onu bazu, jer niti živim od toga niti me baš briga. Međutim jasno je da ti živiš od Oracle/MySQL, prema tome jesi stručnjak za baze, ali nisi objektivan da sudiš o tome koja je bolja.

nisam imao nameru da vredjam, no malo me iritira javascript i ceo koncept kompajliranja u javascript i javascript app servera i celog extremno pogresnog hype-a vezano za isti


kako nema veze? ti si rekao da ga google podrzava i da to nesto "Znaci", to sto google nesto podrzava danas sa 100% niti znaci da ce da ga podrzava sutra niti znaci da to nesto valja .. vrlo cesto se google pokusava predstaviti kao opozicija zlom zatvorenom microsoftu, pritom je google zatvoren koliko i microsoft i zliji i komercijalniji od microsofta ... dakle ima veze, kako nema .. to sto google nesto podrzava nije nista pozitivnije nego da ga podrzava bilo koja druga firma


vidis ti ne znas sta ja radim :D, ja actually zivim od noSQL-a (mysql cluster je nosql baza i kao takvu je koriste i alcatel lucent i nokia siemens network i ericsson i mnogo drugih telco-a, banaka etc etc .. mysql server je rdbms koji ume da koristi razne storage sisteme pa kao jedan od njih moze da bude i mysql cluster te se onda mysql clusteru pristupa kroz SQL interface ali to ne cini mysql cluster rdbms-om isto kao sto ni memcached interface za innodb ne cini innodb key-value/nosql storage sistemom), mysql server kao rdbms znam koliko i postgresql, mssql, sybase, db2 etc etc .. iz visedeceniskog rada sa istim ... placaju me da budem objektivan, ne da vucem na ovu ili onu stranu (sadasnji poslodavac ima i rdbms i noSQL resenja i vrlo lepo naplacuje i jedna i druga)... a ne placaju me da pisem na forumu te ovde predstavljam sebe a ne njih ..

no nisam tema ni ja, ni oracle ni mysql cluster, ni rdbms-ovi an general vec je tema mongo, ti ako sumnjas u moju objektivnost slobodno to sto sam napisao opovrgni cinjenicama. ja sam to sto si ti napisao stavio u kontekts sa cinjenicama ..

Meni ova javascript hype prica mnogo, ali mnogo potseca na slicnu vezanu za ruby on rails pre par godina. Mator sam, sta li je.

Neke stvari su jako dobre. Doticni node.js je odlicno resenje za neke stvari, ali nema nekih velikih prednosti u odnosu na python twisted, ili neko resenje za php. Ima tu dobrih tehnologija, ali ubi me hype, ogadice mi i ono sto valja...

to je najveci problem novih tehnologija .. fanboys .. najveci
neprijatelji svojih fanova .. npr za mongo, ja sam pratio razvoj istog
sa podsmehom i vristao od smeha na fanboy price, a 99% prica je bilo od
strane istih .. da bi u nekom trenutku bio prisiljen da se sretnem sa
istim oci u oci i vidim sta to i kako stvarno radi te skonto da je
mongodb u stvari extra stvar, samo ako ga koristis za sta je namenjen i
izignorises armiju retarda koji pricaju gluposti .. potpuno ista prica i
za mysql i fanboy klub, linux i fanboy klub etc etc ..

mora se uzeti u obzir da je mongo dizajniran nekoliko decenija posle
SQL-a da resi probleme sa kojima se SQL bori i da nije opterecen
nikakvim standardom pri osnovnom dizajnu.. realno uzimajuci u obzir te
dve cinjenice mongo je trebao da bude znatno bolji.. razlog zasto nije
(isti problem sa kasandrom) je sto je neko ko ne zna dovoljno sql probao
da resi problem svog neznanja novom tehnologijom .. tako da tu ima nekih
odluka koje nisu najbolje i nekih projekata koji su skupo kostali nosql
open source community .. no sta je tu je, i dalje je to mlad community
koji i dalje moze vrlo lako da odbaci bilo koju premisu i promeni
arhitekturu sistema na bilo koji nacin ako se za to nadje potreba posto
je user base dovoljno mali i dovoljno agilan da bilo koju promenu moze
da proguta... to je ono sto je najveca prednost mongodb-a, kasandre i
ekipe .. ja licno ocekujem da ce upotrebna vrednost a samim tim i broj
instalacija da raste exponencijalno narednih par godina

@Bogdane, jel mozes ti da kazes za koje namene je Mongo odlican? Vise si puta si rekao da je za odredjene stvari extra, ali nikako da kaze za sta, a bilo bi korisno od nekoga poput tebe cuti to. Hvala!

@ivan.mojsilovic, nemoj pogresno da me shvatis, nije moje misljenje nista validnije od nkrgovic ili mist ili bilo koga drugog ko je pisao na ovoj temi. profesionalno ima ovde mnogo vise ucesnika cije misljenje o ovom problemu treba da ima mnogo vecu tezinu od mog.. moj "posao" je daleko od toga da mogu da sudim o kvalitetu i upotrebnoj vrednosti bilo kog data storage sistema bio on big data ili sql ili nosql, key-value etc etc, dakle moje misljenje je zasnovano ne na "poslu" vec na onome sto radim u slobodno vreme ... a ima ovde ljudi koji koriste i rdbms i nosql za leba te bih njima mnogo vise verovao (tako sam i krenuo da koristim mongo za neke svoje projekte verujuci tim ljudima) ... ja sa @mist diskutujem (vidim da se nasao uvredjen, nisam siguran zasto) ali ne odbacujem njegovo misljenje, on je rekao nesto, ja sam dao protivargument, ako on ima argument da potvrdi svoju tezu ja sam vise nego rad da je cujem i nesto naucim, on ili bilo ko drugi .. tako da gde je dobar, mogu da ti dam recimo 3 projekta za koja mislim da je idealan, dva moja i jedan veliki globalni, no to je opet moje misljenje zasnovano na limitiranom iskustvu bavljenja tom problematikom (monngodb) "usput", ako ti koristi super ali nemoj to da uzimas kao informaciju prve klase

1. kreglista, oni momci imaju cca giga podataka dnevno koje moraju da arhiviraju (stare vesti). live vesti su im u sql-u i tu po njihovom ( a i po mom ) misljenju, za sada, mongo nema sta da trazi, ali za arhivu, koja se pretrazuje sporije i na drugi nacin, nosql tj. u ovom slucaju mongodb, je odlican sistem za cuvanje te date

2. sistem za vertikalnu pretragu, inicijalno je bila ideja da se ovo radi sa nosql (druga velika firma koja to radi koristi nosql za isti posao) ali sam ja rekao da cu da postignem min 10x vecu brzinu na 10x manje servera (iliti 2 reda velicine manji utrosak resursa za isti kvalitet servisa) ako stavimo sql, dobio sam odgovor da je to nemoguce posto su "oni drugi probali" .. ti "drugi" nisu znali da organizuju sistem i sa nekim usputnim savetima koje su dobili su ubrzali svoj sistem nekoliko puta da bi na kraju batalili sql i presli na nosql .. elem ja sam dobio "sansu" da uradim to sa mysql-om i napravili smo sistem koji je ne samo bio za 2 reda velicine brzi nego je imao i funkcionalnost koju ovi drugi nikako mogli da naprave (radi se o count(*) group by x; sto sql uradi iz ... a nosql da bi to radio u nekom realnom vremenu nad 20-30 kolona u bazi, moras da rodis mecku) .. to je recimo tipican primer gde je neko resio problem sa mongom bolje nego sa sql-om zato sto nije znao da napravi resenje sa sql-om a ne zato sto mongo bolje resava taj problem ... elem za taj sistem je potrebno logovanje svega zivog, ko je dosao na sajt, odakle, gde je klikno, to sto je klikno dal je filter ili rezultat ili .. ako je klikno na rezultat pretrage koja strana, koji redni broj rezultata, ako je klikno na outlet koji je outlet, dal je klikno na bustovan rezultat ili na regularni .. svi podaci njegovog browsera etc etc ... ta tusta i tma date se cuva u mongodb i odatle se ta data izvlaci (povremeno) i iz nje racuna razna statistika .. citanje te date je prilicno sporo ali realno mongodb je idealan sistem za cuvanje takve date.. moglo je to jos malo bolje da se odradi, tada kada smo radili nismo imali dovoljno iskustva sa mongom, ali svakako sledeci put kada budem radio neko logovanje tog tipa, obavezno mongodb (mozda kassandra no za sada ipak mongo)

3. sistem za oglasavanje (recimo personals), u startu je tim bio za sql a ja sam (za cudo svih) bio za to da idemo na mongo, osnovni razlog za mongo u ovom slucaju su spatial indexi koji rade brze od mysql/pgsql za 2-3 reda velicine!!! uz neka teska budzenja pgsql smo naterali da bude blizu (samo 2 puta sporiji) u nekim slucajevima .. te je inicijalna ideja bila da mesamo mongo i sql no ipak je reseno da se ide 100% sa mongodb posto denormalizacije date ne pravi preveliki problem, gro date bi ionako bilo u nekom blobu a mongo u poslednjih par verzija podrzava indexe te tih par atributa koji su morali biti denormalizovani ne predstavlja za mongo nikakav problem .. jeste malo cimanje sa "samo jedan index" pricom ali ima i za to resenje ...

'nough said :)

btw za kreglistu, vrlo poucan video:
http://youtu.be/a25tBrQCs1Y

Nije MongoDB resenje svih problema :) ima on i tekako svojih mana. Odlican je kad na brzaka treba da dodas neko novo polje jer ne moras da molis DBA da uradi alter table-a. I sto s obzirom da je dokument based od jednom procitas sve sto ti treba i tu dobijes ubrzanje jer ne radis nekakav join. Ili ako treba da uradis neki dinamican query da radis neku novu vrstu pretrage koju nisi do sada radio. I zgodan je zbog samih kljuceva tj shardovanja kolekcije. I drugovi omladinci tu svaka lepota prestaje.

A da mu pogledamo mane ?

Velicina polja moze da bude problem sa mnogo strana drasticno moze da poveca zauzece diska, tj da samo ime polja bude duze nego pravi podatak., query takodje mogu da budu veoma spori bas zbog tih istih duzina polja, je mongo ne moze da koristi optimizacije nad jednom rekordom kao sto to sql elegantno radi. Pa onda da bi resio problem taj problem kreces da imenujes svoja polja sa jednim ili dva slova, drugim recima zarad optimizacije samog mongoa ti sam sebi obsfrukujes bazu. Pa onda takodje da bi brze pretrazivao neki put sam vestacki pomeras polja u pod objekte.

Pa idemo dalje putem perfomansi, kukala mongu majka kad mu index vise ne staje ceo fizicki u ram memoriju. Tad krece jad cemer i tuga.

Pa onda opet mozemo da se vratimo na velicinu baze, mongodb ne radi kompresiju dokumenata, pa i vrapci na granama iz big data sveta (hadoop i kompanija) znaju da kad treba da obrade veliku kolicinu podataka da ce to sve ici mnogo brze ako se koriste neki algorimi koji "solidno" kompresuju a brzi su jer vreme provedeno na citanju manje kolicine podataka plus dekompresija traju krace nego citanje vece kolicine podataka.

Prvo, to da treba da "molis" za alter nije posledica toga ko je DBA, vec toga sto to traje. Drugo, to sto je "dokument based", ne daje ubrzanje, to si se ti nesto presao. Moze i sql upit da nema join - i da, onda radi brze. A moze da radi brzo i kad ima join. Ovo sve lici na to da tvoj DBA nije bas neki, ili da vam sql i ne ide, nhf. I da, mysql ima particionisanje tabela. :D

Sa druge strane, imenovanje kljuceva u key-value store-u, bar po meni, ne treba da bude human readable, a kamoli dugacko. Tipican primer je session storage - kad je SessionID bio human readable. To nije, bar meni, mana monga. Nije on za citanje "na ruke".

Kompresija i RAM, to stoji. Mada, opet, ni MySQL nije srecan ako ti je InnoDB Buffer Pool manji od 10% tablespace-a. Ja to imam na nekim sandbox okruzenjima, baza 150GB, memorija 2GB - i to je isto JAKO sporo. Kompresija.... e to je boljka koja i meni ide na zivce. :D

za sistem koji je dizajniran "pre neki dan" stvarno je cudno da mongo ne ume da koristi bar neki brzi lzw ili lz4 ili tako nesto .. odavno smo svi svesni da su nam db serveri overloadovani na IO delu dok proecsori lade jaja 99% vremena... takodje vezano za brzinu i nove tehnologije, vrlo je cudno da sistem dizajniran "pre neki dan" ne ume da koristi 2-3 level cache, danas sa mega brzim ssd diskovima koji su beskorisni za cuvanje velike date (previse $$$) doticni extra dobro mogu da rade kao 2nd level cache.. svi filesystem-i dizajnirani skoro umeju to da koriste, vrlo cudno da nijedan od novih "document storage" sistema to ignorise ... etc etc .. ima tu jos mnogo stvari koje bi covek ocekivao od monga, kasandre .. a koji ne postoje, koji bi ih ucinili znacajno upotrebljivijim .. sad, moram da priznam da nisam pratio worklog entries za mongo/kasandru pa ne znam da li je tako nesto planirano vec ili ne ..

secam se kada je krneta pricao pre 20tak godina kako je alfa sa 64 bita resila problem baza jer ce ram da bude mnogo jeftiniji te ce cele baze da sede u ramu, ono cega se tada nije setio je da ce velicina date koju cuvamo rasti mnogo brze nego sto padaju cene rama ..

elem, nadam se da ne smaram sa klasterom u mongodb temi ali bas upravo nesto diskutujem sa kolegama, ono sto mccge recimo vec resava a ima i transakcije i relacije i ...

- Sharding
- Cross-shard transakcije (nema nijedan od ovih open source dokument storage sistema tipa mongo, kasandra..)
- Pushed down predicate filters / programs ( nema nijedan od ovih ..)
- Pushed down joins / Adaptive Query Localization (ovi nemaju ni join a kamoli pushed down joins)
- Cross-shard consistent backup (ovo nisam siguran kako se radi sa mongo/kasandrom)
- Online resharding (ovo mongo ume ako sam ja dobro svatio, nisam probao doduse)
- Pruning of cross-shard scans to single shards (nisam siguran kako ovo radi mongo ali mislim da ne radi ovako brzo)
- Distributed transactional DDL (recimo da mongu ovo nije problem)
- Batched cross-shard parallelism (ne znam da li ovo mongo ume, realno bi trebalo da ume)
- Synchronous replication (ovo nema nijedan od ovih ...)
- Automatic Failure detection, failover and recovery (ok ovo bi trebalo da radi sa mongom jedino sto je sa ndb-om data uvek accessible a sa mongom je eventually accessible sto je ogromna razlika, na ndb-u ako crkne jedan nod sva data je up to date i dostupna)
...

pricamo o sistemu (mysql cluster) koji je dizajniran da rani na ruterima, PC racunar tada nije bio dovoljno stabilan da tera tako nesto, dakle pricamo o vremenu pre 20+ godina .... realno je ocekivati da sistem koji je dizajniran pre neki dan prevazidje 20+ godina star dizajn ...

MongoDB je vrlo zanimljiv koncept i treba ga probati i koristiti ali ne po svaku cenu.

Licno mislim da strogo definisane strukture ipak imaju prednost, nema "prljavih" podataka i tacka :)

To me je licno u gomili primera prilicno nerviralo kada sam imao potrebe recimo za Array data type u MySQL.
Sto to dan-danas nije napravljeno (ima nekih ne-oficialnih ekstenzija ali to ne racunam) !?
Kasnije kada sam to morao da "normalizujem" ipak se ispostavilo da mi nije ni bio potreban takav tip polja.

Znaci treba samo da se debelo zamisli i lepo izprojektuje struktura DB, "veza sa ovim je u vezi sa onim" i to je to.

Skoro sam radio neku APP sa preko 150 tablica (sve custom), bez obzira sto to izgleda komplikovano, tu mi je sve skockano kako treba, bas me briga da li cu da koristim ili necu JOIN, meni je bitno kada ja "pitam" bazu da ona meni vrati tacno to sto sam hteo.
Struktura baze se jedva sitno ostampa na A3 format, ali lepo nacrtano sta je sa cim povezano i to stoji na zidu offica :)

Jedino je malo pitanje oko skalabilnosti, mada to nije pitanje mogucnosti MySQL engina-a vec necije upucenosti u celu problematiku i poznavanja tih stvari.

Evo ta APP radi u privatnom cloud-u (kolokacija 10-ak servera), milionska poseta, integrisna sa Amazon CDN i to fercera samo tako, trunke problema bar oko DB nismo imali. Jedino kad mi neki od developera buta po strukturi dodajuci neka polja a ono se zakuca sve, posle kad pogledam sta je uradio "zavrcem ushi" jer nije stavio index na polje :)

ima dosta rdbms-a sa array tip poljem (npr pgsql), znam da su nasi
developeri vise puta pricali o implementaciji toga u mysql .. tako da to
jeste nedostatak mysql-a, to moze da se zaobidje ali je vrlo korisna
stavka :D ... jos neki nedostaci su vrlo nezgodni, isto mogu da se
zaobidju (npr group by je vrlo limitiran na mysql-u u odnosu na oracledb
ili pgsql etc etc ..) ali jbg, ne mozes da kazes da ne trebaju :D ..
"tako smo hteli" je prolazilo pre 15 godina, danas bas i ne prolazi :D

To sto je document based, daje ubrzanje kada je u pitanju IO, sam IO sa hard diskom je botleneck svake baze podataka. cukni neki hdparm pa pogledaj koliko ti je pisanje a koliko citanje sa diska, a koliko je spooooooooooooooooooooooooooor random seek. Imajuci to u vidu da bi dobio brze perfomanse citanja, zgodno je da mozes da uradis randoom seek samo jednom , pa da procitas apsolutno sve sto ti treba u jednom cugu, to je upravo ono na sta gadjaju sve te scheema-less baze podataka. Niko ne kaze da ne mozes da denormalizujes sve tabele u svojoj bazi na SQL serveru, ali si ipak ogranicen ako moras da dodas nesto novo.

I da se razumemo naravno da ce ovaj sql upit da radi brze


nego mongov ekvivalent



iz prostog razloga sto mongodb mora da proverava da li je ime polja firstname, dok sql tacno zna gde se podatak nalazi u memoriji. E onda da bi tu ubrzao querije za mongoDb, brze je ako mozes da polja da smestis po drugim podobjektima, i trazenje polja svedes sa sa N na log(N), ali to je opet sporije.




Ja ne pricam o values, ja pricam o keys. Kljucevi treba da budu human readable, ako imam neku kolekciju i ako trazim nekog po imenu, hocu da navodim ime kljuca da bude "firstname" a ne da bude "fn" ili "f" i kada sam rekao obsfrukovanje baze na to sam mislio. Jer pisanje takvih querija je bolno i smorno i svodi se na to idi gledaj mapiranje obsfrukovanih polja.

I ja pricam o keys. Kad smestas sessions u key-value, sessionID je KEY - value je sve ono sto potrpas / serializujes u sesiju. I nope, nisu human readable.

Iskreno zivo me zanima da vidim takav dizajn baze gde u recordu ime polja bude sessionID, a ostatak nesto levo, po cemu indeksiras taj sessionID kad je ime za svako polje razlicito?

Kljuc. Ne ime polja, nisam bas kr*ten :) - samo vrednost. Key-value. Ako koristis mongo kao prost key-value, mozes da ih imenujes i kao a i b, tj. ako imas samo 2 poslja u jednoj tabeli.

Mozda to tebi zvuci cudno, ali ja bar na mongo gledam kao na dopunu rdbms-a, ne kao zamenu. Samim tim, u njega potrpam samo neke stvari, i to uglavnom vise kao key-value. Slicno kao sto bi koristio npr. memcached, ali naravno sa mnogo vecom kolicinom podataka - i perzistentnoscu.

Konkretan primer: Smestanje dokumenata. Imam dva polja, kluc i dokument. Indexiram po kljucu, koji je ID (a sifranik je u RDBMS-u), a dokument je, realno, BLOB (unutra je npr. serijalizovani json, ili sta vec....). Meni je to OK zamena za npr. NFS koji sluzi samo za smestanje dokumenata. Glavna prednost je brzina citanja i robusnost sistema. 3-way replica set od 3 off-the-shelf servera (ili VM-a) kosta manje nego dobar storage (tipa EMC), a radi isti posao.

@nkrgovic, ako ti treba key-value gde ti je storage "create table t (id
bigint/uuid/stagod not null primary key, content blob/text/stagod)" a
upiti "select b from t where id=konstanta" onda ti je ndbcluster majka
mara .. ne postoji brze resenje na planeti a pitanje je debelo da li
postoji resenje koje je stabilnije/robusnije ... cak i ako picis to kroz
sql nije sporo, ako picis kroz memcached interface (ndb ima isti i
zaobilazi sql kompletno) to je jos brze a ako ti je app u nekom
"podrzanom" jeziku (c/c++/java) mozes direktno da picis ndb-api i onda
je to smrzavanje .. ndb-cluster drzi normalno datu u ramu ali ti mozes
da kazes da ti je kolona "content" na disku (index mora da bude u ramu,
za to nema mogucnost da ide na disk), performanse za takav use case su
neprehebive, pricamo o milionima upita nad terabajtnom bazom ..

Ok sad se razumemo, pricano u mongo terminologiji 1 record = 1 document = lista key/value parova, gde value moze da bude string, broj, array, drugi objekat itd..., e sad kad kazem kljuc mislim na ime polja. I da bi stedeo na prostoru i performansama querija prosto moras da imena polja drzis kratkima, sto same querije cini uzasnima i veoma necitljivima.

Nego da se vratimio malko na mongo, postoji new kid in the block, koji resava neke od ovih problema :) ali opet ni to nije resenje svih problema. Momci su generalno razvili malko drugaciji tree algoritam, koji je optimizovaniji kad je disk IO u pitanju. I nazvali ga fractal tree. U pitanju je Tokutek, imaju engine za mysql i imaju fork MongoDB-a kunu se u neke nenormalne perfomanse, iako im fale neke opcije koji ima mongoDB kao npr 2d geo indexi.

Imacu to na umu! Videcemo ima li sanse odma, ako ne - onda bar kasnije, kao refactor.



Ako bi pogledao moju poruku koju Bogdan komentarise u postu koji sam ja citirao iznad - videces recenicu "OK, ne mongo, toku". :D Iskreno, svi moji planovi vezano za mongo idu ka tome da se koristi TokuMX, a ne default mongo implementacija. Evo i jedan od mnogih linkova, sa bloga koji citam skoro svaki dan:

http://www.mysqlperformanceblo...tokumx-is-mongodb-on-steroids/

vadim je mnogo zeznut lik tako da njegova pohvala bas mnogo znaci "nosql
got level up" je .. od njega .. leleeee ... no ovi momci stvarno kidaju

meni na zalost geo treba mnogo ..

U istoj smo kanti :)

mada pazi, ja se secam kada se pojavio ibd, falilo mu je par sitnica,
cim je nastala potreba za to resile su se, evo do pre neki dan nije imao
FTS, realno nije bila frka, onda je neko rekao "koji je osnovni razlog
zasto ljudi koriste myisam" mi uradili istrazivanje 3 meseca i puf,
jedini razlog (tipa 0.1% ima neki drugi razlog) je full text search ...
i sta uradimo, napravimo fts da radi i na ibd .. garant su ovi momci u
slicnom fazonu, mongo satire geo, nemam pojma kako su ga uradili tako
dobro, sad zamisli ako ovi ludjaci sa fraktalnim indexima i kompresijom
sednu da mozgaju kako da ubrzaju spatial :D ima svi da pevamo :D

http://nyeggen.com/blog/2013/1...e-genius-and-folly-of-mongodb/

Webscale :D

yup. bilo kakva ozbiljna prica nad "The global write lock and the non-durable un-verifiable writes" pada u vodu no lagano, postoji velika sansa da ce od svega toga biti nesto :)

More rant :)

http://pastebin.com/raw.php?i=FD3xe6Jt

Why MongoDB is worth $1.2 billion
http://www.infoworld.com/d/app...ongodb-worth-12-billion-228510

To what does MongoDB owe its success? Oracle! That's right, Oracle is the best thing that ever happened to MongoDB.


Big red legacy
Oracle has many great advantages, beginning with an entrenched installed base. Many internal IT applications are written in Oracle's stored procedure language PLSQL.

But Oracle is not fundamentally different from the database I learned to love and hate in the mid-'90s on HP/UX PA-RISC boxes. In fact, it hasn't fundamentally changed since the '80s. Legacy is great and terrible at the same time. Oracle requires a lot of hardware and a good amount of support staff to keep running. It also does not affordably scale to the tens or hundreds of terabytes required by some -- or the millions of users required by others.

To scale in that way, Oracle would need underlying software architecture changes. Oracle is trying to address this by bolting other technologies onto its RDBMS, but as I've said before, this is a little like stapling a goose to a Mack truck and calling it an airplane.
Moreover, that sort of scaling requires a fundamentally different license model. This is difficult to do without cannibalizing your existing market.

Why The MongoDB Hate?


http://yourstartupsucks.com/post/12416816599/why-the-mongodb-hate



P.S. Juce probih broj od milion dokumenata u bazi :)

ovaj tekst koji si linkovao podseca jako na montijev tekst od pre 10tak godina kada objasnjava kako je mysql najbolji na svetu i kako samo retardima i losim programerima trebaju constrainti / strani kljucevi a kako su transakcije "overrated" i kako svaki dobar programer zna kako da ih zaobidje i radi bez njih ... ili takodje montijev tekst istih godina, gde odgovara na napade kako pgsql ima full sql sintaksu a mysql podrzava samo malecni subset sql standarda, kako je left join nepotreban i kako subselect koriste samo retardi a kako su stored procedure zlo koje niko sa 2 grama mozga ne treba da koristi ... pa evo ga sada mysql ima i transakcije i strane kljuceve i subselect i ... i vise ni monti ne prica to u sta se kleo pre 10tak godina ... tako i ovde

to je bukvalno prica sa myisam i table level lock, nije problem radi web vec skoro 20 godina sa tim, ima samo jedan problem to se ne skalira i to je neverovatno usko grlo za bilo kakav write heavy sistem .. kada mi neko prica za bazu projektovanu juce koja se navodno super skalira kako je global rw lock "design decision" i kako "not a big deal" dobijem sracku a taj je zavrsio za ceo zivot vezano za vrednost njegove reci ... da je prica "ok mongo sada ima global rw lock, znamo da je to zaheb ali jbg radicemo na tome da se to promeni" to je prica koja pije vodu, ali varijanta tipa drzi datu u ramu pa mozes da imas global lock je nevidjena glupost, pa turi svu datu u ibd_buffer_pool i preko toga stavi jedno od milion mogucih sharding resenja i imas sistem koji je za klasu brzi i stabilniji od monga sa armijom ljudi koji umeju da ga nameste, poprave... da ne spominjem da ako ces da drzis datu u ramu ndb je ACID + je brzi za 2 klase od mongo-a, razlika je samo sto za ndb nodovi moraju da budu u lanu a ne razbacani po internetu i kada dodajes nodove u klaster moras da dodas po noofreplica nodova, ne mzoes da dodas samo jednu masinu, i sto ne mozes da izvadis nod iz klastera (ima samo online add node, nema online remove node) ne znam da li mongo moze da izbaci nod iz klastera, mislim da moze

gomila drugih stvari takodje nema smisla tipa

ma nemoj, pa ako ides tom logikom onda ti je bolje da stavis lucene, imaces milion puta brzu pretragu :D ... ne mozes da kazes da ti je prednost to sto ne moras da mas strukturu a onda da kazes ali jbg ako ne napravis strukturu nista ne radi kako treba ... vracamo se na blobove u rdbms-u .. iliti u narodu poznato kao "nemos je jees a da ti ne udje"

jedina vredna recenica u tom tekstu je nesto sto ja inace non stop spominjem:





to se racuna u malecnu bazu za mysql ?! ako pricamo o onome gde mongo gadja trziste pricamo o big data, o terabajtima, milijardama dokumenata .. sa milion dokumenata ti ne treba ni skaling vec osrednji server i mysql ili pgsql i vozi misko

Nisam tako mislio, pogledaj smajlija Hteo sam da se 'pohvalim' da mi je to prvih milion zapisa u Mongu tj. necemu sto nije upravo MySQL koji konza za druge stvari


Why Can't This Be Love? Van Halen





http://www.mongodb.com/solutions

Solutions

MongoDB is a general purpose database suitable for most applications and use cases.

MongoDB is being used successfully by organizations of all sizes across all industries for web, mobile, cloud, internal and other enterprise solutions. A few of the more popular MongoDB use case examples include big data, content management and delivery, mobile and social infrastructure, user data management, data hubs and more.
Big Data

Big Data is creating new opportunities for organizations to serve customers and markets — while also creating and extracting value — in new ways. MongoDB provides the foundation for many of these systems, not only as a real-time, operational data store but in offline capacities as well. Traditionally, the work of capturing and analyzing data has required different technologies, different infrastructure and redundant costs. With MongoDB, organizations are serving more data, more users, more insight with greater ease — and creating more value worldwide.

:D :D :D ja nisam mnogo bolji, ja sam negde na 30tak miliona :D ... no to je bas patetican use case jos uvek :D

Ja vozim TokuMX i MongoDB u paraleli. TokuMX mi je primarna baza, a mongoDB ima kopiju kolekcija gde mi trebaju geoqueriji. I to za sada radi lepo.

5 Pitfalls to Avoid with MongoDB

http://forms.tokutek.com/acton...ts=1383771801922&id=e-0004

20. novembar

Bogdane, koji keyword obicno koristis @google trazeci negativne clanke
vezane za Monga? :-). Salim se malo, taj tip je koliko vidim pokusao da
mesa babe i zabe tj. tipicnu RDBMS i NoSQL bazu.
Ali dobro, bolje i da je probao nego da nije. ;-)

Kada uhvatim vremena testiracu horizontalnu skalabilnost kroz šreding.
Ako neko tu ima iskustava, neka javi, znam da config server masina ne mora
biti jaka.

stvarno mislis da mi je toliko dosadno da trazim to po gugletu :D .. to su clanci koji se pojavljuju na internim listama, na ./ i slicno ..

vertikalni skaling radi isto kao i bilo koje sharding resenje, zavisi od toga kako ti uradis i osmislis sharding ... automatski uglavnom ne radi

Mislim da su ovi iz diaspore zesce omanuli tj, pogresno su denormalizovali. Drzati sve postove unutar users tabele je zesci FAIL, ali NI EPIC FAIL mu nije ravan. Broj postova po korisniku konstantno raste a to znaci konstantan update nad users kolekcijom, a to znaci svaki post zahteva reparticionisanje podataka, znaci skolski fail u najavi. Plus citanje nekog usera, da li je stvarno neophodno da za svakog usera procitas odjednom za zadnjih 10 godina sta je pisao, naravno da ne.

Znaci ono sto ima smisla jeste da svakog usera kesiras recimo 30-40 postova. A sve to isto trpas u kolekciju postova.

nemoj da me drzis za rec posto ja ne bi nikad radio socijalnu pricu sa
mongo pricom, tj mongo tu moze da bude neki kesh umesto memcached-a
posto memcached nije persistent i to je to .. elem, mongo konsultanti
koji uopste nisu jeftini i od kojih, jeli, ceo projekat zivi, kazu bas
suprotno, kazu da bi u tom slucaju ti imao komentare po useru, po n
komentara u jednom slogu a onda lazy vukao te slogove iz baze ... tj ono
sto oni daju kao resenje je vrlo slicno onome sto je diaspora radila,
cak stavise, pre par godina su savetovali tacno to sto je diaspora
radila a sada savetuju neke male izmene... oni su imali po meni mnogo
fail-ova u tom dizajnu, prvo RAILS .. zako mi je jao ljudi koji se ne
slazu samnom ali to je jos jedan moderni bs hype koji na kraju dana
odnese mnogo vise vremena nego sto ustedi .. to je kao ovi sto u acess-u
pokusavaju da napisu erp software .. nije da ne moze ali .. c'mon be
real ..

da se jos jednom ogradim ja nisam expert za mongo, koristim ga na par
mesta gde mislim da dobro pase, cesto se vidjam sa mongodb konsulantima
zato sto je brdo naseg sales-a i sales konsultanata odbeglo u mongodb
(mysql je prilicno zasiceno trziste, nema tu mnogo novih firmi koje ne
znaju sta je mysql support i konsalting i zasto ga treba i nema tu za
sales mnogo para dok je mongo community u razvoju i nove ovc^?^?^?^?^?i
klijenti se pojavljuju non stop) te posto smo u dobrim odnosima i dalje
komuniciramo :D ... plus vece firme obicno traze drugo misljenje pa kada
im se prezentuje resenje sa X oni traze i Y i Z tako da se vrlo cesto mi
nadjemo u drustvu sa firmom koja nudi pgsql resenje i firmom koja nudi
mongodb resenje (i ne tako cesto m$not resenje) i onda mi svi vidimo sta
oni drugi pokazuju kako treba to uraditi po njima i koje su prednosti u
odnosu na ostale .. hence "mongo konsultanti kazu ovo i ono" ..

dijasporina baza moze i u .txt fajlovima da se odradi nije to problem,
pitanje je sta je tu "natural" i koliko dokument sistem jeste ili nije
"natural" za taj oblik podatka .. a to sto ti mozes da odradis kroz
dokument sistem, kroz relacioni sistem, kroz tekstualni fajl, xml, csv,
access, dbase .. to je sad druga prica .. pisao ja sistem za vodjenje
poslovanja srednje firme u asembleru pre mnogo godina, moze, danas bi
coveku koji to krene da radi rekao da je retard i da ima suvise
slobodnog vremena ..

Ali ono sto mene zapravo iznenadjuje, jeste da ljudi ne prave testove opterecenja, nego uhvate prvi proof of concept, i to maltene bude set in stone. Krene u produkciju, nisu probali da napune sa djubre podacima pa da pogledaju performanse. Svi danas manje vise prave nekakav rest service sa json-om, ima mala gomila alata kojim mogu da smore sistem na maksimum i da pogledaju perfomanse. Kao da je problem napuniti nekoliko stotina GB za par dana i pogledati kako se sistem ponasa.

cela poenta je bas u toj poglesnoj prici koju provlace fanboy's ...
retardiranim izrazima (web scale i slicno) i onda je to varijanta tipa,
sta poturis dokumente u mongo i ako je sporo dodas jos servera i bas te
briga ... iliti kako brajan rece neki dan (parafraziram ne secam se
originala na anglikanskom) "skontah cemu sluzi nosql, to je za ove sto
ne znaju sta je baza podataka i kako se koristi ista"

http://geekandpoke.typepad.com...3df553ef0148c80ac6ef970c-800wi

Mislis na ovako nesto ? :D

pusti, obzirom na probleme koje imam zadnjih 4 dana na privatnom projektu (nema veze sa oraklom) ocu da se roknem ... od svih stvari gde sam ocekivao probleme ukljucujuci mongo sve radi, tamo gde sam ocekivao da sve sljaka 1/1 (glassfish) raspad sistema :(

nego moram priznati, momci koji razvijaju app su se odusevili gui klijentom za mongo, radi mega dobro, kazu na lindzi milion puta bolje od svega sto su probali za mysql i pgsql .. ja uzeo danas bas da probam, stvarno svaka cast ozbiljna alatka :D

nego nevezano za "vodeci nosql", kapiram da bi vredelo na es-u odvojiti neki nosql kutak za razmenu informacija oko svih ovih nosql sistema .. ja sam se ovde malo nasalio sa nekoliko linkova o tome kako je nosql krsina no hteli mi ili ne ima ga mnogo, cesto i na dosta mesta nas niko nije pitao sta i kako vec smo zatekli situaciju .. takodje ne mozes da odaberes pravi alat za posao ako ne znas sve o alatima koji postoje :D ... eno npr sparkfun pobego sa marije .. nasao bolji cekic za svoj zavrtanj :D

Kada ga vec pomenu tvoje kolege mu veselo sasekli support. Ubise ga ko zeca. Ko nece na spring otici ce nazad na jboss :)

ti bas zelis da mi reaktiviras cir na zeludac? znam, ispi* sam .. pricao
neki dan sa managerom managera managera mog managera na tu temu,
otprilike kako sam skonto (on nema direktno veze sa gf-om ali svakako
zna vise od mene, no info nije zvanican niti je to stav orakla zvanicno,
tj ja svakako ne mogu da iznesem zvanican stav) bice varijanta kao rhel
i gedora, na gedori (glassfish) se kao testiraju stvari, radi razvoj etc
a na rhel (weblogic) je komercijalni server .. e sad kada je linux u
pitanju gedora je upotrebljiva ali za app server nesto mi nije jasno da
ce neko razvija na gf a tera produkciju na wl to mi je malo tadirano :(
tako da ja gleadam od neki dan na gf kao na propalu investiciju (mislim
na moje savladavanje istog zadnjih 7 godina) i razmisljam da predjem na
http://www.wildfly.org/ ... ne znam sta da radim iskreno .. ali znas ono
kad na kraju projekta saznas da si ceo projekat napravio na deprecated
nogama ... uh .. a meni bila frka da de mi tu mongo doci glave .. sad
provaliti kako ceo ejb + cluster trip baciti na wildfly .. ma .. neka
idu ... inace mi je cela java polako na vr... nego slaba alternativa za
ozbiljan veb, piton mi se gadi, rails je za ove sto ne znaju da
programiraju, da ga cukam bas u c++ nesto ne ide a i naci developere za
to je ravno samoubojstvu .. ostaje onaj trulez od php-a ... tuga i
jad... doslo vreme da imas izbora koliko oces a nista ne valja :(

https://github.com/errbit/errbit/issues/614

Samo da pozdravim sve u studiju, režiji i ispred malih ekrana...

Za nas sa jevtinijim ulaznicama - kojim? Bas mi treba GUI klijent za mongo, idealno neki koji zna sta je replica set, ali sasvim dovoljno i da se kaci na jednu masinu.

Zauzvrat javljam kako mi radi replica set cim ga ubacimo u produkciju :). Tri masine, TokuMX.

Uh-oh. Genijalci su stavili Redis i Mongo em na istu masinu em su oba proizvoda in memory?! Odluka pucam sam sebi u nogu u startu.

Ono sto je de facto jeste duzina naziva polja - meni npr. u bazi su nazivi polja poduzi tipa: dodatna-polja-potvrde-authorization-data-TipKorisnika i to bi mogao da skratim na neke numericke kljuceve a onda da na aplikativnom nivou vrsim konverziju u stringove (ima ih 20-25 polja).




Heh, krenuli smo i po PHP-u :) Meni bas glavna alatka za citanje iz monga i prikaz je PHP. :)

U firmi tIm (dva coveka) koji je projektovao bazu i aplikaciju pre ove price PHP+MongoDB radio je mesecima i nije uspeo da resi varijabilna polja ka Oraklu nikako (jedna poruka ima 5, sledeca 25 polja, sl. N polja, gde su nazivi takodje nepoznanica). PHP+MongoDB je krenuo u produkciju za 2 nedelje posle perioda testiranja. ;)

Bogdane jedno pitanje, mali off - kakvo je tvoje stanoviste prema WebLogic-u? Ima li tu nade ili je i to pucanj u nogu? Hvala.

Ono sto sam skapirao pre jedno 5 godina da je app server jedan veliki overkill. Ono sto je bila generalno ideja jeste da razvijas na jednom app serveru i da to prebacis na drugi bez menjanja icega. Ali to u praksi nema veze sa vezom, iz prakse mogu da kazem da smo u jednoj od predhonih firmi koristili nesrecni apacheov geronimo koji je trebalo da bude comunnity edition za ibm-ov "web sphere". Ali to je bilo u stilu cry me a river dok nismo presli na jboss. Tako da toplo savetujem prelazak na jboss tj wildfly kako ga sad zovu, jer vrteti se izmedju dva servera je haos.

Mada generalno za sve te enterprise zezancije ja toplo preporucujem spring, jer kako god da gledas uvek je vendor lockin. Spring je dovoljno narastao da pokriva sve sto ti srce pozeli.

A sa druge strane ako zelis neki lightweight java framework, uzeo bih ili restlet.org ili playframework oba su dovoljno mala i agilna pa neka vrsta prototypinga ide jako brzo.

ha od svih drajvera za mongodb jedino php-ov je ranjljiv na "sql injection" :P

http://robomongo.org/



ne bi da pretvorim temu u bljuvacinu ima tamo na advocacy dovoljno :D a i odosmo od mongo-a .. ja sam duze radio u php-u nego u svim ostalim web tehnologijama zajedno, jedino jos direktno c++ moze da se poredi a da budem iskren kada je dosao php i kada sam sa pisanjem cgi skripti presao na php teo sam da idem da ljubim zenda u ... koliko me usrecio :D .... al da danas ocekujem od php-a da radi milion puta bolje, ocekujem, a da radi, ne radi .. cak naprotiv :( .. ide mi na ganglije .. i dalje ga koristim extenzivno no ipak za neke stvari nije, negde ti ipak treba app server u pozadini a apache je sledece razocaranje posle php-a, onoliko bloat-a bez neke preterane koristi ... elem, mnooogo smo daleko od teme .. al cisto da se ispravim da ne bude da samo @%)@#$@)_$*@# .. php je u generalnoj kategoriji "ocekivao sam 1000x vise posle 20 godina od ovoga sto sam dobio"



nemam pojma, cak i ogromni klijenti kojima sam radio razne web aplikacije poput barcly banke su jeftini i nece da plate licence za app server tako da ma koliko su bili spremni da plate konsalting za glassfish i mysql nisu hteli da plate licence za weblogic tako da ja na doticnom nikad u zivotu nisam odradio deploy.. oracle je vrlo pragmaticna firma, pri silnim akvizicijama su po mojoj proceni odlicno radili odabir sta je najbolji sistem iz grupe i gasili sve ostale tako da ako su resili da ugase gf zarad wl-a kapiram da je wl dosta bolji .. mada sto se cele jave i orakla tice mnogo je tu razlike izmedju zelja i mogucnosti no sad vec prelazimo u sferu zanimljivih informacija zbog cijeg deljenja se dobija sut u d00pe iz firme te cu se zaustaviti :D



pa za male brze aplikacije jeste ali za bilo kakav ozbiljan app moras da imas i neku ozbiljniju obradu na serveru koja se ne zasniva samo na obradi unutar strane :) u tom slucaju je budzenje takvog sistema na web serveru koji nije app server ozbiljna budzologija i nikad se ne zavrsi dobro




standardi su cudo :(



ne bi se slozio no odosmo predaleko u mongo temi :D

Malo odosmo u OT ali play framework i ligthweight u istoj rečenici?!
Misliš na strukturu projekta ili na resurse?

Ja sad ulazim u neku pricu, gde u Toku hocu da smestim 2-3 stvari:

- Countere, perzistentno. Izbacujem ih iz relacione baze, posto su takvi da mi se fucka ako se nesto malo i pogubi od date, i trpam u mongo. Zauzvrat rasterecujem bazu gomile update-a, a mongo ima increment komandu koju mozes da pustas i asinhrono! :)
- Bas to, kesiranje, ne umesto memcached-a, vec da rasteretim kes. Prvi nivo u redis, drugi nivo u mongo.

Jos par stvari o kojima ne bi... :)



Hvala puno!

A što ne koristiš Redis za countere? Komanda INCR:
http://redis.io/commands/incr

Ima i DECR, naravno

RoboMongo je super stvar. Konacno malo boje 😁
Al steta sto ne moze da se inicira backup kroz njega, ali je svakako pravo
osvezenje. 10Gen bi trebalo da kupi Robo 😯

ja sam koristio onaj tadirani cli, probao par klijenata i vratio se na
cli :( .. razmisljao da mozda uletim da napisem neki svoj klijent, ko
zna mozda kane i neka parica uz ceo hype oko mongoloida kad mi rece
jedan od momaka koji rade development na ovom novom projektu kako je
presrecan klijentom (mislim da su reci bile "najbolja stvar kod mongo-a
je sto ima gui klijent bolji od bilo kog gui klijenta za mysql") tako da
ja reko aj da probam i .. bas je dobar

sad sto se tice 10gen kupi robo .. iz mog, ne tako malog iskustva, to bi
bilo jako lose... mislim da ce ovako odvojeno i sam robo bolje
funkcionisati a i verovatno ce uskoro dobiti i zdravu konkurenciju ...
10gen svakako treba da im da povremeno neke pare u vidu donacije i dzaba
konsaltinga, ali nikako ne treba da ih stavi pod svoju kapu

Imate MongoVue a i plugin za eclipsu

Treba mi perzistentan na disku. Redis to nije, onako kako ga ja koristim. Plus, redis nije bas HA.

Imam ja neko HA resenje, sa dva redisa master/slave + keepalived, ali sam iskljucio perzistenciju na disk jer mi upuca storage najstrasnije (neki NetApp od provajdera), plus sto kad vrisne master, pa treba da se novi slave usinka od nule sa mastera koji radi to zagusi i mrezu i hipervizor i sve vm-ove, i sam redis. Show.

U redisu ima nekih 15-20GB podataka, kesiran content iz baze. :)

P.S. Mongo isto ima increment, zato mi se i svidja za ovo.

Strukturu projekta, app server je takozvana lazanja arhitektura.

Kako MongoDB alocira podatke na HD? Imam utisak da za neke stvari od 10MB u MySQL, MongoDB zauzme 512MB?

HDD space je "dzabe" tako da se slabo "stedi" na istom:

http://docs.mongodb.org/manual...r-than-the-data-in-my-database

MongoDB namerno agresivno prealocira data fajlove da bi se izbegla fragmentacija.

Znam da je tema dosta stara - ne vidim čemu toliko vređanje JavaScript-a na serverskoj strani. Zašto ne iskoristiti potencijal tehnologije koja omogućava dugu konekciju sa serverom i ažuriranje podataka u realnom vremenu? Možda JS i nije baš najsrećnije rešenje pošto je , kao i PHP , implementiran nevešto , ali je činjenica da se dosta koristi i da ima svojih prednosti, kao i pomenuti MongoDB.

ne vredjam ja javascript ni na kojoj strani, evo sad radim ogroman
projekat sa nodejs (svakako BEZ mongo-a), svaki taj env. ima svoju
poentu ili ga ne bi ni bilo, samo mi idu na ganglije ljudi koji ne razumeju
razliku izmedju interpretera, kompajlera, virtualizacije vs native
koda/masina a kur123e se da su veliki hekleri ... ako ne razumes na
koliko nivoa je "komapjliranje u javascript" pogresna stvar slobodno
nastavi tamo gde si stao ja nemam nista korisno da ti kazem.

_{[Ovu poruku je menjao bogdan.kecman dana 07.12.2015. u 19:54 GMT+1]}

Meni ovo izgleda kao vređanje, e sad, ako ti tako tepaš JS-u onda okej :D

Znam da razlikujem kompajler i interpreter, radio sam i sa kompajliranim i sa interpretiranim jezicima tako da mi je jasna u potpunosti razlika između ta dva pojma. Nisam ni rekao ništa vezano za to. Slažem se da ima puno takvih koje spominješ, krivi su mediji koji pričaju o ogromnim zaradama programera, a ni u jednom članku ne pišu koliko je to zahtevan posao.

ne vredjam ga - tako mislim, da uzasno je i tuzno da mi u 21 veku pisemo server side u javascriptu, da pisemo front u javascriptu, da .... uzas, tuga, strasno na toliko nivoa da ne umem da objasnim .. a to je opet iz ciste lenjosti ... lakse je utuci stotine hiljada / miliona evra u hardware nego skolovati valjanog developera pa ljudi koji ne razumeju zasto je "kompajliranje u javascript" problem (inace onaj covek sto napisa da pise nodejs, kome sam to napisao, nemam nista protiv njega licno, nit znam coveka nit sam gledo sta je i kako pisao mozda uopste nije los developer, mozda je je123ni genije, a mozda je blefer kao 90% njih na trzistu, ne mogu nikako da znam iz tri posta, bilo bi mi zao da se uvredio, ali mi vise pun krivi javascripta, pa ko oce se vredja nek ne cita sta ja pisem ima negde neka skripta ovde na forumu pisana u js-u koja blokira odredjene korisnije :D ) vode kolo oko toga sta je danas "hype" pa se vise trosi vreme da se budalama omoguci da mogu da "programiraju" i "manageuju" nego da kvalitativno unapredjenje okoline u kojoj radimo .. pogledaj bre demoe koje smo pisali u 512 BAJTOVA, pogledaj danas sta kreteni ne mogu da izvedu ni sa 512 GIGABAJTA ... no nije ni vreme ni mesto ni tema :D

@bogdan, offtopic:

Razlika izmedju kompajliranog i interpretiranog jezika se kod servera dosta gubi. Najbolji primer je php sa opcache-om, koji drzi binary kod spreman u ram-u, ne znam da li nodejs ima slicnu funkcionalnost.... Isto, sa stanovista jezika, ne vidim neku bitnu razliku izmedju bare metal masine, vm-a pod kvm-om ili xen-om, ili lxc kontejnera? U cemu je bitna razlika za aplikaciju u php-u ili js-u? Znam za razlike za baze i za virtuelizaciju pristupa disku, consistency, nacin na koji radi sync, sve to ima smisla - ali u cemu je razlika za programera aplikacije? Zasto js developer treba da misli o tome?

@nikola, NES ME UVUC U TU PRICU SADA, NEMA SANSE!!!!

@bogdan: OK, imas poziv skokni neki dan idemo na pivo pa mozemo u prijatnijoj atmosferi :)

znas da sam ja uvek za ali morace da prodje ova godina, od drugog
januara na dalje uvek moze :D (a mozda budem prvog pravio nesto za rodj
za krnjenje pete decenije pa ... videcemo) .. samo ima toliko
interesantnijih tema :D

Ako hoćeš da pišeš softver koji se vrti u browseru nemaš puno izbora, ili da pišeš JS ili da pišeš u nečemu što se "kompajlira" u JS, ne vidim ništa skandalozno u tome. Sva sreća pa su makar Flash utepali, trebalo je bogami decenija i više...