Nekako mi se čini da si pogrešno postavio stvari. Koji problem riješavaš i zbog toga razmišljaš u NoSQL-u?

NoSQL se generalno koristi u situacijama kada imaš ogromne količine podataka i gdje apsolutna tačnost upita nije jedan od imperativa.
Mislim da NoSQL nema praktično nikakvu primjenu u standardnim veb sajtovima.

Hvala sto si mi se javio,

Evo u cemu je problem ... trenutno radim nesto poput digitalnog dnevnika tj, njegovu zamjenu ili mozda bolje da kazem alternativu...
E sad zamisli tabelu koja za 9.mjeseci puni se na nekih 10m redova .... e sad znas kakva je relaciona logika i kako razmisljamo relacino preko id -a :)
10m redova nije nimalo malo ako se uzme predpostavka da ce oko 20k usera prosecno dnevno da pristupa + racunanje i ostalo ....

e sad kod mongodb mogu maltene da smjestim sve u jednu "tabelu" ali ne znam kako da pravim relacije, a druga mogucnost jeste da podatke o ocjenama smijestam i u "tabeli" user i u "tabeli" ocjene npr ali tu se krsi osnovni model db ....

jednostavno ne znam kako da povezem sve te stvari ... jako mi se svidjaju nonsql db ali jednostavno ne umijem da ih primjenim ... trebaju mi uputi i klasicni primjeri ... a to sto sam nasao na netu recimo da nema nista o tome ....

Ja sam skoro pročitao par članaka vezanih za NoSQL baze podataka i koliko sam skapirao relacione baze i NoSQL baze se ne sukobljavaju već se dopunjuju. Na ovom linku
http://www.mongodb.org/display/DOCS/Schema+Design
imaš materijal koji bi mogao da ti razjasni neke stvari.


Takođe na ovom http://degizmo.com/2010/03/23/redis-relations-in-a-nosql-world/ linku možeš da nađeš sledeće:

Hvala na ovom drugom linku .. ovaj prvi sam vec gledao i citao ... ali jednostavno ... nece jos u mojoj glavi nije sve jasno ...:)
a moje misljenje je da ce ove baze pregaziti sql ... jer je lijepo kad sa jednim "upitom" dobijes sve podatke pritom date u json strukturi i ovo sto sam do sad testirao radi jako brzo ....
Bacam se na proucavanje .... hvala puno

Ja i dalje mislim da se neće desiti ovo što pričaš da će NoSQL baze pregaziti relacione baze pošto nisu za iste potrebe. Uostalom pokazalo se u praksi za šta se koriste ove baze, proguglaj Facebook NoSQL i Twitter NoSQL i videćeš gde su našli primenu. Kad bi bila dobra ideja da se sve relacione baze zamene NoSQL bazama verovatno bi to Facebook i uradio, ovako oni za većinu podataka koriste MySQL, makar tako piše na internetu.
Kao što sam rekao, po mom mišljenju ove dve baze se dopunjuju i stvarno ne treba da advokatišemo o tome šta je bolje. Znači i jedno i drugo imaju primenu, ko zna i jedno i drugo odlična je stvar.

Ako vec developeri moraju svu relacionu logiku da rese kodom, sta ce ti uopste bilo kakva baza, SQL ili NoSQL. Obican text fajl moze da posluzi, ili XML. I tu ima dosta iskustva. I dobro je sto se ustedi vreme koje se inace gubi na garantovanju integriteta podataka. nema bajo vise nikakvih ogranicenaj, sve prolazi, i to velikom brzinom. Kako se samo ovoga niko nije setio ranije. A mozda i jeste.

Jos pre 30 godina su komunalne firme u staroj YU koristili protram napisan u BASIC za PDP kompjuter (kod nas ze zvao Iskra) koji je sve radio sa text fajlovima i sve je bilo kontrolisano iz BASIC-a. Znaci, moze se, i ima se iskustva, valjda nisu svi bas u penziji koji su na tomre radili. Iz nekog glupog razloga, verovatno pomodarstva, ljudi su kasnije presli na relacione sisteme...

