NoSql baze i iskustva

[_korso_]

U poslednje vreme (zadnje 2 godine) se sve vise prica o no-sql bazama. Iako izgledaju kao zgodan alat za neke stvari, sigurno da nisu zamena za RDBMS u svakoj situaciji.

Istrazivao sam malo na tu temu i cini mi se da su ove baze pogodne za neki tip web-based aplikacija, koje ne zahtevaju transakcije u isto vreme nad vise tabela (dokumenata), a npr. zahtevaju cesto radi prikaza ili izvestaja, agregaciju rezultata iz vise tabela (sto su tabele normalizovanije to je veca petljancija izvuci neke podatke). Kao primer, vrlo cesto zbog takve organizacije UI-a (sve na izvol'te) dolazi se u situaciju da treba da se radi JOIN nad 6-10 tabela, pa dodatno filtriranje, grupisanje, limiti itd... Nekada stvarno postaje PITA, a i sporo. Ok, tu su indexi i explain, ali voleo bih da bude nesto "lakse".

Govoreci no-sql terminologijom, to bi se pamtilo na nivou jednog dokumenta, jedne kolekcije, dok npr. stvari koje se mnogo cesto updateuju, ili rezultati nekih pretraga se mogu pamtiti u Redisu.
Siguran sam da ima i neki losih strana ovakve organizacije koje treba pokriti. Nisam testirao i radio u real-time uslovima sa ovakvim tipom baze, tako da sve sto bih izneo su manje-vise pretpostavke i razmisljanja.

Evo jednog linka, gde se uporedjuju neki od popularnih no-sql enginea: http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

Gledao sam najvise MongoDB, posto je bas velika buka oko njega. Medjutim naleteo sam i na par clanaka na netu gde ljudi nisu najzadovoljniji istim (http://blog.engineering.kiip.me/post...r-with-mongodb, http://www.zopyx.de/blog/goodbye-mongodb - neki od argumenata su apsolutno validni). Dok, eto Trello ili stackexchange ga guraju uspesno.

Glavni zahtevi koje bi trebalo da podrzi no-sql baza su relativno lako skaliranje (master-slave), lakse pisanje tipova upita ili ubrzanje koji su pandan pisanju JOIN-a ili subselecta nad vecim brojem tabela u RDBMS svetu i uopste stabilno okruzenje da tako kazem (gde nece tek tako da podaci nestanu od sebe).

Sigurno cu se pozabaviti i sam vise ovim i istraziti i testirati neka resenja. Interesuje me da li je mozda neko imao iskustva sa ovim i naravno ako moze da to podeli ?

[mangia]

Mislim da daleko više pljuvačine možeš pronaći o MySQL-u recimo pa opet rula mnogo velike projekte...

Boj ne bije svijetlo oružje....

[ivanhoe]

Moje iskustvo sa mongom je odlicno, ali naravno ja nisam pravio Facebook (a ni Trello). Osnovna prednost u mom slucaju (tracking bannera) je sto su upisi stvarno brzi i sto ti NoSQL daje jednostavan nacin za organizaciju i kasnije dump podataka u komplexnu strukturu sa kojom je lako posle raditi.

Kod RDBMS moras da pravis komplikovane JOIN-e, pa da onda tako dobijene tabelarne podatke slazes u petlji u objekte koji ti trebaju, ovde je to vec tako kreirano u bazi i samo povuces ono sto ti treba. Em zahteva manje koda, em je dosta brze na vecoj kolicini podataka.

[djipko]

Jedna stvar koju ti ne kazu kada pocnes da radis sa nosql-om - koju bi i sam provalio ali mozda suvise kasno: UVEK cuvaj strukturu dokumenta u kodu i UVEK koristi polje za verziju scheme (ovo vazi ako ti podaci za koje koristis nisu ultra kratkog veka)

Sta pod tim mislim - za razliku od RDBMS-a, Mongo nema strukturu dokumenta (dakle CREATE tabele) - sto znaci da mozes u istu kolekciju da upisujes sta ti je volja... ova sloboda ce te ujesti pre ili kasnije tako sto ces imati kod sa 400 if-ova koji proveravaju da li dokument ima ovo ili ono.

Moj savet - definisi strukturu dokumenta u klasi (nesto kao jako tanki ORM), i ako mislis da ces menjati strukturu dokumenta - dodaj jedno polje koje oznacava trenutnu verziju (koje je recimo globalno i definise se na jednom mestu).

Kako kod i schema evoluiraju - sve promene ce se svoditi na to da u read() metodi procitas dokument - proveris polje 'verzija' i kastujes ga u odgovarajucu nasledjenu klasu tvoje osnovne ORM klase.

Ako nekoga zanima ili mu nije jasno na sta ciljam - mogu da bacim neki snippet da ilustrujem.

[ivanhoe]

^ dobar pristup, a jos jedan razlog za to da imas precizno definisan model, bar kod MongoDB-a, je sto on ne baca greske ako u upitu trazis polje koje ne postoji, tipa slucajno umesto counter otkucas coumter. A takve greske su uzasno teske za debug, narocito kod upita koji dohvataju podatke, jer je spelling otprilike poslednja stvar koju se setis da proveris (well, prvih 10 puta bar )

[_korso_]

Koliko sam procitao i video, sa jedne strane no-sql daje fleksibilnost, dok sa druge strane (ako nisi disciplinovan i dosledan) mozes da upadnes u problem.
Dosta ljudi pominju da za razliku od mysql migracija, kod MongoDB-a koriste upravo verzije dokumenata, sto im omogucava laksi upgrade/izmene baze.

Originalno napisao djipko

Moj savet - definisi strukturu dokumenta u klasi (nesto kao jako tanki ORM), i ako mislis da ces menjati strukturu dokumenta - dodaj jedno polje koje oznacava trenutnu verziju (koje je recimo globalno i definise se na jednom mestu).

Kako kod i schema evoluiraju - sve promene ce se svoditi na to da u read() metodi procitas dokument - proveris polje 'verzija' i kastujes ga u odgovarajucu nasledjenu klasu tvoje osnovne ORM klase.

Ako nekoga zanima ili mu nije jasno na sta ciljam - mogu da bacim neki snippet da ilustrujem.

U sustini je jasno... ali ako te ne mrzi baci neki snippet - ne moze da skodi.

[xippi]

struktura dokumenta jednostavno mora da se cuva. ono sto je orm kod relacionih baza to je object/data mapping za nosql. sto se samog monga tice za asinhrono okruzenje postoji mongoosejs koji podrzava sheme, nestovanje istih, validaciju, itd. postoji nekoliko data mapping libova za rails i ostale jezike

[_korso_]

ORM za no-sql baze mislim da se zove ODM (Object Document Mapper).
Potpuno mi je jasno da se trebaju u client kodu mapirati "definicije" baze (kolekcija i dokumenata). Kako radim sa custom napravljenim ORM alatom (koji je godinama peglan), upravo iz tih definicija se izvlace podaci za validaciju, za castovanje podataka na relaciji db-code, te za data migracije i za jos x stvari. Tako da mi je ideja kada i ako dodje do same implementacije, da se isti pristup primeni i za mongo ili neku drugu document bazu.

Za PHP postoji Doctrine ODM.

[xippi]

Originalno napisao _korso_

ORM za no-sql baze mislim da se zove ODM (Object Document Mapper).

u pravu si

[djipko]

Naravno da postoje razni gotovi mapperi ali svaka dodatna biblioteka u projektu zna da ima i svoju cenu. ODM-i nisu teski i mogu biti zabavni za pisanje, posebno ako ti za tvoje potrebe ne treba sva masinerija koju nude OSS resenja.

Posto sam obecao primer evo ga za python. Primer je vrlo jednostavan mada ovo sve moze mnogo vise da se zakomplikuje.

Dakle osnovna klasa i globalno mesto gde se registruju modeli i verzije bi bili u modulu koji bi izgledao otprilike ovako:

from pymongo import Connection

version_reg = {} #"Globalni" dict koji cuve verzije

def register_version_model(cls, version):
    """Registruj klasu koja je model za odredjenu verziju scheme"""
    version_reg[version] = cls

def get_version_by_model(cls):
    """Vrati za koju verziju scheme je registrovana klasa"""
    for v, c in version_reg.iteritems():
        if c is cls: return v
    return None
    
class MongoBaseModel(object):
    """Klasa koju svi mongo modeli nasledjuju, i redefinisu potrebne metode"""

    _db = 'test_db'
    _collection = 'test_col'

    def _to_dict(self):
        """
        Ova metoda mora da se redefinise - ona ustvari 
        sadrzi logiku predstave modela u bazi.
        """
        raise NotImplementedError

    def save(self):
        #Napravi od sebe dict
        d = self._to_dict() 
        #vidi gde si registrovan, i zapisi to u bazu
        d['version'] = get_version_by_model(self.__class__) 
        Connection()[self._db][self._collection].insert(d)

    @classmethod
    def read(cls, spec):
        """
        Metoda procita dokument ako postoji, i na osnovu verzije konstruise
        objekat i vrati ga
        """
        doc = Connection()[self._db][self._collection].find_one(spec)
        if doc:
            model_cls = version_reg.get(doc['version'], None)
            if not model_cls:
                raise ValueError("No model registered for this version")
            return model_cls(doc)
        return None

I onda zatim pravis svoj model (evo ga jako jednostavan primer):

class Calculation(MongoBaseModel)
    """Zamisljena klasa kalkulacije ciji se rez cuva u bazu"""
    def __init__(self, doc):
        self.date = doc['date']
        self.result = doc['result']
    
    def _to_dict(self):
        """Obrnuto od konstruktora - u ovom primeru nezanimljivo"""
        return dict(
            date = self.date
            result = self.result
        )

Koji i registrujes sa:

register_version_model(Calculation, 1)

E sada kada je model potrebno malo izmeniti:

class NewCalculation(MongoBaseModel)
    """Nova klasa kalkulacije koja sada cuva i koliko je kalc trajala"""
    def __init__(self, doc):
        self.date = doc['date']
        self.result = doc['result']
        self.duration = doc['duration']
    
    def _to_dict(self):
        """Obrnuto od konstruktora - u ovom primeru nezanimljivo"""
        return dict(
            date = self.date
            result = self.result
            duration = self.duration
        )

register_version_model(NewCalculation, 2)

Ono sto se ne vidi iz primera je da ako ove dve klase nasledjuju od trece klase koja definise neki interfejs za rad (i pegla nesuglasice) - potpuno si se resio glavobolje tipa - "sta sam to procitao??". Nekad je OO i dobar

Kao sto sam rekao moze ovo mnogo vise da se zakomplikuje i nabudzi (metaprogramiranjem i slicnim cakama), naravno fale provere gresaka itd. ali funkcionalni, mali i lagani ODM ne trazi mnogo vise od ovih 30ak linija u Pythonu, bez da se patis sa nekim bloat-om sa github-a.

Ako nekome neka python-specific caka nije jasna (mada ih bas i nema u gornjem kodu) rado cu pojasniti.