[es] - NonSQL i MongoDB Pocetnik

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: NonSQL i MongoDB Pocetnik

^{18.04.2011. u 21:47 - pre 170 meseci}

Citat:

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

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.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: NonSQL i MongoDB Pocetnik

^{18.04.2011. u 23:01 - pre 170 meseci}

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)

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: NonSQL i MongoDB Pocetnik

^{19.04.2011. u 22:54 - pre 170 meseci}

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.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

BorisMB
Boris Maksimovic
Pljevlja-Beograd

Član broj: 145101
Poruke: 71
*.crnagora.net.

Profil

Re: NonSQL i MongoDB Pocetnik

^{25.07.2011. u 16:22 - pre 167 meseci}

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 ...

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: NonSQL i MongoDB Pocetnik

^{25.07.2011. u 19:51 - pre 167 meseci}

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

Odgovor na temu

BorisMB
Boris Maksimovic
Pljevlja-Beograd

Član broj: 145101
Poruke: 71
*.crnagora.net.

Profil

Re: NonSQL i MongoDB Pocetnik

^{26.07.2011. u 00:59 - pre 167 meseci}

Citat:

mmix: 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 :)))

Odgovor na temu

Dejan Lozanovic
Dejan Lozanovic
Beograd

Član broj: 691
Poruke: 2325
*.adsl.verat.net.

Jabber: null@elitesecurity.org
Sajt: speedy-order.com

+75 Profil

Re: NonSQL i MongoDB Pocetnik

^{04.09.2011. u 22:57 - pre 166 meseci}

Citat:

BorisMB:
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.

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

http://speedy-order.com

Odgovor na temu

Dejan Lozanovic
Dejan Lozanovic
Beograd

Član broj: 691
Poruke: 2325
*.dta.co.rs.

Jabber: null@elitesecurity.org
Sajt: speedy-order.com

+75 Profil

Re: NonSQL i MongoDB Pocetnik

^{05.09.2011. u 14:20 - pre 166 meseci}

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

Citat:

Suppose we have a collection of status messages from users. We want to query by user
and date to pull up all of a user’s recent statuses. Using what we’ve learned so far, we
might create an index that looks like the following:
> db.status.ensureIndex({user : 1, date : -1})
This will make the query for user and date efficient, but it is not actually the best index
choice.
Imagine this as a book index again. We would have a list of documents sorted by user
and then subsorted by date, so it would look something like the following:
User 123 on March 13, 2010
User 123 on March 12, 2010
User 123 on March 11, 2010
User 123 on March 5, 2010
User 123 on March 4, 2010
User 124 on March 12, 2010
User 124 on March 11, 2010
...
This looks fine at this scale, but imagine if the application has millions of users who
have dozens of status updates per day. If the index entries for each user’s status messages
take up a page’s worth of space on disk, then for every “latest statuses” query, the
database will have to load a different page into memory. This will be very slow if the
site becomes popular enough that not all of the index fits into memory.
If we flip the index order to {date : -1, user : 1}, the database can keep the last
couple days of the index in memory, swap less, and thus query for the latest statuses
for any user much more quickly.
Thus, there are several questions to keep in mind when deciding what indexes to create:
1. What are the queries you are doing? Some of these keys will need to be indexed.
2. What is the correct direction for each key?
3. How is this going to scale? Is there a different ordering of keys that would keep
more of the frequently used portions of the index in memory?
If you can answer these questions, you are ready to index your data.

http://speedy-order.com

Odgovor na temu