Ovo mi daje ideju da otvorim biznis, prodajem prazne sendvice bez hleba. Parce 'leba gore, prce 'leba dole a u sredini nista. Onda se hleb odbaci kao nezdrav, zbog karbohodrata. Strasno se brzo prave takvi sendvici, i sto je najlepse - absolutno je nemoguce dobiti na tezini. A mogu se slati i direktno na Blackberry ili Iphone, "there is app for everything". Total flexibility at enormous speed. Welcome to future.

Srecan rad

@Zidar, pokojni Čkalja je to zvao "PRAZAN SENDVIČ", a ima još uvek živahnih penzionera koji se dobro sećaju PDP-ja i sve pomenute priče... :-)

svaki tip baze ima svoje trziste i svoju primenu. Ako su relacije veoma potrebne, ako je potrebna koinzistentnost podataka.. i jos par sitnica.. onda su ti potrebne relacione baze (oracle, sql server, postgresql, mysql)..
Nosql je nesrecno skovani termin koji sluzi da bi se napravio hype :). A u pitanju su samo nerelacione baze: tree, key-value, object oriented... baze. Svaka sluzi za po nesto :)

Dobri covek Ckalja. Paja i Jare i kamion... bas je bilo lepo.

Sto se tice baza, tacno, sve imaju svoju primenu. Samo treba biti oprezan sa novotarijama, za svaki slucaj. So bzirom na Zoranov moj uzrast, treba nam oprostiti sto smo ponekad skepticni prema novotarijama.

To o cemu pricate je zapravo bolje opisati kao NoREL, da izbegnemo konfuziju. IMHO, RDBMS uvek moze da se koristi u optimizovanom NoREL rezimu dok suprotno ne vazi. Sve ostalo mi deluje kao povelik hype

Hype-a ima sigurno, kao i u svemu sto se danas pojavljuje kao nesto novo - bilo to dobro ili lose.
Ali zaista mislim da se ne moze otpisati kao nepotrebna/redudantna novotarija, jer tesko je povjerovati da bi FB i Google koristili tu tehnologiju samo zato sto je, sta, izhajpana :)
Svaka logika iza toga bi bila mnogo nategnuta. A Google i FB nisu to sto jesu zato sto im je tehnicki dio sistema krs.

a ne ne. Nije nepotrebna. Relacione baze su jako lose za neke tipove primena, i zato ostale uskacu da popune tu prazninu. Ali ne-rel baze postoje oduvek, samo sto su sada napravili hype sa terminom nosql a ne sa samim bazama :)

NoREL je brzi samo zato sto "sece krivine" koje RDBMS po defaultu ima postavljene jer vodi racuna o nekim drugim stvarima sem brzine. RDBMS moze da radi kao NoREL, relacije su opcione. Kad bi iz bilo kog danas ozbiljnijeg RDBMSa izbacio sve ono sto NoREL ne podrzava (a mozes da izbacis konfigurisanjem) i ogranicio query-e na ono sto NoREL radi dobio bi at-par performanse i to samo ako je NoREL resenje "pokralo" neke RDBMS trikove kao sto su paging, caching, indexing, itd. Mislim da smo bas ovde i na forumu imali slicnu temu ovoj. Isto tako obratite paznju na to da skoro SVI noREL timovi sa svojim resenjima polako ubacuju funkcije koje su skupe i za koje moraju da implementiraju logiku koja je u RDBMS sistemima vec dovedena do savrsenstva (sorting, paging, multi-indexing, composite indexing, dynamic cursors, locking, itd). Da ne pominjem da te NoREL potpuno i za sva vremena ogranicava na denormalizovane podatke i da nikad nece moci da uradi stvari koje RDBMS moze i zato kazem Hype. TO moze da bude super za google za brzu pretragu po kljucu ali vec za facebook nije dobro, kao ni za 99.999% poslovnih primena gde je normalizacija kljuc kasnije analitike.

