Vlákno názorů k článku
Používat či nepoužívat MySQL?
od hibernatus - uff, tak som si ten clanok precital;
z osmich...
-
uff, tak som si ten clanok precital;
z osmich "zvucnych" dovodov proti MySQL sa vyklulo 8 blabolov.
prvy dovod je, ze MySQL pouziva GPL, druhy dovod, ze nepouziva GPL. autor sa zrejme nevedel dohodnut sam so sebou. ano, existuju pripady, ked GPL nevyhovuje - hoci to nie je vseobecne uplatnitelna nevyhoda MySQL. to, ze pre firmy, kt nechcu redistribuovat svoj kod na baze MySQL pod GPL, existuje aj komercna licencia, za ktoru treba platit je asi ocividna nehoraznost.
treti bod hovori o "integracii" s existujucim prostredim - presnejsie o tom, ze ked ste si uz kupili nejaku inu DB, tak sa vam neoplati instalovat este aj MySQL. s tym v principe suhlasim, ale nie je to nic co by neplatilo vseobecne pre ktorukolvek DB. autor by si tiez mohol ujasnit pojem integracia.
v stvrtom bode rozobera "vyspelost produktu" (product maturity). ehm, na zaklade poctu rokov na trhu... (nu z tohto pohladu je aj firefox oproti msie len babatko bez prava na pouzivanie)
piaty bod - vyspelost funkcionality. v tomto nie som specialista, no cakal by som viac, ako konstatovanie, ze niektore funkcie su k dispozicii len v poslednej verzii.
6 - dostupnost certifikatov. hm, absolvovat trening s peciatkou sa neda na tolkych miestach ako pre Oracle/MSSQL. to vazne ubera vykonu databazy...
7 - korporatne zazemie. hm, nemozete si kupit akcie fy. MySQL AB. to niektorych manazerov vystrasi k smrti...
8 - "vnimanie skalovatelnosti". autorovi sa nepaci, ze MySQL vyzdvihuje svoju horizontalnu skalovatelnost (viac serverov) a nespomina vertikalnu (silnejsie servery). FUD. iba ak by bola uvedena studia, ktora ukazuje, ze MySQL nedokaze vyuzit viacprocesorove stroje, akceptoval by som to ako pripomienku nevyhodnu v niektorych prostrediach (specialne tam, kde je v serverovniach malo miesta a maju bohate IT oddelenie - (viacprocesorove stroje su zvycajne drahsie ako viac menejprocesorovych - pri rovnakom pocte CPU & RAM. plati napr. pre HP, Sun))
sice je mile, ze autor ten clanok napisal vo vi, ale publikovat ho teda nemusel.
na root.cz by bolo tiez celkom fajn, keby spravicky uvadzali hodnotnejsie zdroje - keby autor aspon precital odkazovany text - aj ked aspon je diskusia :) -
Vyjadrim se pouze k poslednimu bodu, ktery se me bezprostredne tyka - ano, je to samozrejme pravda, nicmene kolega ma dovolenou, tedy mam celou redakci na starost ja, coz je na jednoho cloveka hodne prace, nez abych jeste stihl detailne studovat kazdy clanek ktery linkuju jako zpravicku. Podotykam, ze pri tom vsem se jeste snazim studovat.
-
ad 3) Ano. Da se to rict o vetsine SW, ktery je nutne nejak zakomponovat do stavajicich firemnich technologiich. To ale jeste neznamena, ze to neni duvod proti.
ad 4-5) Pravdou je, ze pred MySQL5 tomuto SRBD chybelo par podstatnych veci jako triggery a rozumna podpora storovanych procedur. To mohlo rade aplikaci vadit (udrzovat konzistenci nad celou databazi pomoci aplikacni logiky neni moc cista cesta). Takze vyvoj jeste urcite potrebuje a je pravda, ze v 5. verzi se vyvojari docela pochlapili :)
ad 6) To ne. Ale provoz SRBD neni jen vykon. Take ho potrebujete administrovat a certifikaty pomahaji zamestnavateli k lepsimu vyberu a tim padem i levnejsimu 'provozu' administratora.
ad 8) No, zvlaste na profesionalnich housingach, kde se plati predevsim pozice v racku, muze byt mnohem vyhodnejsi poridit viceprocesorove masiny. A jestlize mate napr. webovou sluzbu a databazi na jedne masine, bylo by dobre, aby aplikacni server i databaze mely kazdy svuj procesor a v pripade, ze 'ten druhy' ted nepracuje, vyuzit zbyly vykon. To uz je ukol pro 4-procesorovou masinu.
A licence pro vice procesoru by obecne mohla byt levnejsi, nez vice 1-procesorovych. Ted mluvim jak o OS, tak o SRBD.
Dale je tu jednoduchost administrace. Jestli mam administrovat 4 4-procesorove stroje, nebo 16 1-procesorovych .. vedel bych, co si vybrat. -
> 8 - "vnimanie skalovatelnosti". autorovi sa nepaci, ze MySQL vyzdvihuje svoju horizontalnu skalovatelnost (viac serverov) a nespomina vertikalnu (silnejsie servery). FUD. iba ak by bola uvedena studia, ktora ukazuje, ze MySQL nedokaze vyuzit viacprocesorove stroje, akceptoval by som to ako pripomienku nevyhodnu v niektorych prostrediach (specialne tam, kde je v serverovniach malo miesta a maju bohate IT oddelenie - (viacprocesorove stroje su zvycajne drahsie ako viac menejprocesorovych - pri rovnakom pocte CPU & RAM. plati napr. pre HP, Sun))
MySQL skutecne ma problemy s viceprocesorovymi stroji. Na vine jsou bugy v innodb, a v malloc, ktere se v MySQL pouziva, Ty studie jiz byly provedeny:
http://tweakers.net/reviews/657
http://tweakers.net/reviews/657/6
http://ozlabs.org/~anton/linux/sysbench/
Na druhou stranu koho to zajima. Dobre napsane aplikaci s vyladenymi sql dotazy staci jednoprocesorova p4. MySQL ma dnes podstatne lepe vyresene replikace plus jakys takys clustering. PostgreSQL je zas lip vyladena pro velke servery se specialnim hw.
Me osobne vic vadi ryze komercni chovani MySQL k navrhum komunity. V podstate, pokud chcete nejake rozsireni v MySQL, tak si jej musite a) napsat sami, b) musite zaplatit MySQL za integraci. Pred rokem a pul jsem s kamaradem posilal patch opravujici nekorektni lokales pro kodovani 1250 (tedy zadny pozadavek na dalsi vlastnost, ale opravu chyby). Do dneska to v core neni. PostgreSQL je podstatne otevrenejsi, v okamziku, kdy jim poslete patch, tak pokud je akceptovany, tak je aplikovan do nekolika dnu. -
prvni nastrel. Reagovali tak, ze to daji do dalsi verze, pak do dalsi, nicmene zatim se tak nestalo. Kodovani win1250 je zjevne netankuje. Kde tam jsou ceske komentare? Mozna tam neni link na posledni verzi. http://lists.mysql.com/internals/33393
-
McBig (neregistrovaný)*** mysql-5.0.17/strings/ctype-czech.c
--- 165,172 ----
Na konci připojíme znak 0
*/
+ /* treti kolo je case sensitive */
Ale v tom poslednim uz neni :( :D Je to skoda, i kdyz uprime receno, utf je utf, a je to preci jen maly donucovaci prostredek k tomu, aby na nej uzivatele presli ;) -
uzivatel (neregistrovaný)Akoze nechcem prudit, ale WIN-1250 ? Chapem, ze je to naozaj pekne opravit urcitu chybu v DB systemu, ale priznajme si. Kolko webovych sluzieb ma v backende kodovanie win-1250. Ja ked som zacinal s DB a to som nemal ani trochu potuchy ako to pracuje (klasika v. 3.23) tak mi bolo jasne, ze lepsie je uz pouzivat normovane kodovania v tej dobe ISO-8859-X. Predsa drviva vacsina vtedy aj teraz fici na Linuxe
-
Cim dal tim min webu pouziva 1250, nicmene v zacatcich drtiva vetsina mysql databazi bezela v 1250. Na bug se prislo pri testovani prechodu na 5.0. Zastarale kodovani neni duvod pro toleranci bugu. Budto maji stahnout podporu tohoto kodovani nebo jej maji podporovat korektne. Proto jsme se to take zkouseli opravit a systemove resit zaslanim patche do MySQL. Tam na nas ovsem zvysoka ... takze nezbylo prejit na latin2. O samotne kodovani nejde, tam vetsinou nejsou problemy. Chyby se objevuji v navaznych aplikacich, ktere se po deseti letech pocitaji na desitky. Vzhledem k dynamickemu rekodovani neni tak dulezite ani vnitrni kodovani, za predpokladu ze MySQL je nainstalovano korektne. Viz stale stejne problemy, kdy MySQL je nainstalovano pro latin1 nicmene data uvnitr jsou v latin2 nebo v 1250. Bohuzel takovych mrch je neskutecne.
-
uzivatel (neregistrovaný)No s prechodom na verziu 5 tato chyba uz naozaj nema opodstatnenie. Pokial si spravne myslim tak verzia 5.0 vsetky data uchovava v Unicode a Collate je len prevodova funkcia, ktora prelozi Unicode na zvoleny jazyk a opacne.
Naozaj nevidim ziaden problem pouzivat UTF-8. Niektori budu urcite namietat tym, ze oproti lokalnym kodovaniam ma dvojnasobnu velkost, no nie je to tak pravda. 8bitove znaky pouziva pre definovanu ASCII tabulku a tie ktore sa v nej nenachadzaju tym padom maju 16 bitov.
Na to, ze je na vacsine serverov definovany collate pre latin1 je chyba adminov. Prave latin1 je ako prvy v zozname tychto collateracii a lenivym administratorom sa to nejako nechce prehadzovat na nieco normalnejsie.
