Dakle zanima me ova ideja i kako da pocnem da ucim. Procitao sam sta je, znam o cemu se radi, ali sad me zanima sta dalje. Da li je moguce koristiti noSQL sa MYSQL-om. Jer kako sam ja procitao - nije. MYSQL je relacioni tip baza a noSQL to upravo nije. Isto tako sam nasao da je Mongo ono sto mi treba. E sad bih htio ako ima neki sajt gdje cu proci osnove. Sta se sve moze, koje jezike mogu koristiti itd.
Hvala.
Hajmo poci od pocetka.
Sta podrazumjevas pod no sql-om ?
Kako ti zamisljas moguci rad “no sql-a” sa mysqlom ? Drugim rijecima ako vec imas mysql sta bi to “noSQL” trebao da radi ???
noSQL se u poslednje vrijeme prevodi kao “not only SQL”. I jasna mi je ideja.
Odg. na tvoje drugo pitanje je: Zanima me da li je moguce kombinovati noSQL i Mysql kako ovaj prvi nema npr. JOIN. Zasto bih koristio noSQL kad imam vec mySQL, zato sto je brzi kad je potrebno dohvatati velike kolicine podataka. Generalnije pitanje bi mozda bilo: moze li jedna aplikacija da koristi vise vrsta baza?
Da znam u potpunosti kako ovo radi, ne bih postavio temu.
Dakle treba mi nesto sto kad procitam da shvatim osnove noSQL-a. Dakle ne google wikipedia i sl. To sam iscitao. Tutorijal mi treba.
postgre i hstore
Jeste moguce, ali prije toga ti treba dobar dizajn i dobar razlog da koristis. noSQL baze bas i nisu dobre za neko pametnije dobavljanje ali su dobre za snimanje vece kolicine podataka. Isto tako, vecina noSQL baza podrzava indeksiranje teksta (ili eksterno indeksiranje), koje je jos uvijek svjetlnosnim godinama ispred SQL rjesenja (da Postgres ima tu mogucnost, ali se ne moze mjeriti sa nekim Solr/Lucene rjesenjem).
Sada kako bi aplikacija komunicirala sa vise baza? Prvo ocito mora da zna sheme jedne i druge i kako su podaci povezani. Uzmimo da snimas wikipedia clanke; u mongo bi mogao ici sadrzaj clanaka a u mysql meta podaci clanka, kao npr. vrijeme kreiranja, autor, zadnja izmjena i sto je najbitnije id reda sa sadrzajem u mongo. Zatim aplikacija primarno komunicira sa mysql-om (korisnik izlistava clanke, autore i sl.) i kada korisnik zatrazi sadrzaj, aplikacija pokupi iz mysql-a id reda, spoji se na mongo i zatrazi sadrzaj.
To je jedna od mogucnosti…
E to je objasnjenje koje mi je trebalo 
Tako sam i ja razumio koje su prednosti noSQL-a. E sad odakle krenuti s ucenjem?
@Bo: Za postgre sam cuo a za hstore nisam. Pogldacu i to.
ako vec kontas utrositi vrijeme na ucenje neke baze, puno ti je isplativije da se koncentrises na mysql, postgresql ili cak Oracle-a nego na noSQL. Cisto zbog ponude i potraznje na trzistu
Ovo je ogromna tema, za koju treba odvojiti vremena za proučavanje da bi se čovjek odlučio za jednu od baza. Sve ima svoje prednosti i nedostatke.
Članak koji razjašnjava razliku
Ja koristim mongodb za nodejs aplikacije, u kombinaciji sa mongoose omotačem ( objekt modelling tool ) koji ti omogućava prilično lako da manipulišaš podacima indirektno ( ako ti je native mongo težak ).
I ne samo node, već je i sa klijentske strane ( backbone ) prilično lako manipulisati bazom
Ako se odlučiš za mongodb onda je najbolje krenuti od dokumentacije:
zatim imaš ovaj odličan tutorial:
Potražnja jeste velika, ali i konkurencija. Cijela Indija i Pakistan su se navukli na MYSQL 
I za kraj admine, odšetaj do SQL baze i izbriši ova dva prazna posta gore što su mi se potkrala greškom
Pozdrav,
iako moj doprinos ovoj temi dolazi malo s odmakom probat ću ga dati zato jer nisu iznesene u potpunosti točne činjenice.
boby je pitao za neku referencu kako i gdje da počne učiti o noSQL bazama. Na to pitanje ne postoji odgovor zato što noSQL baza nije jedna neka nova baza a da postoje materijali za nju. noSQL je zapravo koncept a ne sama baza, pa tako imamo na tržištu desetke vrlo usješnih noSQL baza. Sve imaju neke zajedničke karakteristike ali su opet sve drastično različite. Npr. u skupinu noSQL baza spadaju MongoDb, CassandraDb, CouchDb, Riak, Redis, DynamoDb, Neo4j…
Sve te baze su noSQL baze a opet više/manje svaka je pogodna u nekim situacijama. Nema generalnog rješenja za sve. Ukratko usporedba pojedinih baza se dobro može ročitati u članku.
boby je rekao da su noSQL baze brže kada treba dohvatiti velike količine podataka. To je zaravo vrlo nedefinirana izjava. Klasične relacijske baze podataka su zapravo vrlo brze u dohvatu podataka. Sporost međutim nastaje kada imaš normaliziranu bazu i kada su podaci raštrkani u puno tablica i povezani su definiranim relacijama. Tada je za dohvat potpunih podataka potrebno napraviti JOIN između više tablica što je skupa operacije što se brzine tiće. prednost tog pristupa je što nema redudancije podataka. To znači da se neki podatak (npr. korisnikova adresa) nalazi samo na jednom mjestu pa je kada dođe do promjene potrebno promjeniti samo na jednom mjestu pa ne postoji mogućnost da negdje zaostanu stari podaci (koji se nisu promjenili). Sustavi za upravljanje relacijskim bazama podataka (RDBMS) uglavnom održavaju transakcijski sustav (npr. Oracle, SQL Server, IBM Informix itd.) pa su takvi sustavi vrlo pogodni npr. za bankarske sustave gdje ne smije biti mogućnosti pogreške.
Također, treba razjasniti što je to SQL. SQL (structured query language) je upitni jezik za relacijske baze podataka koji je definiran standardom. U pozadini SQL-a stoji striktno definiran matematički model koji je definirao Edgar Frank Codd. Kada se kaže sql baza podataka misli se na neki rdbms kao npr MySql, PostgreSql, Sql Server itd.
Tako da su relacijske baze podataka vrlo moćne, dugo su u upotrebi i bit će sigurno još jako dugo.
U praksi se vrlo često relacijske baze podataka denormaliziraju i to tako da se unosi redudancija podataka, a sve u svrhu smanjenja broja JOIN operacija među tablicama kako bi se dobilo na brzini. I to je uglavnom dovoljno dobra tehnika za velik broj slučajeva.
Ipak, u praksi se pokaza potreba za novi konceptima pa su tako nastale i drugačiji sustavi za upravljanje bazama podataka. Prvo su nastale tzv. objektno-relacijske baze podataka. Prijemjer takve je IBM Informix (to je ujedno relacijska i objektno-relacijska baza). To su baze koje imaju neka svojstva relacijskih i neka svojstva objektnih baza. Poanta je u tome da relacijske baze mogu spremiti samo jednostavne atomarne tipove podataka (npr. int, float, char itd.) dok objektno relacijske mogu i neke složenije tiove kao npr. lista integera.
U objektno orijentiranim aplikacijama je problem perzistencija podataka, tj. problem je spremiti neki objekt koji je složen u rel. bazu koja prima samo jednostavne tiove podataka. U takvim alikacijama je potrebno na neki način mapirati takve složene podatke u oblik koji je pogodan za spremanje u rel. baze. Često se koristi treći sustavi koji služe za takva objektno relacijska mapiranja (ORM). Primjeri takvih sustava su Hibernate za Java-u ili NHibernate za .NET.
Kako bi se riješio problem spremanja objekata u rel. baze razvijene su nativne objektne baze podataka u koje se jednostavno mogu pospremiti cijeli objekti. Primjer jedne dobre baze i vrlo jednostavne za korištenje je db4objects. I to je tzv. noSQL baza.
Općenito noSQL baze potiču redudanciju podataka u odnsu na relacijske, tj. ne postoje relacije/veze između podataka na razini samog sustava baze podataka. Tj. za povezanost između podataka se mora brinuti programer.
Svaka noSQL baza ima neke svoje karakteristike i ne može se reći ova je da je jedna bolja od druge generalno, jer su previše konceptualno različite i zapravo se više/manje svaka specijalizira za neku svrhu.
Npr. Neo4j je vjerojatno najbolja graph baza na tržištu i ako imamo aplikaciju koja je modelirana tako da imamo jako puno objekata koji su međusobno na neki način povezani onda je takva baza najpogodnija. Primjer takve baze je neka društvena mreža gdje imamo puno korisnika koji su povezani sa drugim korisnicima kao nekakvi prijatelji itd. Za detalje pogledati službene dokumentacije.
Redis npr. ima mogućnost spremanja podataka koji će se automatski izbrisati nakon definiranog vremena, pa ako imamo tako modeliranu aplikaciju redis će dobro oslužiti. K tome ima jako bogat set struktura podataka koji se mogu spremati, kao npr. povezane liste, setovi i sl. K tome je i izuzetno brz pa se često koristi umjesto memcached-a za cache-iranje podataka.
Neo4j i redis nemaju baš ništa zajedničko a ih se ne može uspoređivati i tamo gdje odgovara jedna baza druga za tu istu namjeru vjerojatno neće pasati. Želim reći da sve ovisi, kako je netko naveo, o samom modelu aplikacije i potrebama.
Sanel je rekao da većina noSQL baza podržava indeksiranje teksta dok to rlacijske baze ne podržavaju. To je zapravo dosta kriva formulacija. Apache Solr sustav za indeksiranje sadržaja koji je dao kao primjer nema nikakve veze sa samom bazom. Solr indekseru se mora dati sadržaj koji se želi indeksirati a taj sadržaj može biti pospremljen bilo gdje. Samo za primjer, uz Apache Solr najčešće se spominje Sphinx sustav za indeksiranje. Radio sam na razvoju nekoliko news portala kao što su npr. vecernji.hr ili zurnal24.si. News portalima je važno da imaju učinkovitu pretragu članaka. Svi podaci su bili sremljeni u MySql bazu ali oni podaci koji su bitni za brzo pretraživanje su dodatno spremljeni u Sphinx index. Isto tako su mogli biti spremljeni i u Solr, tako da sustavi za indekiranje nisu nikakva karakteristika noSQL baza već su to zasebni potuno neovisni sustavi.
Dalje je navedeno da su ti sustavi za indeksiranje teksta u noSQL bazama svjetlosnim miljama ispred sustava koji su ugrađeni u relacijske baze. Kao što sam rekao, Solr je odvojeni neovisni sustav koji nije karakteristika noSQL baza pa se onda to i ne može uspoređivati.
Neke rel. baze kao nr. MySQL ili PostgreSql imaju svoje sustave za indeksiranje. MySql ima tzv. “Fulltext search”. Stvar u praksi zapravo ide tako da i kada koristiš relacijsku bazu podataka a imaš potrebu za pretragom teksta tada moraš upogoniti neki pametni sustav za pretrau teksta kao što je Solr ili Sphinx, ali za sremanje podataka i dalje se može koristiti rel. baza.
Dakle, zaključak je da se ne može reći dali su bolje SQL ili noSQL baze jer sve ovisi o potrebama sustava. Drugo pitanje je bilo da li se mogu unutar iste aplikacije koristiti različiti sustavi baza podataka.
boby je negdje pročitao da se to ne može. To je naravno besmislica. Naravno da se može. I to se radi u većim aplikacijama koje za to imaju potrebu.
Npr. na projektu na kojem trenutno radim starvibes.com obilato koristimo nekoliko različitih sustava za upravljanje bazama podataka u isto vrijeme. Također i sustavi kao što su LinkedIn, Facebook i sl. koriste više različitih baza podataka, sustava za indeksiranje, sustava za cacheiranje itd.
Moglo bi se zaključiti da kod glomaznih sustava dolazi do potrebe za različitim bazama, no takvih sustava jasno nema jako puno.
Ne moram niti reći da je upravljanje različitim bazama u isto vrijeme izuzetno složeno, pa stoga boby dobro razmisli da li uopće imaš potrebu za time.
Za kraj… kako ne znam koje su potrebe aplikacije nemoguće je preporučiti neku noSQL bazu ali MongoDb je baza koja pokriva jako puno stvari i vrlo vjerojatno najviše odgovara raznim potrebama. Izuzetno je popularna, brzo se razvija, ima veliku zajednicu korisnika i odličnu dokumentaciju. Puno se koristi pa je svakako dobar potez naučiti dobro MongoDb.
No, na primjeru mog projekta, mi smo odustali od MongoDb-a i prešli smo na Amazon DynamoDb zato što kod MongoDb baze nije najbolje riješeno pitanje shardinga koje mislimo da će nam trebati. No sharding će biti potreban kada bude toliko puno paralelnih korisnika da sam Mongo postane usko grlo aplikacije, tj. kada Mongo ne bude mogao u razumnom vremenu poslužiti sve zahtjeve.
Ukoliko se ne radi o aplikaciji koja će jako skalirati takvih problema nema i Mongo je izvrsno rješenje.
Samo primjer kako odabir baze zapravo ovisi o potrebama.
Razdužio sam ovaj post više nego sam mislio. Nadam se da sam malo razjasnio stvari, tj. da nisam unio dodatnu pomutnju
Ja ne bih sad ulazio u priče o tome šta je brže, bolje, koliko svjetlosnih godina ispred i sl. Sve zavisi od toga kakvu aplikaciju pravite, za koliko korisnika, da li ste search engine ili niste itd.
Svima onima koji su zagrijani za NoSQL tehnologije bih preporučio da naprave misaoni eksperiment i zamisle kakav “database/data storage” softver će koristiti za 1, 5 ili 10 godina. Da li će to biti trenutno moderni NoSQL favorit, ili nešto totalno drugo (ko će biti živ a ko mrtav, kao tehnologija …)
Anyway, svako konja za trku imade, ja bih pak preporučio držati se klasike dok god je to moguće (dakle, RDBMS i SQL), a ako već pričamo na temu full text search-a, evo i jedne zanimljive prezentacije za PostgreSQL/Python/Flask
http://coffeecode.net/archives/270-A-Flask-of-full-text-search-in-PostgreSQL.html
Prilično informativan post, mada možda malo napredan.
Ja trenutno sjedim na dvije stolice - sql i nosql. To znači da bazu za aplikacije ( male i srednje ) obično izradim i u Mongodb i Mysql.
Kada sam počinjao sa učenjem baza, bio sam u raspoloženju da se odlučim samo za jednu. Međutim učiti nosql znači neprestano se u primjerima osvrtati na sql. Primjer - Mongodb tutorijali neprestano govore kako se ne koristi joins ili kako je kolekcija ekvivalenta sql tabeli.Prema tome, morao sam sažvakati obe.
Mogu reći da mi je sad mnogo lakše jer baze posmatram kao generalni koncept koji ima svoje implementacije u nosql i sql varijantama (recimo). Kad radim sa jednom od njih, samo napravim mentalni switch u sintaksu i sve ide.
Još jedan argument u korist nosql baza je taj što podatke praktično modeluješ programski u jeziku u kojem i pišeš aplikaciju. Recimo Javascript driver podatke u bazi posmatra kao čisti JSON. Sql je u tom smislu potpuno nezavisan jezik sa sopstvenom sintaksom i paradigmom.
Potpuno razumijem Adisa sa stavom da je bolje držati se provjerenih recepata, ali dodajem da se treba kretati dalje. Po meni, nosql nije nekakva eksperimentalna tehnologija koja je trenutno zablistala, već predstavlja izuzetno jak i kvaliteten izazov postojećim sql šablonima.
Ima tu još mnogo argumenata za nosql. Kao i za sql.
Interesantan je govor Martina Fowlera, tvorca activerecord patterna, koji je u stvari interfejs za pristup sql bazama.
Koliko sam ja pročitao, activerecord je u stvari srž ORM-a.
Fowler se dosta pozitivno izjašnjava o nosql bazama i vrijedi ga poslušati: http://www.youtube.com/watch?v=qI_g07C_Q5I
U svakom slučaju, jako interesanto vrijeme za bavljenje rezvojem web-aplikacija.