Ne kazem da NoREL-only resenja ne treba da postoje ali kazem da je hype napravljen ogroman oko necega sto je u osnovi povratak korenima RDBMSa. Nista se revolucionarno tu vise ne desava, optimalni algoritmi za pretrazivanje vec postoje, i ako vec biram ciju implementaciju cu koristiti moji favoriti su medju iskusnijim igracima kao sto su MSSQL, Oracle, PostgreSQL i sad MySQL pre nego sa emerging timovima kao sto je Mongo ekipa. Isto ne kazem da mi se ne svidja lambda dokument query i hijerarhija koju Mongo ima, sve to izgleda previse dobro i nazalost i jeste, to je mac sa dve ostrice. Losa strana je sto efektivno query optimization svali tebi u krilo, pa kako ti bude, sa prostijim queryima na flat strukturama se snadjes da izzmuzes optimalno resenje a onda kako evoluiras proizvod i uhvatis sebe da ti treba normalizacija onda pocnes da validiras, da simuliras relacije, spajas strukture, preloadujes masu podataka za kompleksnije agregacije, i to onda postane ruzno i sporo.

Solr/Lucene (po mom misljenju) najbolji search engine koristi norel bazu :). Za keshiranje web aplikacija, niko ne koristi rel baze nego samo norel (npr memcache/apc/memcached i sl). Embeded sistemi, koliko ja znam, ne koriste rel baze. Veliki CMS tj EMS sistemi, za smestaj samog contenta, skoro uvek koriste specijizovane XML baze (mislim da su izuzetak IBM, Oracle i MS)
Hype sam po sebi je jako dobar, jer ipak, na neki nacin, se sazna mnogo vise o bazama i dobijemo mnogo bolje alate za neke specificne stvari.
Jednostavno sve je to alat: nekad ce koristimo ashov a nekad motiku (ili kafenu kasiku kao arheolozi). A i jedno i drugo sluze za kopanje

Juche je kolega u firmi drzao predavanje o NoSQL bazama. (NoSQL ne znaci NON SQL (bez sql) vec Not Only SQL :).

Jedna cinjenica koja ide u prilog NoSQL bazama je horizontalna skalabilnost koja je daleko ucinkovitija nego kod RDBMs-a.

Kako? I u kom smislu ucinkovitija? Daj malo elaboracije, pustio buvu i zapalio




Znas sta, mogu i ja iz koda da napravim hashed kolekciju za kesiranje i u osnovi to zadovoljava basic definicije NoREL baze , nemojmo sad preterivati i nazivati to bazama . A btw, koriscenje XMLa za smestanje/retrieval podataka je teski crap osim ako nije samo za content nad kojim je neki indexable search layer koji nije XML, to mogu iz prve ruke da ti potvrdim.

@BorisMB

10 M slogova je puno podataka, a opet s druge strane i nije.
zato postoji particioniranje tablica.
nosql baze nisu predviđene za stvari za koje ih ljudi pokušavaju koristiti.

mysql je relacijsla baza, a mysql cluster je recimo jedna vrsta nosql baza.


nosql baze neće pregaziti relacijske baze, jer relacijske se koriste za organizaciju podatataka, dok nosql za neke druge stvari.

u praksi obično to ide ovako: neznamo relacijske baze, ali imamo za napraviti neki projekt, sa strane smo čuli za nosql baze i odlučili koristiti.
čitaj: ne uči nam sql i nemamo pojma o relacijskim bazama i nećemo imati.

Loša ti je ta praksa.

U praksi, sagledaš problem i onda odlučiš koji alat je dobar da ga rešiš. Ako ne poznaješ alat - naučiš da ga koristiš.

Iliti: ako treba da zakucaš ekser, uzećeš čekić, a nećeš ga tući klještima...

Nerelacione baze su vrlo zanimljiva pojava. Mogu da barataju sa nekim vrstama podataka koji su noćna mora za relacione baze. Ipak, idelno bi bilo da se napravi kombinacija.


_{[Ovu poruku je menjao Predrag Supurovic dana 18.04.2011. u 08:53 GMT+1]}

Nisam siguran da je moguce napraviti kombinaciju jer je normalizacija problem, struktura je ili normalizovana do neke forme ili nije normalizovana uopste, nema niceg izmedju NoREL i 1NF, samo NoREL, a ako u NoREL ubacis normalizaciju onda je to vec RDBMS.

