Názory k článku MySQL vs PostgreSQL vs Firebird II
-
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. -
Já myslím, že o tomto píše přímo manuál MySQL (mimochodem první co čtu, když chci stavět něco nad nějakou databází jsou kapitoly o optimalizaci):
In some versions of GNU/Linux and Unix, flushing files to disk with the Unix fsync() and other similar methods is surprisingly slow. The default method InnoDB uses is the fsync() function. If you are not satisfied with the database write performance, you might try setting innodb_flush_method in my.cnf to O_DSYNC, although O_DSYNC seems to be slower on most systems -
Mikulas Patocka (neregistrovaný)A proc nepouzijou fdatasync()?
fsync() syncne vsecka data i cas modifikace na inode.
Flag O_DSYNC predany syscallu open() zpusobi, ze pred kazdym
navratem z write() se zapisou data na disk, ovsem bez syncu
casu na inode --- coz na jedne strane zrychli tim, ze se casy
nesyncuji, na druhe strane zpomali tim, ze requesty na disk
nejdou paralelne.
fdatasync() je to, co by se melo delat. -
anonymníhmm, fsyncem to nebude, pravdepodobne. Testoval jsem select, kdybych testoval insert, update, tak mozna. Budto tam mam chybu v mereni, ale kazdy si muze test zopakovat a potvrdit, nebo mne poslat nekam, nebo proste innodb si s win rozumi lip. Neni tak uplne pravda, ze mysql bezi jenom na linuxu. Znam dost instalaci na win. A osobne mne zajimal vliv platformy - v klidovem stavu. Neco jineho bych se asi dozvedel pri zatezovych testech, ale to je zase hromada testu.
-
PJ (neregistrovaný)Hmm v bete4 ten patch, ktery jsme mel na mysli jeste neni. Jde o CHECK_FOR_INTERRUPTS patch, ten hodne zrychlil tuto funkci na windows cimz se zrychlilo vsechno co ji pouziva (indexy, vacuum atd) - napr order by se zrychlil v nekterych pripadech az o 40%. Prave vzhledem k hodne velkemu zrychleni byl tento patch aplikovan ikdyz uz v te dobe byla 8.1 pred vydanim prvniho RC.
-
BigSam72 (neregistrovaný)Byt jsou provadeny na totoznem hw. Mam vice nez 10ti lete zkusenosti s Oracle pres 7.3.x az po 10g. Oracle stale pridaval a pridava nove vlastnosti do DB nektere jsou z meho pohledu sporne. Je o opravdu moloch. Autor zde napriklad popisuje a srovnava casy importu do jednotlivych DB ale neuvadi pouzite metody. Nechci nijak autora sikanovat, ba naopak bych mu chtel podekovat za clanek, jiste ho stal spoustu casu a usili.
Ale napriklad jenom co se tyka importu mate u Oracle cca 5 ruznych zpusobu s ruznym efektem a rychlosti.
imp/exp
imp/exp direct path
sqlldr
a u oracle 10g oracle datapump.
takze psat ze tomu to trvalo tolik a tomu tolik je proste zavadejici. -
anonymníNebylo. Diky tomu ze jste mne ted opravil, tak nikdo nebude priste importovat sql pomoci @, a to mi slo. Vsechno muzete dohledat na netu, jenomze ted uz je tam toho tolik, ze najit ty spravny klicovy slova je alchymie. Navic casy importu jsem neuvadel, je mi jasny, ze zrovna import je hodne specificka zalezitost, a navic nikdo, pokud importuje realna data, nebude importovat SQL dump. Abych to upresnil, importoval jsem pomoci operatoru @, a evivalentnimi prikazy u ostatnich databazi. Ale nemel jsem predstim predstavu jak je to pomale (prakticky u vsech databazi).Ted uz bych to nedelal.
Poradte mi - jaky z tech peti prikazu pouzit na sql dump (flat file obsahujici Inserty). -
anonymníto vim, ale jak dostanu data ve formatu copy do Firebirdu? A opakuji o rychlost importu mi neslo. Vice mene upozornuji na zadrhel obdobnych testu. Pokud budete importovat data v SQL formatu, tak se obrnte trpelivosti. Jedine co stoji za zminku je rozdil v rychlosti importu Firebirdu na win a Linuxu.
-
anonymníV textu byla nepatrna poznamka: mysql a firebird pri definovani referencni integrity REFERENCES tab () vytvori index i nad sloupcem obsahujici cizi klic. PostgreSQL tento index 100% nedela, a pokud jsem se nespletl (preci Oracle a MsSQL neznam tak do hloubky, takze nejakeho systemoveho indexu bych si treba nevsiml) tak Oracle s MsSQL take ne. Diky tomu, pokud mate libovolny priklad obsahujici referencni integritu, tak my. a fi. maji jeden index navic a v porovnani dosahuji lepsich vysledku. Pokud tenhle chybejici index pridate do PostgreSQL, tak ma lepsi vysledky PostgreSQL. Takze, aby ta cisla byla alespon trochu porovnatelna pridaval jsem rucne indexy na sloupce obsahujici cizi klice std. prikazem
create index nazev on tab(sloupec_cizi_klic); -
Mmm (neregistrovaný)To je ale spatny predpoklad. Pouziti indexu nemusi vzdy zrychlit dotaz a naopak jej muze i pekne zpomalit, protoze jeho pouziti je nadbytecne. Mam takovou zkusenost prave s FB, kde preferuji udrzovani referencni integrity pomoci triggeru a volitelne indexu prave proto, ze vytvari pro FKs indexy a pouziva je v selectech, kdyz by bylo sekvencni zpracovani rychlejsi. Jak by to dopadlo bez indexu na FK?
A jedna velka vytka za me k clanku - chybi mi velmi plany jednotlivych dbms pro jednotlive selecty. -
Pavel Stehule (neregistrovaný)Dobra, sekvencni cteni bude rychlejsi cca do 100(0) radku. Jelikoz 3 ze 4 tabulek maji nad 10000 radku, tak sekvencni cteni asi nebude to nejrychlejsi. Testoval jsem Firebird2, ktery ma lepsi optimalizaci dotazu, priznam se, ze plan jsem zas az tak dukladne nesledoval. Nicmene prave ze jsem importoval bez indexu, tak jsem importoval i bez referencni integrity, a somosebou jsem byl liny nastovovat ref. integritu, poprve jsem nastavil jen indexy. Casy Fb. byly zhruba kolem 10 sec, tedy o dost vic nez u ostatnich databazi. Fb. sekvencne cetl tabulku faktura tusim - proste kaslal na primarni index. Takze jsem si dal praci a nastavil ref. integritu, coz melo zasadni ucinek. Takze mozna presnejsi tvrzeni - pokud ma tabulka nad tisic radku, tak index nad cizim klicem pravdepodobne urychli dotaz. Ty indexy jsem u firebirdu zkousel celkem dost, prave protoze mne prekvapilo, jaky to ma zasadni vliv na vykon. Pomohl index i u tabulky produkty, ktera ma 250 radku.
Plany jsem mohl pribalit, pravda. V okamziku, kdy jsem s Fb. dosahoval podobnych casu jako u ostatnich db. jsem se s tim dal nezabyval. Generujici zdrojak mate, tak portnete s.p. do fb, a vygenerujte si jej. -
martin (neregistrovaný)To je rozhodne zajimavejsi srovnani nez ten prvni clanek.
Asi by bylo zajimave (ale taky pracne) prirpavit ruznych testovacich selectu vice a pak se podivat na variabilitu namerenych casu v zavislosti na databazi (nebo spis databazi a platforme)
Cim kvalitnejsi a robustnejsi databaze, tim vyrovnanejsi vysledky by mela podavat (nezavisle na charakteru dotazu si s nim v rozumnem case poradi), zatimco horsi databaze sice nektere dotazy zmakne bleskove, ale na jinych si vylame zuby.
Pochopitelne je vyhoda, kdyz pri vyvoji aplikace nemusite dumat, jak dotaz prepsat, abyste databazi neposlali do kolen. (navic, jak je v clanku popsano, casto se vyvoj dela na malych datech, kde se nic neprojevi a v provozu to pak skripe; u horsich databazi je pak toto riziko vetsi)
Kdyz si seradim databaze podle smerodatne odchylky jednotlivych mereni (predpokladam, je to cas provadeni dotazu), na linuxu mi vychazi poradi (berte hodne s rezervou, tech testu by to chtelo vic a jeste k tomu by to chtelo, aby jednotlive testy byly srovnatelne v narocnosti, aby variabilita vysledku nebyla primarne dana tim, ze jeden test bezi v prumeru 10s, zatimco jiny 0.01s)
Oracle 0.18
InnoDB 0.32 (vsechno vyrovnane pomale)
PostgreSQL 0.42
MyISAM 0.83
Firebird 1.85
na windows pak
MS SQL 0.31
InnoDB 0.36
MyISAM 0.39
Firebird 1.02
PostgreSQL 1.89
Naznacuje to i duvod rozporuplnych nazoru na PostgreSQL a Firebird -- vypada to, ze zalezi, na jake platforme se s tim kdo
setka. -
Pavel Stehule (neregistrovaný)Tak nejak, tri truhy dotazu jsou hrozne malo, i kdyz to urcitou malou vypovidaci hodnotu ma. U mne to byl ve vsech pripadech 4xJOIN, 1 test AND, 1 test OR. Tech dimenzi muze byt vic: dostupna pamet, pocet procesuru /pocet klientu, pocet radku. Urcity ukazatel kvality je take neexistece singularit, tj. napr. vykon dramaticky spadne po vycerpani RAM, pri prekroceni urciteho poctu radku, ... No proste tema na slusnou diplomku.
-
Pavel Stehule (neregistrovaný)hmm tak mam smulu. A delam si z toho ... Oraclisti by meli byt spokojeni za reklamu. Dopadlo to pro ne dobre. Pokud bych je nakrk nejak zvlast, tak at se ozvou. Neni problem si mne najit.
Patrim k tem zivlum, kteri maji problemy nektere veci respektovat, a tohle je jedna z nich. Kdyby se bod d) striktne dodrzoval, tak by se na netu nesmela objevit zadna informace o tom co v Oracle a kdy pouzit, protoze to je v jistem smyslu taky benchmark aniz by se k tomu nevyjadrilo Oracle. Podivejte se na net: vsude mate rady pouzijte to a to. Stejny problem mam s msoftama :-(.
Jde o duveryhodnost informaci: Microsofti plati nezavisle studie, kterym nikdo neveri a nesponzorovane studie nikdo nesmi udelat. Totez u Oraclu. Pokud komercni fy. chteji aby nekdo jejich sw. pouzival a platil za nej, tak se nesmi branit srovnavacim testum. Dejme tomu, ze bude pozadavek zduvodnovat grantove penize na netu. Pokud si za penize koupite Oracle, tak byste mel dolozit proc. Jednim z duvodu muze byt provedeni vykonostnich testu a jejich vysledky. Pokud bych ve zprave proskrtal vsechna cisla, tak zduvodneni vubec nema zadny vyznam.
Pevne doufam, ze fy. prestanou delat z lidi trotly co si neumeji zavazat tkanicky. Tim spis, ze kvalitni analyzy, treba od tretich stran, jsou jednim z mala podkladu proc platit za soft.
Uznavam, ze Oracle je kvalitni, ale je podstatne drazsi nez MySQL. Na netu mate kupu blabolu typu: MySQL je s..t nebo Oracle je *r*c*a. Trochu rozumne analyzy mozna z tohoto duvodu nenajdete. Nebranim se placeni, ale musim vedet proc, chci slyset argumenty. -
honza (neregistrovaný)to je skutecne sokujici. nejaky zoufalec si precte par radku v nejake licenci a zvedne karave prst. A jak za komunistu se vy prikrcite a skoro omluvne reagujete. Kde to jsme?
Samozrejme, ze jste neuverejnil zadny benchmark test. A zcela spravne jste upozornil na to, ze v kazde oracle-konferenci na netu je mnohem vice podobnych udaju. Ale omlovat se jeste takovym idiotum je na me skutecne moc. -
dh (neregistrovaný)Ne, tak to podle me neni. Alespon v pripade Oracle nee Protoze si predstavte, ze udelate aplikaci a najedkou to nekdo bude testovat a vyjde z toho nepravem spatne. Budete-li mala firma, budete upozornovat na nespravnost testu. Jakmile vam to ale preroste pres hlavu, tak to date do licence. To neni hloupost ale jejich svate pravo. Pokud neco proti Oracle mate (nebo jejich licenci), tak ji nepouzivejte = netestujte. Je to snadny jak facka
-
Pavel Stehule (neregistrovaný)Svatych prav uz bylo, taky se upalovaly carodejnice ;-). Ja mam pravo svobody projevu. Nejsem pravnik, takze to dale komentovat nebudu. Jak Oracle tak Msofti produkuji kvalitni software, ale s bodem d) licencni smlouvy mi a) komplikuji zivot, protoze nemam dostatek informaci abych se objektivne rozhodnul (na coz mozna spolehaji), b) nemam dostatek informaci, ktere by mi oduvodnily vydaje c) pokud publikuji objektivni informace, tak nikoho neposkozuji, ale naopak - kvalitni a objektivni informace poslouzi vsem. ==> bod d) pro mne neexistuje.
-
Zírám, že zrovna na tento server píše autor, který tak okatě pohrdá licencí. Pokud někdo dává k dispozici software (a je jedno, jestli zdarma nebo komerčně) a vydá k němu licenci, která není v rozporu se zákony, tak přece tu licenci musím respektovat, ne? To bych mohl říct, že se mi nehodí, že z GPL software nemohu vyházet copyrighty, a dílo prodávat jako svoje vlastní bez poskytnutí zdrojáků, tak to jednoduše udělám.
Wikipedia: Benchmark (computing):
In computing, a benchmark is the result of running a computer program, or a set of programs, in order to assess the relative performance of an object, by running a number of standard tests and trials against it.
-
anonymníReseni je jednoducha - kazdy autor necht explicitne uvadi, ze Oracle zakazal zverejnit vysledky, proto nejsou uvedeny. Kazdy ctenar si automaticky pomysli to nejhorsi, v pripade nejakeho managera ktery vi prd a rozhoduje o nakupu technologie by to mohlo zasit velke problemy :)
Predpokladam ze by je to po roce prestalo bavit a zrusili by to. -
Me se ten článek líbil, nechci zde výřit vody, jen mě překvapilo, že první test, který jsem vygooglil, měl výsledky Oracle "začerněny", a pátral jsem proč.
Ono to ale dá rozum, mají v tom spoustu peněz a rozhodně není dobrý, aby kdejaký troba dělal "testy", ze kterých vypadne Oracle jako poražený. A to může být nejen tím, že bude Oracle špatně nastaven nebo bude volena špatná metodika (viz minulý test, kdy ostaní DB "dostaly na frak" od Firebirdu).
Test se mi líbí, jsem realista a zastávám názor, že 70 % všech databází jede (zhruba) v defaultním nastavení, takže takovéto "jednoduché" testy mají svým způsobem vypovídající hodnotu. Na druhou stranu takto testovat Oracle je minimálně přitažené za vlasy -- jakkoli Oracle v poslední době zlevnil a vyšel vstříc menším firmám, patrně si na implementaci (řádně) placené DB najmete/zaměstnáte odborníka, který si už bude vědět rady, jak Oracle nakonfigurovat.
A malá poznámka na závěr -- enterprise aplikace jsou hlavně o vkládání a aktualizování záznamů, jakmile překorčí dotazy únosnou mez, používají se různé postupy, které toto řeší (DATA MINING, OLAP...). Kdybych já dělal test, asi bych se zaměřil na všechny aspekty, protože SQL to není jen SELECT (toto dost evokuje v poslední době www/php boom). A také bych si přečetl něco o metodice testování, SELECT COUNT se mi nejeví jako nejlepší příklad -- ale to je jen můj amatérský dojem.
Díky za článek, který rozhodně Oracle nepobouří. -
Pavel Stehule (neregistrovaný)Udelejte ten test, rad si to prectu. Do update, insert jsem se nechtel poustet, nechtel jsem napsat komplexni test. Ten se pripravuje tydny a ne jeden den. Inserty to je spis test importu - a ten uz je pro kazdou databazi specificky, pg. principialne 2, oracle 5, o dalsich ani nevim. Testovat update ma smysl, pokud budete simulovat provoz. S updatem vetsinou neni problem v zapisu, ale s tim, ze update zustane na nekterem zamku. Tudiz potrebujete skripty, ktere budou simulovat typickou cinnost uzivatele, pokud mozno vzit v potaz treba to, ze se vetsinou pracuje pouze s novejsimi radkami, atd. Napsat takovy skript uz Vas nejaky cas stat bude. Smysl by to melo. Alespon co vim, a co by se dalo predpokladat, tak vsechny MVCC databaze by od n (cca kolem 5) klientu by meli mit dost navrch nad mysql, ktere vede v hrube sile.
SELECT COUNT ma jednu vyhodu - musi se zpracovat vsechny radky, ale vysledkem je pouze jedna hodnota - tudiz vliv protokolu bude minimalni (viz. predchozi uvahy o overhead protokolu mysql, firebirdu, mssql). Ne ze by to nebyly zajimave hodnoty. Ale je podstatne obtiznejsi je ziskat (tak aby mely aspon nejakou vypovidaci hodnotu) -
benzin (neregistrovaný)Chapu, ze se chcete ucit a to je jiste chvalihodne, ale preci smyslem clanku neni, cekat jestli mne nekdo vyvede z omylu nebo ne. Clenek piste, az mate dojem, ze jste na danou problematiku skutecne odbornik (i tak bude jeste mnoho mist, kde vas nekdo opravi).
O co se ROOT snazi? Chce nam ukazat, alternativni zpusob zaskolovani? S takovymi clankami bezte do diskuse.
Jen doufam, ze v MF, HN, nebo Lidovkach se nerozhodnou psat clanky stejne. Uz to vidim: "Amerika vyhlasila Ceske Republice valku" bude titulek. V uvodnim odstavci bude neco jako "tento clanek tu pisu, proto abych se neco priucil" a pak budou zcela zcestne informace, nasledovane e-mailovou adresou, kde je mozno predat nejake informace autorovi. -
Pavel (neregistrovaný)Ono ani jedno ani druhe proste nejde v prostoru, ktery dava root provest. Jenom o std. db testech by se dalo napsat desitka clanku, pokud by meli byt fundovane, a odhaduji, ze je v Cechach tak pet, sest lidi, kteri by o tom mohli neco napsat obecne. Co vite o rizeni a testovani kvality sw? O tom jsem vubec psat nechtel, kdybyste si precetl, co jsem napsal, tak byste se docetl, ze se pidim po prinosu jednoucelovych jednoduchych testu. Verohodne srovnani je dalsi samostatna kapitola. Kdo ma povedomi o multikriterialni optimalizaci, tak vi, ze objektivni porovnani neni pri vetsim poctu kriterii prakticky mozne, vzdy zalezi na vahach, ktere priradime kriteriim. Ale to je taky neco uplne jineho.
Priznam se, ze jak rad pokecam s ostatnimi, kteri mne na neco upozorni nebo prijdou s napadem, pripadne se ptaji na neco konkretniho, tak Vas moc nechapu, kdyz to reknu slusne. Jeste jednou si to prectete, kdyz vas to tak zajima, popremyslejte, nechte rozlezet v hlave, pockejte tyden, a pak zkuste s necim prijit,
ps. -
Pavel (neregistrovaný)Kvalitní text na toto téma budu publikovat jako disertační praci a ne na rootu, ne? Vím toho dost o Postgresu, MySQL, abych něco o něm mohl napsat, míň o firebirdu. Nakolik této problematice rozumím, P.B. ví. a)Neabsoloval jsem nikdy žádne 150 tis. školení od Oraclu, tak možná vůbec, napsal jsem většinu textů v češtině o postgresu, mysql5, které jsou na netu, tak možná, že ano. Lichotíte mi, na MF zdaleka nemám. Nedávno v titulcích napsala 20000 tis. obětí, pak v článku možných 20000, a za tři dny v malém článku, že jich vlastně nebylo ani 1500. Ale asi odborník nejsem, 99% odborníků v životě nanapsalo jediný článek, a z těch co publikují, si skoro nikdo netroufne tvrdit, že rozumí všemu. b) mám pocit, že nemáte anunk, o co mi šlo :-)
-
benzin (neregistrovaný)Slo Vam jenom o napsani clanku, proto aby byl clanek. Budete-li ragovat na vsechny pripominky dostatecne dlouho muze Vam to vydrzet na dlouhy serial.
Nevim jestli Root plati za clanky, ale pokud jo. Verim ze si takhle muzete vydelat a pritom se ani nezadychate.
Btw. dekuji, ze jste sam uznal, ze neco kvalitniho date az na disertacku, nebo diplomku, ze pro roota je vasich kvalitnich praci skoda a ze chcete roota vyuzit k tomu, aby Vas ostatni v diskusi zadarmo vyskolili. -
Pokud budou v reálném provozu tyto dotazy převažovat nad vkládáním dat (a vzhledem k tomu, že se testuje jejich rychlost a ne rychlost vkládání, tak předpokládám, že tomu tak bude), neměly by být v tabulkách definovány i nějaké složitější indexy než jen nad primárním a cizími klíčemi?
Jak by testy dopadly, kdyby byly definovány např. klíče faktura (vlozeno, zakaznik_id), produkty (trida, id) a zakaznik (kategorie)?
Já vím, že musely být hrozně pracné i tyhle testy, ale bez dokonalého vyladění všech systémů nevím, k čemu vlastně slouží. Když mě začne tlačit výkon databáze, tak nejprve optimalizuji dotazy, potom nastavení databáze a pak se teprve začnu kopat do zadku, že jsem nepoužil jinou databázi, která by byla pro mé účely vhodnější. Takže test by měl spíš ukazovat, kam až jde s danou databází zajít (pro případ, že mě začne tlačit její výkon), a ne to, jak se chová při spuštění z voleje. -
Matyas (neregistrovaný)Ahoj,
dik za clanek, tendle je jiz oproti puvodnimu rozumnej :-). Jen je skoda, ze tech sledovanejch dotazu nebylo vic a ze nebyly prilozeny u Firebirdu plany.
Dle mych zkusenosti s firebirdem (delam nad ni asi dva roky a obcas se s jejim vykonem trochu peru) je jeho rychlost na planech i na pouzitych dotazech dosti zavisly. V nekterych pripadech jsem zjistil, ze specifikovat Firebirdu spravny plan je opravdu nutnosti - zrychleni je deseti a vicenasobne (z nekolika minut na radove sekundy).
Take se mi zda, ze firebirdu vylozene nesedi operator OR. Nektere dotazy po pridani OR podminky do WHERU nekolikanasobne zpomalily, a dokonce pri specifikovani planu pri slozitejsich joinech a zaroven pouzitem operatoru OR se Firebird spolehlive zasekne (uz to je v bugreportu).
Pres to vsechno je Firebird jedna z nejlepsich databazi pro psani aplikaci na WIN, ktere se maji jednoduse distribuovat - pro RAD nastroje (C++ Builder, Delphi, etc...) asi neexistuje databaze, ktera by mela podobne moznosti a zaroven k ni byly spolehlive, volne upravovatelne komponenty
Matyas -
anonymnío tom ze budu za debila v nejmensim nepochybuji, presto dekuji za clanek, pro mne okrajove orientacni, a vsem stezovatelum (hlavne ku clanku predchazejicimu) snad jen vzkazat ze v duchu GNU a freeSoftu mohou kdykoli vytvorit vlastni test, klidne o 100 stranach, hlavne nezapomenout zadny " ; " :-)
-
Jan Sunavec (neregistrovaný)1. Tento clanok pysal niekto iny ako ten predosly.
2. Co sa tyka vypovednej hodnoty benchmarkov. Seriozny benchmark je cisla utopia. Jedina cesta ako zmerat databazy je robit viac takychto benchmarkov. Takze za clanok vdaka. Ten Oracle a MS SQL mi prisly celkom vhod. Dufam, ze Oracle to nestiahne. Spravit taky test je dost makacka, zvlast ked sa za to velmi neplati. Ono kazdy kto sa zaobera databazami by mal spravit nejaky test a zverejnit to na Root-ovy.
