Da li MySQL odlazi u istoriju ?

Da li je došlo vreme da MySQL okači patike o klin i tiho se povuče u zasluženu penziju?

Mnogim web programerima ova baza podataka predstavlja nezaobilazni alat za razvoj web aplikacija i upravo je ova baza podataka zadužena za čuvenje podataka na najvećem broju sajtova. Uprkos ovim činjenicama, ova baza podataka nema svetlu budućnost.

Razvoj Interneta i socijalnih mreža koje okupljaju ogroman broj korisnika, među kojima prednjači Facebook sa preko 500 miliona korisnika, uticao je da se uzdrma MySQL i potraže alternativna i inovativna rešenja. Sam Facebook je doprineo razvoju i unapređenju InnoDB endžina, ali kako bi postigli skalabilnost morali su da pokrenu razvoj sopstvenih rešenja (Cassandra).

Skalabilnost

Skalabilnost je mogućnost aplikacije da ponese povećanje zahteva i broja korisnika a da sama aplikacija ne mora da se menja. Što je aplikacija skalabilnija ona će lakše podneti povećan protok podataka. Cilj kojim teže svi projektanti sistema jeste da se postigne linearnost u brzini odgovora na zahtev i količine podataka sa kojima se manipuliše.

Postoji horizontalna skalabilnost i vertikalna skalabilnost kada govorimo o samom hardveru.

Vertikalna skalabilnost je kada se je aplikacija smeštena na jedom serveru, a na povećan protok reagujemo tako što serveru dodajemo memoriju, jači procesor, nova jezgra ili dodatni hard disk.

Horizontalna skalabilnost je idealnije rešenje, posebno za velike sisteme. Dodavanjem novih nodova sistem nastavlja da radi kao do sada samo sa novim igračem(nodom) u timu. Nod predstavlja jedan server.

Kada web aplikacija dođe do stadijuma da povećan broj podataka sa kojima se manipuliše utiče na brzinu odgovora na zahtev, tj na učitavanje stranica, možemo reagovati na više načina:

  • Uložiti gomilu novca u kupovinu hardvera koji će moći da se nosi sa novonastalom situacijom.
  • Misliti na vreme i dizajnirati samu aplikaciju tako da bude skalabilna, a to ćemo postići tako što ćemo na probleme odgvarati rešenjima koja podižu performanse. Ne postoji univerzalan odgovor već svaki scenario i svaka situacija zahtevaju posebno rešenje. Ukoliko sama aplikacija nije skalabila, treba pronaći usko grlo i na za njega odgovarajuće rešenje. U relacionim bazama podataka čest odgovor na probleme jeste denormalizacija. U školama ste učili da treba koristiti normalizaciju, ali sada ne pravimo anketu koju će popuniti vaše kolege sa klase, ovo je realnan svet sa 500 miliona korisnika i nekoliko milijardi otvorenih stranica dnevno.

Prvi način je jednostavan ali ima svoja ograničenja jer ne postoji hardver koji može podneti loše optimizovanu i neskalabilanu aplikaciju. Za drugačiji pristup je potrebno više vremena, kreativnost i tim programera koji voli izazove.

Zašto više ne volim MySQL ?

MySQL je kreiran kao rešenje koje će odgovoriti na svaki zahtev bilo da razvijate CMS, news portal, bankarski sistem ili socijalnu mrežu. Koristili ste MySQL i za velike zapise u jednom slogu, i tabele koje imaju nekoliko miliona zapisa sa malim sadržajem. Da li je moguće da je MySQL dobar u svakoj opciji i za svako rešenje ? Naravno da nije.

Šta je ono što od MySQL-a pravi tromo i neskalabilno rešenje ?  MySQL nudi mnogo blagodeti programerima, i one su i mač sa dve oštrice. Inner join upiti su veoma spori i problematični posebno sa velikim brojem zapisa. Još jedan mač jesu transakcije, koje su funkcionalnost bez koje se ponekad ne može. Transakcije su neizostavne kada je reč o aplikacijama koje vode računa o bankarskim transakcijama ili e-prodavnicama. Ali upravo ove funkcionalnosti utiču na to da MySQL bude sporiji od konkurencije.

NoSQL kao sinonim za skalabilnost

“NoSQL je kao seks u srednjoj školi. Svi o njemu pričaju a malo njih ga je zaista i probalo” – Emmanuel Bernard.

NoSQL rešenja se u poslednjih nekoliko godina rapidno razvijaju i postoji veliki broj NoSQL baza podataka i key-value servisa. Cilj svih ovih projekata jeste da se postigne visoka skalabilnost i brzina.

Odgovor na pitanje koje ću rešenje da koristim za čuvanje svojih podataka više nikada neće biti jednostavan, i biće ih više od jednog.

U praksi danas ćete sresti aplikacije koje koriste više od jednog rešenja za skladištenje podataka. Razlog leži u tome što svaka funkcionalnost traži posebnu analizu i rešenje. Svako od NoSQL rešenja ima svoje predosti i mane, i za svaku funkcionalnost morate pronaći najbolje odgovarajuće NoSQL rešenje.

Facebook je razvio Casandra sistem za email index search, ali to ne znači da će oni Casandru koristiti za svaki deo aplikacije. Naprotiv oni će Hbase koristiti za razmenu poruka korisnika, jer su njihovi inženjeri procenili da će ovo NoSQL rešenje najbolje odgovoriti zahtevima.

