Vlákno názorů k článku MySQL vs PostgreSQL vs Firebird II od Jakub Hegenbart - Možná je to pitomý dotaz, ale co je...
-
Možná je to pitomý dotaz, ale co je v těch tabulkách za výsledek? Průměrný čas na dotaz nebo počet dotazů za jednotku času (sekundu nebo minutu nebo já nevím co)? Nějak jsem to nepochopil.
Píšete, že PostgreSQL drží indexy v cache, ale to snad dělají všechny DB, ne? Tedy pokud mají dost paměti. Jaká byla vlastně konfigurace jednotlivých serverů?
Snad to nejsou příliš rýpavé dotazy. :-) -
anonymníKonfigurace, tak jak jsem nainstaloval. U mysql optimalizace stred. Cisla jsou nejmensi cas provadeni dotazu. Vsechny db sice pouzivaji cache, ale tak nejak videt je to jen u PostgreSQL, tj dost vyrazny rozdil mezi prvnim a druhym dotazem. O tom rozptylu hodnot jsem psal. I tak jednoduche priklady hazi dost ruzne hodnoty, takze nejde rici, co je rychlejsi, jen ze vsechny jsou dost rychle. Dusledne testovani se neobejde bez analyzovani provadecich planu - cisla jsou jen ciste orientacni.
-
Michal Kára (neregistrovaný)Pockejte... Chcete rict, ze ty vysledky Postgresu jsou pro dotazy vracene z cache??? Pak jste ziskal podobne jako autor predchoziho clanku uplne nesmyslna cisla, akorat s vetsi pracnosti :-)
A dalsi dotaz: Jak jste se vyporada(va)l s diskovou cache? Pokud nijak, tak jsou zcela mimo i ostatni vysledky. -
anonymníPostgreSQL ma dost komplikovany system cache, kesuji se jak indexy, tak datove stranky - ale predpokladam, ze tomu je tak i u ostatnich databazi. Monitorovat je muzete napr. http://pgfoundry.org/projects/pgbuffercache/
Stejne tak jako jsem nevypinal cache u PostgreSQL, jsem ji nevypnul ani u PostgreSQL. Podminky meli vsechny databaze stejne. Dotazy jsem spoustel opakovane, i po restartu databaze. Bral jsem ten nejmensi cas, kdy se da predpokladat, ze cache jsou naplnene a pouziji se. Stojim si, ale za zaverem, ze na MySQL Firebirdu a Oraclu neni znatelny rozdil cca 10% mezi prvnim a dalsimi dotazy, tj. vliv cache je pod 10%. U Pg je to 100%. Precte te si o co mi slo. Zjistit, jake casy dosahuji databaze na mirne komplikovane uloze pri std. podminek a posoudit, zda mezi nimi neni podstatny rozdil. Coz je asi jedine overit. Vykonost databazi nezalezi jen na cache, ale i shared mem, atd. Cisla jsou orientacni.
Absolutni cisla nezatizena okolim ziskate jen analyzou provadecich planu, tj. kolik se nacetlo datovych stranek, jaka je cena, ... -
Michal Kára (neregistrovaný)"Bral jsem ten nejmensi cas, kdy se da predpokladat, ze cache jsou naplnene a pouziji se." - to ovsem predpoklada, ze se databaze vejde do pameti RAM a ze se bude na vsechny ty data pristupovat dost casto, aby se udrzely ve file cache. Coz si zdaleka nejsem jisty, zda je v praxi splneno.
Stejne tak se asi tezko bude dotaz na jednu fakturu v praxi provadet nekolikrat za sebou; naopak signifikantni bude doba provadeni prvniho dotazu, bez vlivu cache.
Doporucuji, precte si muj prispevek k prvnimu dilu tohoto "testovani", tam je popsano, jak dostat vysledky ktere se alespon vzdalene blizi realite. -
Pavel Stehule (neregistrovaný)Prectete si, co pisu (nic ve zlem). Uz to co jsem zkousel, je "mimo realitu". Kdy mate napr. provozni db. server bez zatizeni. Na jednu fakturu se opakovane dotazovat nebudete, ale pokud pouzijete connection pooling tak je celkem dost pravdepodobne, ze dalsi uzivatel ano - ne na tu samou, ale to uz je jedno, protoze zaklad jsou indexy. Zalezi na aplikacich, a na tom jak zachazite s connectem. Naopak si myslim, ze v praxi se cache, vyuziva hodne - ale to je jen muj soukromy nazor, potvrzeny slodovanim logu jednoho firemniho db backendu - crm, "pomale" dotazy se vyskytovaly jen tesne po startu.
Vase doporuceni jsou relevantni, ale je to zas jiny test.
