NoSql baze i iskustva

[_korso_]

^ Hvala puno na trudu i primeru.

Primer je u sustini jasan, posto ima i inline komentara. Mada moze se kao sto kazes zakomplikovati, sto validacijom, sto meta definicijama, a sto jos nekim apstrakcijama. Sto vise automatizma i magicnih stvari to ce biti i kompleksnija implementacija.

Imao bih samo jos 2 pitanja, posto vidim da imas iskustva sa MongoDB-om.

Kako se sajt ili app (ne znam da li je jedna ili vise koje si radio) ponasaju ukoliko ima malo veceg opterecenja istih - npr. par stotina konkurentnih zahteva u sec? Najvise mislim na race-conditions posto koliko sam shvatio, MongoDB zakljucava celu bazu dok se za jednog korisnika obradjuju podaci?

Da li si naisao na jos neke da kazem "klopke" kojih nema u RDBMS svetu. Jedan od primera je ovo verziranje polja. Drugi... video sam na par mesta kada se prave polja u bazi, da samo ime zauzima resurse baze. Ako imas 1000 korisnika u kolekciji users, "username" polje se 1000x pamti, da tako kazem. Pa onda radi optimizacije i performansi npr. mapiraju ga u "usn", pa ga onda "remairaju" u username u samom server/client kodu. Na ovaj nacin (procitah pre neki dan, ne secam se gde) neko je bazu sa 700MB, smanjio na 300MB, sto je vise nego pola.

[djipko]

Nema na cemu

Sto se tice prostora - moj primer je tu uzasno neefikasan jer za SVAKI record cuva verziju. Ovo je nesto sto bi radio u pocetku razvoja, kada postoji velika mogucnost da ces imati izmena same scheme, ili ako ne maris previse za prostor (Mongo je inace vrlo "bahat" sto se prostora na disku tice, barem sa default parametrima, a i ne zaboravimo da po defaultu dodaje svoj _id na svaki record, tako da ako ti je prostor problem - sigurno moze bolje od onoga sto mongo radi po defaultu).

Sto se lockovanja tice, mislim da to zavisi od tvog deployment-a. Mongo nije MySQL i sfere u kojima se oni koriste nisu skroz disjunktne, ali se i ne preklapaju u potpunosti. Opisacu ti ukratko kako ga mi koristimo, ali po meni svaki slucaj je drugaciji. Ako mene pitas nakon nekog vremena sam poceo da razmisljam da je Mongo u klasi sa Memecahced-om (samo nabudzen) bre nego sa raznim RDBMS-ovima.

Dakle: mi koristimo ReplicaSet opciju gde imamo master u koji se pise (to ne rade web workeri, nego za to koristimo taskove - za queue inace isto koristimo mongo ali to je nevezano za celu pricu). Front end web serveri imaju svaki svoj mongo koji replicira mastera, i u te mongo-e se nikad ne pise (osim replikacije naravno ali je ona jako brza) vec samo cita iz njih. Dakle lag replikacije postoji (otud ona rec 'eventual' u frazi 'eventual consistency'), ali je nama nebitan, dakle kao sto rekoh zavisi od aplikacije (mi imamo peakove sa nekoliko stotina upisa, ali realnost je par desetina u sekundi).

Sami upisi na mastera su uzasno brzi - ali kad kazem uzasno mislim jako uzasno, hiljade u sekundi, pre ce ti algoritam biti bottleneck nego Mongo.

Ovo sve sto sam ti opisao sa ops strane nije trivijalno, ali nije ni nocna mora (Mongo ReplicaSet nije bas jednostavan za koriscenje, srusio nam je sajt 2 puta dok nismo provalili kako bezbolno da dodajemo servere, ali se sve zavrsilo na fabric skripti od par stotina linija koja to sada vrlo bezbolno radi).

Sto kazu ono TL;DR:

Mongo je okej sistem, ima svoje mracne strane, ali u definitivno vise nego pristojan. Sve zavisi od tvoje aplikacije, ali kad razmisljas o tome gde da ga koristis (a i vecinu nosql resenja), pre razmisljaj: memcached sa vise opcija a slabijim performansama (isto pogledaj i Redis), nego felksibilniji MySQL.

PS. Nije bas tako strasno sto zakljucava celu bazu - pogledaj http://www.mongodb.org/display/DOCS/...ncurrency+work ali ako ti je to problem mozda ti treba redizajn .

[_korso_]

Prostor na disku nije problem, mada bez obzira na to nismo za rasipanje resursima.

Inace Redis ce verovatno biti u stacku posto nam je potreban pub-sub za real-time.
Pa su sada varijante, nosql ili Mysql, gde bi one stvari koje su usko grlo, ako je nosql isle manje u Redis (posto pomenuh da je vec skoro izvesno clan stacka i da moze da radi i kao Memcache), ili ako je Mysql onda bi vise stvari imalo neki vid predstavljanja u Redisu.
Sustina je da posto ce biti dosta sadrzaja u vidu agregacije da tako kazem, da ubrzamo i sprecimo masivno pisanje JOIN-ova nad x tabela. Trenutno nemamo bazu, pa mi je jedan od ciljeva da sada ako moze identifikujemo stvari kojih se treba paziti ili obratiti vecu paznju ako radimo sa MongoDB-om (slicno sto si pomenuo da ti niko nije rekao da treba verzirati polja).

U svakom slucaju, jos jednom ti hvala puno na trudu i vremenu. Imao bih jos par pitanja, ali neka budu ovo za sada. Dosta si mi pomogao i ovako .

[djipko]

Meni zvuci super zanimljivo to sto pokusavate (ako sam dobro razumeo). Moj savet - probajte prvo braindead pristup - memcached ispred mysql-a sa lukavo odabranim diskriminatorom... dobre su sanse da ce vas samo to daleko odvesti.

Ja sam uvek protiv komplikovanja ako nije bas nuzno

[_korso_]

Slazem se sa tobom. I mi smo za KISS .

Odatle i npr. odluka da ne koristimo Memcache, kada vec imamo u stacku Redis koji moze da potpuno zameni Memcache funkcionalnost.
Problem kesiranja, pub-sub resen - barem na papiru.

Sada sama baza - persistence sloj. Nemamo iskustva za Mongom, ali imamo sa par RDBMS. Znamo sta nam je problem u RDBMS-u, ali ne znamo u Mongou. Jeste brzi za stvari koje nam treba (JOIN replacement), jeste donekle parsovanje rezultata na relaciji db-app lakse (strukture objekata vec cuvamo u MongoDB onakve kakve ih "skoro" i koristimo), ali opet nemamo nijedan nosql production projekat, pa imamo nepoznanice.

Videcemo...