NoSQL baze podataka se ne trude da zadovolje sve zahteve i neće žrtvovati performanse zarad mogućnosti. To znači da u nekim NoSQL rešenjima nećete imati ACID i transakcije, ili nešto sto bi bio pandam inner join-u. Ovo ne znači da je NoSQL lošiji od MySQL-a već da je koncipiran na drugi način i da ćete morati da promenite način razmišljanja pri dizajnu i programiranju DAL sloja aplikacije.

MySQL je najbolje rešenje za aplikacije koje insistiraju na ACID-u, tamo gde su transakcije neophodne, kao što su e-prodavnice ili bankarske applikacije.

Važnije od toga koju tehnologiju ćete koristiti za skladištenje podataka, jeste da na problem odgovorite inteligentnim rešenjem. Odgovor na pitanje kako da postignete skalabilnost aplikacije, ne možete naći na Internetu niti vam na to bilo ko može odgovoriti. Odgovor leži u tome da budete otvoreni za nova rešenja i da ih testirate u samom radu na vašim konkretnim realnim problemima.

MySQL neće u penziju još neko vreme, imajući u vidu njegovu zastupljenost na webu i to da će za većinu aplikacija na web-u MySQL biti sasvim prihvatljivo i rešenje. Sa druge strane MySQL Cluster podiže MySQL na viši nivo skalabilnosti.

Ono što ne ide u prilog MySQL-u jeste da su NoSQL rešenja daleko brža i skalabilnija i da je sve više web aplikacija i servisa koji ih u većoj ili manjoj meri koriste. Veliki servisi kao što su Facebook, Twitter, Thumbl ne mogu zamisliti svoj rad bez NoSQL rešenja.

Pravo je vreme da se upoznate sa NoSQL-om, da ga istražite i primenite u svom radu. Revolucija se već odigrala, i za nekoliko godina NoSQL će biti standard za skladištenje podataka na webu.

4 Responses to Da li MySQL odlazi u istoriju ?
  1. Данило Reply

    Revolucija se već odigrala, i za nekoliko godina NoSQL će biti standard za skladištenje podataka na webu.

    Неће. Оно што се мора разликовати је начин складиштења података (РСУБП/„складишта објеката“) од упитног језика. Као што се SQL језиком може задати веома неоптималан упит на једном РСУБП, тако се SQL језик може користити за упите на нерелационим системима. Мада вероватно ниједна NoSQL база у скорије време неће омогућити упите на SQL језику, сигурно је да ће понудити језике сличне њему који омогућавају и inner join имплементирајући га на најбољи могући начин за тај систем.

    Уопште недостатак образовања и разумевања самог ACID-а код ширег броја програмера, који данас представљају основне творце веб садржаја, ће довести до такве ујдурме и таквих пропалих пројеката у које је уложено много да ћемо врло брзо опет певати хвалоспеве трансакционим системима који бар нешто гарантују.

    Е сад, таман посла да оно што се популарно назива „NoSQL“ базама нема своје место под сунцем (а ко има потребе за тако нечим је јасно и из изнетих примера). Наравно, њихова највећа предност јесте у водоравној растегљивости (хоризонталној скалабилности ;), пошто су углавном дизајниране да реше управо тај проблем.

    Са друге стране, апсолутно је могуће направити базу у РСУБП која неће задовољити ниједан од ACID/трансакционих захтева (нпр. не коришћењем страних кључева). Самим тим се могу постићи сличне перформансе ако се и упити ограниче на нерелационе.

    Да не дужим, мислим да је ово врло отворена тема, али да је релациони системи за управљање базама података бити врло присутни (и да ће свакако преовлађивати) — само је питање колико ће брзо постати квалитетно/лако растегљиви, пошто они већ нуде све што и „NoSQL“ базе у својој теоријској основи, али успут и много више ако то желите да користите.

    ПС. Моје искуство је углавном засновано на Постгрес бази, са MySQL-ом нисам радио озбиљно већ неколико година.

  2. Данило Reply

    Успут, да још кратко напоменем: ако база не обезбеди трансакциони интегритет, онда ће то бити на програмеру да уради. Да ли заиста верујеш да ће просечан програмер (а ниво знања потребан за ту квалификацију непрестано опада, и то сматрам позитивним) бити у стању да води рачуна о искључивости приступа, изгладњивању и осталим тешким теоријским проблемима рачунарства?

    Ја не.

    То што ће велики системи као што су Фејсбук, Гугл и слични морати да жртвују понешто од комотности за њихове програмере ради перформанси, то је само зато што ће они моћи да приуште да запосле програмере који ће разумети све проблеме у потпуности. Али не, Интернет неће, пошто је Интернет баш супротност монолитима као што су Фејсбук и Гугл — гомила малих јединица сједињених у велику глобалну мрежу.

  3. Milan Popovic Reply

    Zanimljiv pogled na ovu temu moze se naci na ovom video materijalu

    http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale

  4. InterstellarOverdrive Reply

    Prvo, jako zanimljiv blog, čestitke. Naiđoh na ovaj tekst guglajući malo o Cassandri na srpskom. Složio bih se sa g. Danilom; relacioni model je previše dobro smišljen da bi tek tako bio otpisan, i ne verujem da će u doglednoj budućnosti biti zamenjen. S druge strane NoSQL postaje de facto standard kada se radi o projektima gde se na dnevnom nivou obrađuju gigabajti/terabajti. Za većinu projekata SQL će biti dovljno dobar, normalizovan ili delimično denormalizovan, ali sasvim dovoljan.
    Svakako se nadam da će Cassandra privući veću pažnju i domaćim developerima, jer se radi o izuzetnoj tehnologiji koju vredi isprobati.

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

20169 pregleda