18 komentářů k článku Zvyšujeme výkon MySQL změnou konfigurace:

  1. kuba

    Re: Zvyšujeme výkon MySQL změnou konfigurace

    „naváže další díl, který pojedná o horizontálním škálování, a poslední díl pak o replikaci a možnostech jejího využití při vertikálním škálování“
    Buď si autor plete vertikalni vs horizontální škálování, nebo to bude hodně zajímavé :)

    1. Blaxi

      Re: Zvyšujeme výkon MySQL změnou konfigurace

      Samozřejmě jedná se o záměnu těchto výrazů, má býti:
      „V příštích dílech se podíváme na možnosti vertikálního škálování a také na replikaci a možnosti jejího využití při horizontálním škálování výkonu.“
      Má omluva.

      1. konzultant v oboru ICT

        Re: Zvyšujeme výkon MySQL změnou konfigurace

        O cem muze byt clanek o vertialnim skalovani? Proste jen potunime server po fyzicke strance a je to. Clanek na jednu vetu :-)

    2. Martin Malý

      Re: Zvyšujeme výkon MySQL změnou konfigurace

      … anebo se autor přepsal! :) Opraveno, díky za upozornění.

  2. Jakub Vrána

    Připomínky

    Kromě několika překlepů je článek podle mě poměrně zdařilý. Možná bych alespoň nějaký čas věnoval specifikům InnoDB (obzvlášť primárnímu klíči, podle kterého se data organizují a který se přímo zapisuje do listů ostatních indexů, takže jeho volba má zásadní důležitost). No a pak by taky neškodilo lépe vysvětlit, jak funguje query cache (že jakákoliv změna tabulky smaže cache všech dotazů, které tabulku používají, nejen dotčených záznamů).
    Rád bych se nicméně ohradil proti dvěma výrokům:
    1. „tabulky typu MyISAM jsou daleko výkonnější“ – to zásadně záleží na charakteru provozu. V jednouživatelském režimu to obvykle platí, ale ve víceuživatelském (který je zcela typický pro webové aplikace) to může být přesně naopak. Obzvlášť kombinace UPDATE a SELECT (i nesouvisejících záznamů v jedné tabulce) může být pro MyISAM smrtelná.
    2. U query cache „čím větší je počet paralelně přistupujících klientů k dané databázi“ – jakou souvislost s query cache má to, jestli klienti přistupují paralelně nebo sériově? Pokud vím, tak žádnou.

  3. Radim Smička

    Query cache

    Bylo by užitečné trochu více v článku zdůraznit Query cache. Přijde mi, že převládá názor zapnutí query cache = zvýšení výkonu. Čím častější aktualizace a čím unikátnější dotazy tím méně se cache vyplatí. Nemá smysl cachovat select, který se provádí v průměru jednou za minutu, když podkladová tabulka se mění každých 10 vteřin.
    >Efektivitu cache lze měřit pomocí stavových proměnných, které zobrazíme například položením dotazu SHOW STATUS LIKE ‚Qcache%‘.
    Podle mě je to téměř k ničemu, často jsou v aplikaci dotazy na malé pomocné tabulky, které jsou rychlé a tuhle statistiku úplně rozhodí. Je lepší se vždy zamýšlet opravdu nad tím kolikrát se po update, insert nebo delete provede select – tedy 2×, 1000×? Není univerzální odpověď kdy cache a no a kdy ne.
    I pokud se tabulka nemění často může query cache dělat problémy – pokud na tabulku míří velká spousta neopakujících se dotazů. Taková změna tabulky po 1 000 000 unikátních dotazů, může trvat relativně dlouho (kromě změny tabulky se bude měnit i cache).

    1. Blaxi

      Re: Query cache

      Samozřejmě, že článek nemohl obsáhnout všechny možnosti a nastavení, už takto jsem se musel značně omezovat, abych se vešel do rozumného maxima délky článku. Od toho jsou tu dobré ty diskuze, kde je možné některé důležité věci zdůraznit.
      Mno už aby vyšla verze MySQL 5.5, jež slibuje velmi pěkné navýšení výkonu zejmnéma pro tabulky InnoDB a také semisynchronní replikace. Doufám, že se vývojářům povede vydat GA verzi o prázdninách.

  4. mat

    MySQL je pro opravdové zoufalce

    MySQL je opravdový děs, pokud to myslíte z databázemi opravdu vážně, použijte PostgreSQL …

    1. František Kučera

      Re: MySQL je pro opravdové zoufalce

      +/- souhlas, ale na druhou stranu nad MySQL existuje řada fajn aplikací, takže se hodí umět poladit i MySQL databázi – ne všechno můžeš zmigrovat do PostgreSQL (i když ta aplikace o sobě tvrdí, že to jde, tak se nakonec může ukázat, že jí nikdo s jinou databází netestoval a odladěná je jen pro MySQL).

    2. sup

      Re: MySQL je pro opravdové zoufalce

      Vsade citam, ze postgreSQL je lepsia ako MySQL, ale nikde nie su dovody. Nie je niekde clanok s porovnanim tychto dvoch DB?

      1. mat

        Re: MySQL je pro opravdové zoufalce

        v cem je rozdil? reknu to ze sveho pohledu. DB pouzivam temer vyhradne pro analyticke ucely.. tzn mam v nich ulozeny data a vytvarim nad nima reporty, slozite selecty, analyzy … Mysql stale nepodporuje celou radu sql prikazu, ktere jsou v tzv SQL standardu a musi se to slozite obchazet .. Je to takovy voser, ze by jeden skakal z okna. Bohuzel nekteri klienti maji data v tomto systemu :-( Pokud to alespon trochu jde, delam import do rozumejsich systemu jako je postgre, oracle apod …
        MySQL podle me nema zadne opodstatneni. Dnes uz neni ani rychla, ani „light“ … vsechny drivejsi vyhody konkurence dohnala, tak proc pouzivat nedodelek?

        1. logik

          Re: MySQL je pro opravdové zoufalce

          Všechny? Nezpochybňuju, že mysql je děs, ale která free databáze nabízí dobře vyřešenou replikaci?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3247