Te zanimljivosti se uglavnom svode na apstrakciju query jezika, ono sto ti ne vidis je na koji nacin noREL sistem interpretira i izvrsava te strukturalne query-e a to se na kraju svede na index scan, MORA da se svede ili gubi na performansama. Ako hoces plastican primer ovoga pogledaj Linq2SQL ili Linq2EF, sve operacije koje npr Mongo podrzava u svom arsenalu direktno podrzava i Linq, i kao nivo apstrakcije oslobadja te potrebe da znas SQL, pa ipak iza svega toga je sistem koji Linq queryje pretabava u SQL koji rdbms moze da sazvace. To i dalje ne cini Linq bazom, samo ga cini apstraktnim layerom iznad baze. Ista je prica i za noREL sisteme, dok neko ne pokaze fundamentalno novi algoritam za pretrazivanje struktura podataka koji je bolji od B+tree sve se na kraju svodi na isti mehanizam.

Recimo Cassandra nema 'master' node vec su svi nodovi podjednako vazni i ne drzi ni jedan node sve podatke ali zna gdje ga naci. Povezani su u prsten i tako da uvijek postoji 2 puta kud mogu doci podaci. Opterecenje se jednako rasporedjuje po nodovima. Ukoliko je postojeca struktura previshe opterecena - moguce je 'na zivo' dodati nove nodove i time smanjiti opterecenje.

Kod RDBMS-a to nije bas tako izvodivo koliko znam.

OK, sharding nije podrzan out-of-the-box ni na jednom RDBMSu, postoje implementacije na aplikativnom nivou (tipa Enzo Shard Liba) ali ok, priznajem da nije to to kao sto je implementirano na Mongou i Casandri. Medjutim to nije feature NoSQL/NoREL baza per se, nista ne sprecava RDBMS da ga implementira na nivou engine-a. Sta vise suska se da ce Denali imati sharding sto je i ocekivano kao nadogradnja na single-machine particije koje imamo sada.

Sem toga i ta prica oko Cassandre je malo naduvana, na stranu sales speech, ne mozes imati sistem koji nema single point of failure a da svaki podatak nema bar DVE kopije , samim tim je i cela infrastruktura za lociranje sekundarnih pozicja svakog podatka kompleksnija (tj nije dovoljno da node zna gde je neki podatak vec mora za svaki podatak da zna i gde je druga kopija u slucaju da node originala padne plus sto je u odmah baza*2 u velicini)

Cuj, ne idealizujem ja tu pricu, to jos treba da sazri (fali dokumentacija, driveri nisu bas najbolji, teorija a praksa) ali je cinjenica da postoje okruzenja gdje to radi i ima svoju svrhu i pokazuje rezultate / prednosti.

Pozdrav narode,
Evo posle par mjeseci se javljam, kad sam god imao vremena cackao sam oko svoje aplikacije i polako je prenosio na MongoDB. Naravno koristion sam doctrine ODM za Mongo DB.

Ono sto vam mogu reci iz ugla programera koga puno ne zanima kako radi sama baza, vece njeno koriscenje mogu vam reci da sam vise nego zadovoljan.
Svidja mi se njena dokument orjentisanost, u sali sa par drugara nazvo sam je dosije bazom jer bukvalno imam takav osjecaj dok je koristim. Ono ko u filmovima kad vada o nekom opasnom liku dosije koji je tezak 10KG i mlatnu sa njim od sto :)

