Meeting 2010-02-01
Igor Rumiha
Ima zainteresiranih za meeting danas?
Igor Rumiha
Igor Rumiha
> Ja, samo u koliko sati? moze oko 19h? ili kasnije?
>
> Zanima me da li se netko igrao sa Mojo i MongoDB?
>
Meni odgovara 19h. Mjesto? :)
Igor.
Boris Shomodjvarac
Ako nekog zanima mozda bi mogao malo pricati o MongoDB vs CouchDB,
MongoDB = c++
CouchDB = erlang
Oba su document store, per document transactions,
MongoDB je po meni brzi i bolji, MongoDB ima binarni protorok zvani
BSON, i perl ima driver za njega, sto znaci da svi podaci IN/OUT idu u
binarnom formatu...
Dok kod CouchDB, idu u JSON-u, sto znaci dosta decode/encode sa strane
perla i couchdb, osim toga MongoDB je UTF-8 store, dok elrang ima
problema sa UTF-8 (uopce nema podrsku u jeziku, ima nekakve trikove u
R13), tako da erlang koristi libicu za konverziju znakova.
CouchDB ima samo raw drajver za elrang, svi ostali moraju da koriste JSON.
MongoDB za sada ima podrsku za cluster tipa one-write,many-read dok
CouchDB ima malo bolju, MVCC, ali to nije 100% automatski, tj sa strane
baze, nego kada ne moze da uradi merge dokumenta onda prijavi gresku pa
programer mora da ih merge-a ili taj dokument ode u neku drugu tablicu.
Sto se tice MongoDB-a, mislim da je one-write,many-read savim dovoljan
za potrebe i najvecih hrvatskih sajtova. Verzija 1.2 and up ima i neke
nove cluster opcije osim one-write,many-read.
Oba imaju map/reduce pisani u javascript jeziku.
MongoDB je laksi za instalaciju, nema web sucelje ali ima dobar shell,
dok CouchDB je malo kompliciran za instalaciju, ali ima prilicno lepo
web sucelje.
MongoDB cak ima i podrsku za indekse, nisam siguran u slucaju CouchDB-a,
a znam i da MongoDB jede jako puno memorije, i radi nekakvu smart
optimizaciju na disku, naime pokusava da odredi velicinu dokument-a po
tablici i automatski alocira disk, gledao sam malo po netu nekakve
benchmarke i nasao samo jedan, otprilike je MongoDb bio ~16x brzi
read/write od mySQl-a na nekih 10 miliona dokumenata.
Sto se tice query jezika u odnosu na mySQL, izgleda mi da podrzava skoro
sve kao i mySQL, jedino sto nema je transakcije na vise dokumenata, ali
to ni jedan NOSQL nema, jer to je ono sto ih cini drugacijim od SQL-a,
ali transakcije su automatski per document.
Mislim da Dobrica moze dodati na ovo, on zna vise o Redis-u, ali mislim
da je to samo key-value store...
HTH,
Boris.
Dobrica Pavlinusic
Pa, prili�no sam siguran da je mama o.k.
Ja se tako�er javljam temu MongoDB :-)
http://blog.rot13.org/2010/01/mongodb_-_so_you_want_fast_nosql_database_which_you_can_grok.html
http://blog.rot13.org/2010/01/its_about_system_stupid.html
ko' da sam znao :-)
--
Dobrica Pavlinusic 2share!2flame dpa...@rot13.org
Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
Boris Shomodjvarac
> On Mon, Feb 01, 2010 at 11:52:53AM +0100, Boris Shomodjvarac wrote:
>> Igor Rumiha wrote:
>>> 2010/2/1 Boris Shomodjvarac <sho...@gmail.com>:
>>>> Ja, samo u koliko sati? moze oko 19h? ili kasnije?
>>>>
>>>> Zanima me da li se netko igrao sa Mojo i MongoDB?
>>>>
>>> Meni odgovara 19h. Mjesto? :)
>>>
>>> Igor.
>>>
>> Vjerojatno je mama zauzeta? Dobrice?
>
>
> Ja se također javljam temu MongoDB :-)
>
> http://blog.rot13.org/2010/01/mongodb_-_so_you_want_fast_nosql_database_which_you_can_grok.html
>
> http://blog.rot13.org/2010/01/its_about_system_stupid.html
>
> ko' da sam znao :-)
>
Cool, zanimljivo, cinimi se da smo dosli do prilicno istog zakljucka sto
se tice CouchDB vs MongoDB.
Moze onda mama u 19h?
Boris.
Dobrica Pavlinusic
> Boris Shomodjvarac wrote:
> > Igor Rumiha wrote:
Zapravo, jednostavno koristi mmap-ani file tako da 2000 write-ova ne
flush-a 2000 puta na disk nego VM layer flush-a buffere po svojoj
procjeni (zato i nema MVCC i ne garantira da �e sve zavr�iti na disku).
Zbog mmap-og file-a izgleda kao da je virtual memory footprint velik
(jer je cijeli file dio virtualnem memorije) i zbog istog razloga ima
limit od cca. 2G na 32-bitnim platformama [lupio sam u njega :-) nije
data corruption, ali indeksi javljaju assertation error].
Anyway, daviti �u vas u mami danas sa time :-)
>
> Sto se tice query jezika u odnosu na mySQL, izgleda mi da podrzava skoro
> sve kao i mySQL, jedino sto nema je transakcije na vise dokumenata, ali
> to ni jedan NOSQL nema, jer to je ono sto ih cini drugacijim od SQL-a,
> ali transakcije su automatski per document.
Nema zapravo ni logi�ke operacije: foo.bar = 1 and foo.baz = 2 je
jednostavno jer je defaulni operator and, ali foo.bar = 1 or foo.baz = 2
je IMHO trenutno neizvedivo).
FWIW, foo.bar = 1 or foo.baz = 2 je rje�ivo sa 'foo.bar': { $in: [ 1,2 ] }
> Mislim da Dobrica moze dodati na ovo, on zna vise o Redis-u, ali mislim
> da je to samo key-value store...
Grrr... Redis isto tako ima array-e, opcije sa setovima (unija, presjek)
ali je zapravo cijeli u memoriji i O(1) pa je sli�niji memcache-u na
steroidima nego disk-based CouchDB/MongoDB-u (iako ima perzistenciju na
disk).
Boris Shomodjvarac
read/write od mySQl-a na nekih 10 miliona dokumenata.
>
> Zapravo, jednostavno koristi mmap-ani file tako da 2000 write-ova ne
> flush-a 2000 puta na disk nego VM layer flush-a buffere po svojoj
>
> Zbog mmap-og file-a izgleda kao da je virtual memory footprint velik
> (jer je cijeli file dio virtualnem memorije) i zbog istog razloga ima
> limit od cca. 2G na 32-bitnim platformama [lupio sam u njega :-) nije
> data corruption, ali indeksi javljaju assertation error].
>
>
Da ovo je malo problematicno, ali to je problem generalno sa svim
bazama, tj diskovima i cache-om:
{quote}
Full durability comes at a significant cost to write performance. For
this reason, modern hard drives have hardware buffering of writes turned
on by default. What's more, many traditional RDBMS solutions simply
perform an fsync-style flush when flushing the transaction log. This is
reasonably fast but incomplete -- on Linux for example, fsync() may
return before the data is permanantly stored when the drive has write
caching enabled. (Disabling the write cache on the drive could result in
a huge drops in performance).
What all this means is that even the most durable systems are
susceptible to corruption and data loss in certain situations. Some
research is underway with MongoDB on durability schemes that maintain
very high performance. Those desiring greater durability are free to
configure the --syncdelay option mentioned above and are encouraged to
employ some forms of replication.
{quote}
Tako da se moze podesiti opcija --syncdelay u sekundama, i MongoDB ce
zapisati sve izmene na disk u tom periodu.
Boris.
Boris Shomodjvarac
> Zapravo, jednostavno koristi mmap-ani file tako da 2000 write-ova ne
> flush-a 2000 puta na disk nego VM layer flush-a buffere po svojoj
> procjeni (zato i nema MVCC i ne garantira da će sve završiti na disku).
>
> Zbog mmap-og file-a izgleda kao da je virtual memory footprint velik
> (jer je cijeli file dio virtualnem memorije) i zbog istog razloga ima
> limit od cca. 2G na 32-bitnim platformama [lupio sam u njega :-) nije
> data corruption, ali indeksi javljaju assertation error].
>
> Anyway, daviti ću vas u mami danas sa time :-)
>
Odmah par pitanja da ne zaboravim do sastanka, mene zanima koliko je
izvodljivo/pouzdano zamjeniti mySQL sa MongoDB za web siteove.
1. Sta se desava ako MongoDB udari limit od 2gb? mislim da bih sa ulimit
lako mogli simlirati to, zanima me jer ok recimo da je 64bit platforma,
ali sta ako nema memorije, osim toga to nije 2gb podataka, MongoDb
alocira mnogo vise po dokumentu nego sto je on u istinu velik, razlog je
kako bi spasio sebe od fragmentiranja dokumenta prilikom dodavanja
polja, pa on alocira mnogo vise mjesta po dokumentu kako bi mogao da
uradi update in place od binarnog fajla.
2. vjerujem da bi u ovom slucaju, trebalo arhivirati nepotrebne podatke,
kako bi se smanjila velicina baze, arhivirani dokumenti mogu da se
presele u drugu bazu na drugi server ili jednostavno export i brisanje
iz baze.
3. delayed fsync me malo brine... Razmisljam se, mozda bi se moglo iz
shell-a, tj komandom reci MongoDB-u da uradi fsync, ako je recimo nesto
dodano u bazi, tipa financijskog impakta, sto je vrlo bitno, da onda on
uradi sync, a za ostale unose ne toliko bitnog tipa da radi default
delayed fsync.
Npr:
1. kupovina karticom, fsync
2. promena profila ili slicno, default fsync od 60 sec nakon zadnjeg fsync-a
Nisam siguran koliko je ovo pametno...
Znam da neki veliki sajtovi vec koriste MongoDb, recimo sourceforge ga
koristi, nisam siguran za sto... Samo je pitanje znati sto su mu granice
i kako ga pravilno koristiti.
Boris.
Darko Prelec
> Npr:
> 1. kupovina karticom, fsync
> 2. promena profila ili slicno, default fsync od 60 sec nakon zadnjeg fsync-a
> Nisam siguran koliko je ovo pametno...
Ja osobno taj dio sajta vjerojatno ne bi vrtio preko MongoDB, nego
preko klasičnog sustava.
Ionako ti za brzi delivery nije bitno hoće li se dio za preferences 2
sekunde brže servirati ili ne.
Osim ako se sajt ne sastoji od konstantnog updejtanja profila (MySpace, npr).
Šteta kaj ne stignem na sastanak danas...
Boris Shomodjvarac
Hm, pa to nije losa ideja, par tablica u mySQL samo za double entry
accounting, a sve ostalo ide u MongoDB.
I onako je double entry accounting prilicno statican sto se tice kolona,
uglavnom je to trx_id, line_id (ili rule_id), account_id,
account_type(ASSET,LIABILITY...), credit_amount, debit_amount, datetime,
description...
Boris.