Pani googlujte PBXT, a potom si polozte otazku, ci MySQL ako DB Server ma vyznam pre vyvoj DB. Ano oddelenie storage engines je potrebne pre jednoduchy navrh a vyvoj DB ako celku. Pokial by sme nemali MySQL, ktora to umoznuje alebo obdobnu DB, tak by vyvoj v DB svete nebol taky rychly.
Treba sa pozriet na to, ako MySQL prispieva, nie ci je idealna pre vsetky aplikacie. Google tiez vyuziva MySQL resp. ich orezany variant, ze by naozaj nevedli preco?
Preco oddeleny storage je POTREBNY pre jendoduchy navrh DB ak je vsetok zdrojovy kod open (pochopil by som ak by server bol proprietarny a umoznoval storage plugin)?
Cim prosim vas prispela MySQL k vyvoju DB? Prisla s niecim zaujimavym, novym?
MySQL je fajn baza a nech si ju pouziva kazdy na co chce, ale naco je tato peticia?
No moment – jedna věc je logické „oddělení“ storage engine s cílem zjednodušit vývoj (což je v PostgreSQL), druhá věc je vytvoření veřejného API přes které se dají doplňovat další a další storage engines (což je v MySQL).
Ale skutečně mi není jasné jak tímto oddělením přispívá MySQL k rychlosti vývoje DB technologií … Netvrdím že masová dostupnost MySQL nepřispívá k rozvoji DB, ale se kterými pojmy nebo technologiemi MySQL přišla? Kromě „automagic“ funkcionality, pochopitelně.
Uvedomte si preco, storage engines su vyvijane pre MySQL, je to prave tym striktnym api. Je komplikovane nieco taketo vyvijat pre Postgres. Pozrite si prave to PBXT, myslite ze to je design, ktory sa nemoze zasadne hodit? No ja viem o niektorych oblastiach, kde sa to z hladiska postupov vyuziva. Ide zvycajne o bezpecnost, ktora v minulosti a v podstate este niekde aj v pritomnosti vyuziva magnetoopticke disky preto, aby sa nedali udaje mazat. Vyuzivali sa rozne neDB systemy, lebo riesenie nebolo. A vyzera to tak, ze coskoro taketo riesenie bude a v tejto oblasti bude nasadzovane, lebo nema konkurencie. Podla prvotnych vysledkov je performance viac nez prijatelna.
Trochu se točíme v kruhu. Jsem názoru že tvrzení „výhodou MySQL je podpora několika storage enginů a API pro jednoduché doplnění dalšího“ je nesmysl, protože důsledkem toho je že enginů je sice několik, ale v podstatě žádný není dotažený.
Mně osobně se více zamlouvá filozofie PostgreSQL, podle které je lepší mít jeden storage engine, ale zase lépe vymyšlený a vyladěný. Což ale nemusí nutně znamenat že ten storage engine je nenávratně zadrátován a nelze ho s přiměřenou snahou nahradit – cituji z Wikipedie (http://en.wikipedia.org/wiki/PostgreSQL):
„Yahoo! for web user behavioral analysis, storing 2 petabytes and claimed to be the largest data warehouse using a heavily modified version of PostgreSQL with an entirely different column-based storage engine and different query processing layer. While for performance, storage, and query purposes the database bears little resemblance to PostgreSQL, the front-end maintains compatibility so that Yahoo can use many off-the-shelf tools already written to interact with PostgreSQL“
Jinými slovy Yahoo vzalo PostgreSQL, totálně překopalo storage a query processing, a ukládá do toho 2 PB dat o uživatelích.
Lenze taketo prekopanie si nemozu dopriat mensie firmy, ktore dodavaju ucelene riesenia. Je to neskutocne jednoduchsie napasovat storage engine cez MySQL API ako prekopavat PostgreSQL. Skus si to pozriet v zdrojakoch. Neexistuje idealny storage engine, pre vsetky podmienky riesenia. Moznost zapisu jedineho zaznamu je velmi zvlastna poziadavka, ale je to legitimna poziadavka pri istych situaciach. Taktiez performance pri roznych poziadavkach na DB je rozna v storage engine-och. Tu su moznosti MySQL velkym pozitivom.
Som si vedomy a Yahoo tiez, ze pri istych typoch queries je PostgreSQL na tom omnoho lepsie. Rovnako vsak isty typ queries MySQL zvlada velmi dobre.
Nekonecne hadky PostgreSQL vs. MySQL su uplne bezpredmetne. Ich schopnosti su dane prioritami vyvoja oboch DB rieseni. Obe si musia vediet najst svoje miesto. Kazdy sa zameriava na nieco ine. Zatial plati, ze obe si toto miesto nachadzaju. Ked to tak nebude, jedna DB tu nebude.
Nie je to nic nezvycajne v DB svete.
Ja tvrdim, ze MySQL do istych prostredi je spravnym rozhodnutim. Rovnako do istych prostredi je PostgreSQL. Viem o prostrediach kde by som nic okrem Oracle nenasadzoval. A mnoho prostredi je vysostne Microsoft friendly…
Je vsak jedno prostredie kde DB doteraz nemohlo byt nasadzovane a MySQL toto pole obsadzuje. Rovnako mnohe spolocnosti si robia performance study a vyuzivaju rozne DB v roznych prostrediach.
„Lenze taketo prekopanie si nemozu dopriat mensie firmy, ktore dodavaju ucelene riesenia.“ – nechapu. Pokud jsem firma, co dodava ucelene reseni pro zakaznika, pak mam bud dost penez na vyvoj libovolne specialni technologie nebo neschopne vedeni. Jestlize by se objevil duvod pro implementaci ultra-special-vyjimecneho storage enginu, pak necht zakaznik plati – i programator ma doma par hladovych krku.
MySQL exceluje v dotazech typu „select * from customers“, nicmene takove dotazy jsou pouzivane jen bastlici v jednoduchych aplikacich typu obchod se zradlem pro psy. PostgreSQL je naopak do urcite miry kompatibilni s Oracle (PL/SQL), coz je vyhoda jak hrom. Nicmene na obranu MySQL musim dodat, ze se mi pred lety, kdyz jsem jel na WinXP, PostgreSQL nepodarilo nainstalovat s FAT32, instalator mi proste rekl, ze ten FS neni dost dobry (WTF?).
Souhlasim, ze nejdulezitejsi je moznost vyberu. Tahle diskuse se ale oklonila od zpravicky – jestli chce komunita pokracovat ve vyvoji MySQL, tak prosim, ja jim budu drzet palce. Ale ten humbuk s fuzi Oracle/SUN mi pripada dost hystericky.
Řada vývojářů v MySQL nepovažuje storage engines právě za šťastný nápad – pokud sledujete vývoj a blogy v „Planet MySQL“. Díky tomu dodnes není pro MySQL k dispozici jediný bezproblémový univerzální storage. InnoDB je kvalitní, ale nepodporováno fulltextem, MyIsam neposkytuje konzistenci – Falcon a MariaDB jsou v dlouhodobém beta stadiu.
JJ, Mel jsem moznost mluvit s jednim zamestnancem MySQL a on rikal ze implementovat referencni integritu mezi ruznymi storage engines je peklo a ze to nikdy nemuze poradne fungovat. Pred dvema lety „neoficialne“ prozradil, ze pracuji na novem skvelem hyper-super enginu ktery vsechny ostatni nahradi – jak to dopadlo netusim.