Vlákno názorů k článku
Používat či nepoužívat MySQL?
od Radek Hulán - MySQL je primitivní filesystém, ne DB. Zkuste si...
-
Radek Hulán (neregistrovaný)MySQL je primitivní filesystém, ne DB. Zkuste si třeba zjistit, jaká práva potřebuje "CREATE TRIGGER".. Podobně mizernou funkčnost neměl Oracle ani v roce 1990, a v roce 2007 je zcela jinde.
MySQL je výborný případ open-source odpadku, který se používá jen na miniaturní projekty, na cokoliv jiného je potřeba closed-source komerční kvalita. -
T (neregistrovaný)http://www.systemonline.cz/site/data-warehousing/insight.htm
No já si taky adresně přisadím, pro změnu na RH: některý filesystémy jsou Case-Sensitive! -
Zero (neregistrovaný)MySQL je primitivní filesystém, ne DB.
Ehm to je asi preto ze sa na to pozerate cez oci primitiva...
Zkuste si třeba zjistit, jaká práva potřebuje "CREATE TRIGGER"
A kde vyuzivate ten CREATE TRIGGER???
MySQL je výborný případ open-source odpadku, který se používá jen na miniaturní projekty, na cokoliv jiného je potřeba closed-source komerční kvalita.
Ale toto fakt??? Tak preco sa vyuziva na Free webhostingoch??? -
Radek Hulán (neregistrovaný)"A kde vyuzivate ten CREATE TRIGGER???"
Každý, kdo zná trošku více než základy SQL. Pubescenti znají jen INSERT/SELECT/DELTE a myslí si, že toto je databáze. Velký omyl. Uložené procedory, triggery, a celá aplikační logika v DB volaná z libovolného klienta je skutečná databáze, a k tomuto se MySQL ani zdaleka nepřibližuje.
Nejvíce dementů řve tehdy, když nemají znalosti. Zkus si něco nastudovat po PL/SQL.. Osobně pracuji s Oracle od roku 1992, a výsměch zvaný MySQL se za nic lepšího než "filesystém" nedá považovat. -
Pravděpodobně proto, že od MySQL nechtějí vůbec nic jiného než uložit balík naměřených dat. A to pokud možno rychleji než se jim zahltí paměťové cache. A na to je MyISAM ideální. Pokud ovšem nepracujete s vědeckými daty (většinou se jedná o časové řady, kde můžete tak maximálně sledovat korelaci), potřebujete jištěnou doménovou a referenční integritu. Například abyste si nesmazal číselník zboží, které máte ještě na skladě. Pokud implementujete doménovou a referenční integritu v aplikaci, tak máte jistotu, že uživatel nic nezvoře, nicméně, kdo vám totéž zaručí za aplikaci? Vzhledem k tomu, že obé integrity jsou podporované v SQL, tak jejich definování i vynucení je elementární, bezpracné a účinné pro uživatele. Interně to není nic jednoduchého, a pro MyISAM tabulky s hrubým zamykáním to nelze provést nijak efektivně (diskuze v dbsvete http://www.dbsvet.cz/comment.php?akce=view&cisloclanku=2007050201 ).
MySQL se držela Microsoftí rétoriky, co neumíme je k ničemu a nikdo to nepotřebuje. Naštěstí teď obrátili, vzhledem k tomu, že už jakž takž výšší db operace zvládnou. Jak InnoDB, tak nový Falcon referenční integritu podporuje. -
Tom (neregistrovaný)Na uvod, robim s Oraclom aj MySQL. Nie od vcera. Naozaj dlho. V zavislosti od projektu a ulohy.
Avsak, drobnu poznamku si neodpustim.
Pravdepodobne si naozaj velky k***t, lebo iba k***t napcha aplikacnu logiku do DB. Toto sa riesi tretou vrstvou, aplikacnym servrom. Databaza ma za ulohu udrzat integritu dat (do urcitej miery). Nic viac nic menej.
Vsetko ostatne je na aplikacnom servri. Klienti dnes samozrejme co mozno najtensi.
Pochopis, ked zacnej pracovat na projektoch kde objem dat dosahuje radovo stovky az tisice GB. Udrzat takto velky cluster v behu, zabezpecit skalovatelnost a zamedzit single point of failure nie je naozaj jednoduche. Najma bez app servru.
Takze zdar primitivnym k*****m! :) -
McBig (neregistrovaný)Delam to velice nerad, ale zde se musim zastat naseho mileho genia, byt je vedle jak ta jedle a ja osobne bych mu nesveril ani instalaci icq.
Pro genia (RH): Myslq dnes opravdu umi ukladat aplikacni logiku primo do DB, laskave si zkuste obcas aktualizovat verzi, nebo alespon znalosti, oni to rozumni admini jednou za cas opravdu delaji.
Nicmene, nadavat nekomu do k****tů, protoze chce od db nejaky ten trigger nebo funkci je jednak nesportovni a neslusne a hlavne kratkozrake. Ono totiz cas od casu pride situace, kdyz je potreba do db neco takoveho ulozit, aby si clovek ulehcil praci s aplikacni vrstvou. Ze ste se s tim nikdy nesetkal za vas profika nedela ! A u "malych" aplikaci ktere jsou nad MySQL stavene vytvaret neco jako aplikacni server a k nemu klienta - to je velmi neefektivni. A to nemluvim o tom, ze do jedne DB pristupuje nekolik ruznych systemu, ktere s nim pracuji primo (treba autentikacni mechanismy ruznych serverovych sluzeb).
Proto prosim, nenechavejte se zbytecne vyprokovat ceskym vtipem jmenem Radek Hulan, jen se proste usmejte nad jeho nazory, dyt je to fakt zabava :) -
a) Zbytecne urazis lidi.
b) Mozna pro projekty o kterych mluvis je pouziti aplikacnich serveru nezbytne. Nicmene takovych je minimum. Ulozene procedury, tj. aplikacni logika v db ma minimalni rezii, uzke hrdlo je v SQL prikazech, takze neni zadny zvlastni duvod proc se branit ulozenym proceduram (za predpokladu, ze jim rozumis). Misto osocovani ukaz argumenty.
Spolupracoval jsem na projektu Garuda, kdy je 98% aplikacni logiky v databazi, aplikacni vrstva je fakticky jen prostrednik mezi databazi a AJAX klientem. Zatim se tenhle "sileny" navrh osvecuje. Samozrejme, ze architektura Garudy ma svoje specifika a neni vhodna pro urcite typy projektu, pro beznou vnitropodnikovou agendu naprosto postacuje.
Rozdil mezi aplikacnimi servery a ulozenymi procedurami se tak jako tak stira a bude stirat. Jazyky typu PL/SQL, PL/pgSQL nebo SQL/PSM maji minimalni rezii a umoznuji efektivni zapis kodu. Tam kde nestaci (vykonove nebo obsahove) neni problem pouzit .NET, Javu a dalsi. Naopak si dovolim tvrdit, ze pro celou radu projektu jsou aplikacni servery nevhodne nebo minimalne nekvalifikovane a chybne pouzite. Coz ve vysledku vede k silenym hw. pozadavkum. -
Tom (neregistrovaný)Na uvod, robim s Oraclom aj MySQL. Nie od vcera. Naozaj dlho. V zavislosti od projektu a ulohy.
Avsak, drobnu poznamku si neodpustim.
Pravdepodobne si naozaj velky k***t, lebo iba k***t napcha aplikacnu logiku do DB. Toto sa riesi tretou vrstvou, aplikacnym servrom. Databaza ma za ulohu udrzat integritu dat (do urcitej miery). Nic viac nic menej.
Vsetko ostatne je na aplikacnom servri. Klienti dnes samozrejme co mozno najtensi.
Pochopis, ked zacnej pracovat na projektoch kde objem dat dosahuje radovo stovky az tisice GB. Udrzat takto velky cluster v behu, zabezpecit skalovatelnost a zamedzit single point of failure nie je naozaj jednoduche. Najma bez app servru.
Takze zdar primitivnym k*****m! :) -
uzivatel (neregistrovaný)Tak toto napis IBM, ktora v 70tych rokoch definoval pojem DATABAZA a vysmeje ta. Vtedy to bol prave skutocne INSERT/SELECT/UPDATE/DELETE. Vsetko co sa da spravit cez Triggery sa da v aplikacnej logike spravit taktiez.
Takze ten pubescentn ako nazyvas si akurat len ty a este k tomu hlupak, ktory vie len do kazdeho nadavat aky je nevzdelany. Mozno ze mas inteligenciu, ale to co robi cloveka normalnym je ROZUM a ten ty zjavne nemas.
Proceduralny jazyk ma MySQL taktiez. Zobud sa, nehovorime o MySQL 3. Doba pokrocila. Ak pracujes s Oracle tak by si mal asi vediet, ze to nebola databaza primarne urcena na webove projekty, kde MySQL na toto presne stavane bolo, tak isto ako PHP. Obaja boli vo svojich zaciatkoch priekopnicky, potom zaspali a teraz to dohanaju.
Ak sa ti nepaci tak to nepouzivaj. Ale ty stale budes nadavat vsak ? Vidiet, ze idiot sa nezaprie. -
Zero (neregistrovaný)Pre Vasu informaciu 15 mi bolo uz davno a o SQL viem dost na to aby som Vam mohol oponovat.
Aplikacna logika v DB??? Hmm ja som si myslel ze to sa riesi cez aplikacny server nie v DB. Su sice situacie kedy to treba, ale je ich malo. Ktoru verziu MySQL mate na mysli??? od verzie 1.x sa toho vela zmenilo. Verzie 1.x fakt bola iba FS, ale skuste si nainstalovat novu 4.x, resp. 5.x... -
anonymnízalezi vykon ceho :)
na rychle ne az tak komplikovane casto opakovane dotazy, kde neni potreba nejak pokrocile kontrolovat integritu to je idealni
ale podnikovou aplikaci nebo dokonce DWH bych na to fakt nepostavil
je to proste trochu jina trida, ktera se hodi na neco jineho
a mimochodem ten lepsi vykon mysql podavalo s InnoDB nebo MyISAM? :) -
A PostgreSQL, tez OSS se Vam take nelibi? Ja s ni jsem naprosto spokojen a abych rekl pravdu ani MySQL mi nikterak nevadi, je to dobra databaze, byt ma sve vady. SQLite je take OSS, na nektere mensi vecicky perfektni nastroj. A co Firebird? Vsechno je to OSS ... nerikam, ze MS-SQL je spatna, neznam ji, nemohu soudit, ale rozhodne bych OSS databaze neodsuzoval, ba prave naopak. Tedy alespon pokud mate zajem bavit se ve vecne rovine a ne bulet jak male decko, ze se Vam nelibi pepickova babovicka, protoze ji ma hezci. -
hlavac (neregistrovaný)Před pár lety když jsem se o to zajímal mi na PostgreSQL vadil především jeho "optimistický" izolační model, to že klient v rámci transakce neviděl změny které provedl, a pak provázanost se systémovým locale. Nevim možná je to už jinak?
Jinak rychlost není v databázích všechno.
Velmi šikovné jsou transakce a s tím spojené vychytávky:
- konzistence a odolnost při havárii (při havárii se rozdělané transakce zahodí, dokončené zůstanou, data zůstanou konzistentní)
- záruka že se data neztratí poté co klientovi bylo potvrzeno jejich uložení (např. vinou pádu když jsou data ještě v diskové cache)
- izolace ve víceuživatelském provozu - podle mne nejvíce nedoceněná vlastnost - že se např. v serializable izolačním módu nemusíte vůbec starat kdo co s databází zrovna dělá a jestli vám to nakopne vaše data - databáze dělá zamykání sama a nejhorší co můžete spáchat je deadlock a opakování transakce... tohle ale neumí pořádně (= výkonně) ani většina komerčních databází a vymýšlí si všelijaké omluvy proč to vlastně ani nechceš ;)
Moc to usnadněuje složité aplikace s více uživateli kde není předem známo kdo se v tom bude jak vrtat (např. manažer přímo přes SQL klienta)
Mysql je rychlá pokud vím jen s myisam enginem a ten stojí za houby ze všech ostatních hledisek (na která je dobrý innodb ale zase není rychlý, no).
Nemám rád mysql protože je populární jen kvůli stádové mentalitě lidí co databázím nerozumí vůbec :) -
McBig (neregistrovaný)Kdyz si date tu praci (omlouvam se ale hledat to ted vazne nebudu) najdou se na netu ruzny benchmarky, podle kterych opravdu innodb je rychlejsi nez myisam, mam pocit ze jde predevsim o indexy. Takze opet tu je prostor pro ladeni zda index ano ci ne a jaky prip. kolik. Stejne jako je tento prostor u Oraclu, kdy se proste vyplati nektere indexy nepouzivat :)
-
Innodb automaticky clusteruje a pouziva urcite neciste techniky, a tak muze byt opravdu rychlejsi nez MyISAM. MyISAM ma mnohem jednodussi strukturu a podstatne mensi rezii pro operace UPDATE, DELETE, INSERT, takze pokud se v benchmarku pouzivaji tyto operace, tak na tom bude MyISAM lepe. Na druhou stranu, MyISAM zamyka na urovni tabulek, oproti InnoDB, ktere nezamyka nebo dovoluje zamky na urovni radku. Takze v benchmarkach, ktere sleduji chovani databaze pri viceuzivatelskem pristupu (zalezi jakem), tak u MyISAM vykon strme klesa s rostoucim poctem uzivatelu (vlivem zamykani).
-
Koukám PostgreSQL je i ve verzi 8.2 pořád stejný shit jako kdysi.
Jejich "serializable" izolační level vůbec nesplňuje kritéria serializovatelnosti.
Problém je v tom, že používají snapshot dat tak jak byla na začátku transakce pro všechna čtení v rámci transakce. To může fungovat jen u read only transakcí, při update to způsobí rozpad konzistence ve víceuživatelském režimu. Ten jejich podělaný "optimistický" model :) Ach jo. -
Full serializable by znamenal zamek v kazdem radku, ktery prectete, coz ve vetsine pripadu neni potreba. Pokud by mohlo dojit k problemum s konzistenci, pak je treba pouzit SELECT FOR UPDATE, ktery pozamyka prectene radky, cimz se blizite skutecne serializaci.
Dobra prezentace na toto tema (vcetne vysvetleni proc a jak neni serialisable transakce plne serialisable) najdete http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/concurrency.pdf
Chce si to precist dokumentaci -
> Full serializable by znamenal zamek v kazdem radku, ktery prectete
Ne nutně. Nezaměňujte jedno možné řešení problému s jeho definicí. Aby byly transakce serializovatelné stačí aby se zdálo že proběhly v nějakém pořadí jedna po druhé, tedy aby nepoznaly vliv ostatních transakcí. O zámcích tam nic není ;) Nehledě na to že potřebujete zámky na predikáty, ne na jednotlivé řádky (protože v případě instertu třeba ještě neexistují).
Stačí například zavést read only transakce (s multiversion) a update transakce vykonávat sériově a máte taky plně serializable izolaci s vysokým výkonem pro aplikace s převahou čtení (např. web). Žádné zámky, žádný overhead.
> Chce si to precist dokumentaci
Optimistický multiversion model izolace PostgreSQL jsem studoval _velmi pečlivě_. Právě proto remcám ;)
Hlavní nedostatek vidím v použití snapshotu stavu dat ze začátku transakce pro všechna čtení, což v kombinaci s "optimistickým" přístupem vede v určitých situacích ke katastrofickým selháním (= transakce nebude schopna úspěšně dokončit práci NIKDY protože bude neustále rušena jinými, menšími a rychlejšími transakcemi měnícími stejná data).
Zbytečně se tu navíc ztrácí příležitost pro ostatní transakce změnit (a commitnout) změny dřív než budou data poprvé přečtena aktuální transakcí.
Snapshoty fungují dobře jen pro read only transakce které nemohou měnit data a mohou tedy předstírat že proběhly v nulovém čase.
Jasně že se to dá obejít explicitním zamykáním, ale o tom právě serializable model je - nemuset to dělat ručně ;) -
je to kompromis mezi hromadou kodu navic a funkcionalitou. Navic je otazka, zda-li MGA pravy serialisable rezim dokaze efektivne zajistit.
Ann Harrson "I've been out of the database design business since 1992.
Maybe Dr. Gray has understood the InterBase MGA concurrency control better since then. At the time, he didn't. I spent a great many hours between
1980 and 1992 (and a considerable amount since) trying to find the
trick to make MGA serializable - as have others, much more inspired
than I. My current belief is that the problem has no solution.
However, our goal was not academic purity, or even earning an A on
Date's quiz. It was to create a highly concurrent database that
provided acceptable consistency and predictable anomalies. Any
anomalies had to be avoidable through consistent programming practice
without significant performance cost. I think we succeeded."
This isolation level specifies that all transactions occur in a completely isolated fashion; i.e., as if all transactions in the system had executed serially, one after the other. The DBMS may execute two or more transactions at the same time only if the illusion of serial execution can be maintained. At this isolation level, phantom reads cannot occur.
With a lock-based concurrency control DBMS implementation, serializability requires that range locks are acquired when a query uses a ranged WHERE clause. When using non-lock concurrency control, no lock is acquired; however, if the system detects a concurrent transaction in progress which would violate the serializability illusion, it must force that transaction to rollback, and the application will have to restart the transaction.
Takze je hezke, ze serializace je definovana teoreticky, s praxi je to asi horsi.Mohu se zeptat, ktera databaze ma korektne implementovane serialisable transakce? -
Ony to umí skoro všechny. Oracle, MS SQL, Sybase... snad i mysql s innodb to umí.
Problém s tím mají jen databáze co používají různé formy snapshotů / optimistických schémat.
Jediný problém se serializable je ten že to stojí databázi práci. Jenže přenášet to na uživatele manuálním zamykáním je ještě horší ;) -
To by mne celkem zajimalo. Je k tomu nejaka dokumentace? Znam jenom PostgreSQL a Firebird. Co jsem si myslel, tak serializable transakce jsou hlavne definovane neexistenci Phantom Read. Jinak co vim, tak oracle (alespon 9 mela totez chovani jako PostgreSQL), tj transakce nemusi byt serializovatelna a pokud chci zabranit problemum, musim pouzit SELECT FOR UPDATE. Nicmene to uz je take nejaky rok zpatky. Na jedinou zminku ohledne pesimisticke strategie jsem narazil u Solidu http://www.mysqlperformanceblog.com/2006/09/22/test-drive-of-solid/
-
Firebird byl náhodou docela dobrej, jen měl tendenci postupně zpomalovat a zpomalovat při intenzivních updatech...
V ANSI X3.135-1992(R1998) co tu mám je na str. 54 napsáno:
The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.
The isolation level specifies the kind of phenomena that can occur during the execution of concurrent SQL-transactions. The following phenomena are possible:
Načež následuje popis Dirty read, Non repeatable read a Phantom read. Takže serializovatelnost není definovaná výskytem těchto jevů.
Taková definice serializable umožňuje dokonce víc než klasické dvoufázové zamykání - třeba využít efektu komutativních operací pro zvýšení paralelizmu transakcí.
Typický příklad by byl vyskladňování zboží - když bude jeden dost chytrý aby odečtení ze skladu napsal jako
UPDATE sklad SET pocet = pocet - ?mnozstvi WHERE id=?zbozi AND pocet>=?mnozstvia úspěch zjišťoval jen podle update countu příkazu aniž by se zajímal kolik ze přesně zboží na skladě je, vyhne se jevu hotspotu (transakcím hádajícím se o často měněná data)!Něco takového je v databázích stále ještě bohužel scifi :)
-
He he, a open vs. closed source je známka kvality? Co třeba projekt Firebird? S InterBase jsem se setkal poprvé s verzí 4 (cca 10 let, už tehdy měla uložené procedury a triggery, v té době se např. MS SQL o triggrech ani nesnilo), pak 5.5 a těsně před vydáním verze 6 byla uvolněna jako open source a vznikly dvě větve - Borland dále pokračova s InterBase a druhá větev je open source projekt Firebird. A nezdá se mi, že by tím utrpěl na kvalitě a zatím ani cca 40000 důchodcům, které vyplácíme, se nezdá, že by kvůli Firebirdu nebrali peníze.
-
Zbytečně nasíráš lidi. O Innodb se nedá říct, že to je primitivní filesystém, zrovna tak o Falconu. Triggery a uložené procedury nemají dotažené. Od svého vzniku popírali nutnost logiky na straně databáze, a teď nemají uživatele, kteří by je dokopali, k tomu, aby to dotáhli. Priority MySQL jsou někde úplně jinde. Taky uživatele MySQL jsou jiní než uživatele PostgreSQL. Bohužel rétorika MySQL vedla k tomu, že dost velká část programátorů nemá tušení o datovém návrhu, datové integritě, o možnostech, které mají databáze. Ale to je jiný problém.
MySQL se používá i pro velké projekty - ceny, které google zaplatil za svoje poslední akvizice odpovídají velkým průmyslovým kolosům. Narazil jsem na termín web centrické aplikace.