Aplikacija koju sam pravio prije par godina koja se tice zdravstvenih kartona radila mi je pod MySQL-om i ok je sljakala, posle par mjeseci za pojedine kartone trebalo je i po 4-5s da bi se izvrsio upit, medjutim to doktorima nije smetalo, ne vjerujem da su i osjetili....
E sad u zadnje par mjeseci poceo sam da lagano prebacujem sa MySQL servera na MongoDB u edukativne svrhe. Prva stvar koja mi se najvise dopala jeste taj "dosije" jednim jednostavnim upitom dobijem kompletan dosije, odnosno karton pacijenta i bez obzira na to koliko veliki bio, kolko rasto njegovo vrijeme izvrsavanja ostaje isto, 1-2 ms.
Dio za diskusije, nesto poput klasicnog foruma takodje radi brzo, e sad pretraga diskusija prema sadrzaju je oko 10x sporija. Doduse jednim djelom sam kriv i ja i doktori jer malo neprakticno koristimo taj dio. NPR pod MongoDB izvrsava se 2.61s dok pod MySQL to je 293 ms. E sad ako stavm da mi se sadzaj indexira sto me je kostalo nesto oko 3250MB rama brzina je spala na nekih 45ms. Dakle na tim stvarima da bi se postigla brzina mora da se plati hardver.
Dio koji se odnosi na usere odnosno u mom slucaju na doktore otprilike je sve isplao dobro, ali imao sam problema sa azuriranjem njihovoh podataka. Ne znam jos uvijek kako se to desavalo ali kad sam mjenja trenutni status doktora nekad ga azurira nekad ne, jos nisam provalio kako se to desavalo jer nije bilo pravila kad ce da prodje a kad ne, greska koja se javljala jeste nepostojeci id ali stvarno ne znam na koji nacin. Tako da sam ovaj dio morao promjeniti. Ali i dalje uzimam ovo kao moju gresku koju sam sam napravio.

E sad nesto sto mi se nije svidjelo, sto ipak dajem sql bazama plus jeste dio za za preuzimanje statusa .... lako je kreirati jednu tabelu koja sluzi samo za to ... uzeti zadnjih 20 promjena dok kod MongoDB pokusao sam to da izvadim i dokumenata usera ide znatno sporije ... bez obzira na to sto se radi od svega 15 ms razlike upit je znatno veci, pri tome ako se ne indexira vrijeme je mnogo vece. Object_ID je dio koji mi nije jasno zasto je napravljen tako. dio koji se odnosi na update, malo u nekim slucajevima komplikovan. E sad alat za manipulaciju za bazom, podesavanje servera i slicnih stvari je "zalostan". Uredu kroz kozolu moze sve da se dobije ali sad mi je malo bzv da ja pisem alat. Postoji nekoliko alata ali meni se nekako nisu svidjeli nimalo.

Ono sto mogu reci, generalno kao programer pocetnik, ne profesionalac, jeste da MongoDB je jako korisna stvar. Iskreno ici cu ka tome da totalno izbacim relacione baze. I da pojedini su rekli kako bi bilo dobro da ima neki hibrid, ono sto bih ja volio jeste da u sklobu MongoDB imam tabelu na mjestima dje mi je bas potrebno da je imam u tom obliku.

Volio bi da ako je jos neko koristio MongoDB ili neku drugu NoSQL pazu kaze kakvo je iskustvo imao ...

A sta ces kad ti ponestane rama za indexe? ;)

Pa kao sto sam reko to je i previse skup metod :) ali istina je da se dobije na brzini bez obzira sto ne podrzavam ovu opciju :))
Mada ako je stvaro to potrebno cuo sam da na amazon moze da se dobiju masine koje imaju 32+GB stvarno nisam koristio pomenuti servis
I da stvar koju nisam pomenuo ... slucajno sam upao preko EUDP na GIS monetenegro i tu se upoznao generalno sa gis-om, u tom trenutku postgis od postgresql je u odnosnu na sve ostale servere bio najbolji ... pogotovu kod presjeka poligona i tacaka, gdje je na primer mysql imao bagova .... MongoDB u gis orjetaciji je daleko jednostavni za koriscenje i znatno brzi i do sad sto sam se igro sa njim nisam nasao ni jednu gresku ...
Samo kad bi u mogo ubacili tabelu da ima da se nadje ako zatreba definitivno bih smio reci da bi ugasila sve ostale baze :)))

Jel bi mozda mogao malo detaljnije da opises strukturu dokumenta i sta si indeksirao tj koliko toga, i sa kolikim brojem dokumenata radis ?

Opet kad si pravio indexe da li si vodio racuna o redolsedu polja kako pravis index, evo jednog pasusa iz knjige MongoDb The Definive Guide