DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 22. 05. 2012.   #1
_korso_
profesionalac
Qualified
 
Avatar _korso_
 
Datum učlanjenja: 21.06.2007
Poruke: 166
Hvala: 27
42 "Hvala" u 23 poruka
_korso_ is on a distinguished road
Default NoSql baze i iskustva

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 ?
__________________
Twitter

Poslednja izmena od _korso_ : 22. 05. 2012. u 13:37.
_korso_ je offline   Odgovorite uz citat
2 članova zahvaljuje _korso_ za poruku:
Staro 23. 05. 2012.   #2
mangia
Pukovnik u penziji
Grand Master
 
Datum učlanjenja: 11.10.2006
Lokacija: Banjaluka, BiH
Poruke: 941
Hvala: 209
552 "Hvala" u 137 poruka
mangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoro
Pošaljite poruku preko MSN za mangia Pošaljite poruku preko Skype™ za mangia
Default

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....
__________________
mangiaphoto | BLOGERAJBLOG | ServerAdminBlog
mangia je offline   Odgovorite uz citat
Staro 23. 05. 2012.   #3
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.940 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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.
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 23. 05. 2012.   #4
djipko
član
Certified
 
Avatar djipko
 
Datum učlanjenja: 03.10.2006
Poruke: 96
Hvala: 27
44 "Hvala" u 26 poruka
djipko is on a distinguished road
Default

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.
djipko je offline   Odgovorite uz citat
5 članova zahvaljuje djipko za poruku:
Staro 24. 05. 2012.   #5
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.940 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

^ 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 )
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 24. 05. 2012.   #6
_korso_
profesionalac
Qualified
 
Avatar _korso_
 
Datum učlanjenja: 21.06.2007
Poruke: 166
Hvala: 27
42 "Hvala" u 23 poruka
_korso_ is on a distinguished road
Default

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.

Citat:
Originalno napisao djipko Pogledajte poruku
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.
__________________
Twitter
_korso_ je offline   Odgovorite uz citat
Staro 24. 05. 2012.   #7
xippi
xippster
Master
 
Avatar xippi
 
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 680
Hvala: 102
138 "Hvala" u 84 poruka
xippi će postati "faca" uskoroxippi će postati "faca" uskoro
Default

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
xippi je offline   Odgovorite uz citat
Staro 24. 05. 2012.   #8
_korso_
profesionalac
Qualified
 
Avatar _korso_
 
Datum učlanjenja: 21.06.2007
Poruke: 166
Hvala: 27
42 "Hvala" u 23 poruka
_korso_ is on a distinguished road
Default

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.
__________________
Twitter
_korso_ je offline   Odgovorite uz citat
"Hvala" _korso_ za poruku:
Staro 24. 05. 2012.   #9
xippi
xippster
Master
 
Avatar xippi
 
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 680
Hvala: 102
138 "Hvala" u 84 poruka
xippi će postati "faca" uskoroxippi će postati "faca" uskoro
Default

Citat:
Originalno napisao _korso_ Pogledajte poruku
ORM za no-sql baze mislim da se zove ODM (Object Document Mapper).
u pravu si
xippi je offline   Odgovorite uz citat
Staro 24. 05. 2012.   #10
djipko
član
Certified
 
Avatar djipko
 
Datum učlanjenja: 03.10.2006
Poruke: 96
Hvala: 27
44 "Hvala" u 26 poruka
djipko is on a distinguished road
Default

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:

Kôd:
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):

Kôd:
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:

Kôd:
register_version_model(Calculation, 1)
E sada kada je model potrebno malo izmeniti:

Kôd:
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.

Poslednja izmena od djipko : 24. 05. 2012. u 21:17.
djipko je offline   Odgovorite uz citat
"Hvala" djipko za poruku:
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum


Vreme je GMT +2. Trenutno vreme je 15:59.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.