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. :-)

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.

"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.

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.

no je to o poznani duveryhodnejsi nez ten minuly, nicmene ten rozptyl hodnot je podezrele vysoky, obzvlast innodb linux vs win me prijde dost podezrely vzhledem k tomu, ze je predpokladam vyvijena primarne na linuxech?!?

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

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.

Note that InnoDB uses fsync() instead of fdatasync(), and it does not use O_DSYNC by default because there have been problems with this on many varieties of Unix.

Ten postgres 8.1 byl nejaka beta, nebo z cvs, pokud cvs tak by me zajimalo ze ktereho dne - jde mi o ten test ve w3k (asi vite kam tim mirim) ?

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.

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.

Jenze takto nebudete NIKDY importovat vetsi data do DB. Kazda databaze ma nejake nastroje pro rychly import, i Firebird.

>Oracle Database XE mohu jedině doporučit. Jak instalace, tak provoz jsou překvapivě jednoduché.

To sice ano, ale jen pokud vas system ma RPM...

Psal jsem snad neco jineho? Co mi hrozne chybi v Linuxu jsou datove pumpy MsSQL. Ty od Oraclu neznam. Proste jsem v sobotu nemel chut programovat, a konvertovat tabulky. Nic vic ;-)

Autor presne definoval co testuje a NEtestoval import dat, ale join nekolika tabulek.

díky, že ses mně zastal náčelníku :-). Co rodina?

+external tables od oracle 9iv2

Zdravim,

vo vsetkych tabulkach je * po dodatocnom pridani indexov. Ale akych indexov. Moze autor pridat sql prikazy pre vytvorenie indexov, pretoze by to pomohlo aj ostatnym, aby si pozreli, ze ktore indexy su vhodne, ktore nie.

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.

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.

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.

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.

...tím myslím jak bude vypadat provádění pokud budeme připojovat víc klientů zaráz. My třeba máme nějaké scripty, co běží minutu až dvě a ostatní se v té době nehnou z místa.

Licence vývojářská a betatestovací:

(d) disclose results of any benchmark tests of any Software to any third party without Oracle's prior written approval;

Licence pro nasazení:

disclose results of any Program benchmark tests without our prior consent;

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.

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.

to jste mne spatne pochopil, rozhodne jsem se neomlouval, spis mne to pobavilo.

Idiot je ten, kdo své činy omlouvá tím, že je dělají i jiní.

a) drzte se pri zemi, b) kdyby komercni fy. myslely a chovaly se umerene, tak nikdo nemusi porusovat pravidla, kvuli hloupostem.

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

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.

Jste si tak jisty, ze tato licence neni v rozporu se zakony nebo dobrymi mravy?

V tom prvním zcela jistě ne.

jste si jisty, ze licence v anglictine je pro uzivatele pri zakoupeni produktu v CR pravne zavazna?

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ří.

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)

Teďka možná jen plácnu, ale není databáze natolik "chytrá", že si někde poznačí, kolik daný dotaz vrátil řádek a pokud se data nezmění, bude vracet jen to jedno číslo? Nebo je to tak zbytečná kompilace, že se to nedělá?

Nedělá se to.

psychologove tvrdi, ze pro muze, kteri jsou zalozenim ucetni, je nejlepsi zena=hysterka.

Po odborne strance prosim jeste si ujasnit, co je "benchmark tests". Ale kolega ucetni je jiste schopen obratem dovalit definici (odpovidajici pravnimu systemu CR)

je velmi poučné pozorovat, jak se na databáze dívají různí lidé. Mimochodem, nemohl byste odhadnout, kdy bude ostrá 8.1?

dokaze tu niekto porovnat tieto databazy s GUPTA SQLBase? na linuxworlde som dostal od nich CD s trial verziou a tabulkou ukazujucou ze je naj.... naj... a naj...., ale zaujimalo by ma, ci to uz niekto aj otestoval v reale a ako to vyzeralo.

Tohle existuje i pod linuxem ?

Ptám se jen tak ze zvědavosti - před pár lety jsem v tom vyvíjel SW a měl jsem dojem, že to běhá jen na Woknech.

tvrdia ze su v linuxe rychlejsi nez oracle

To tvrdi kazdy: otazka zni kdy?

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.

Ano "Cesta je cil", jenze i ten autorovi unikl. Clanek totiz neni ani o zpusobu jak kvalitne testovat DB, ani o verohodnem srovnani rozdilnych DB. Stoji napuli cesty a ani v jednom ohledu nic neprinasi.

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.

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 :-)

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.

bez komentare

Root plati, pokud vim 400 za clanek. Autor ho psal minimalne den. 400 za den neni zas takove terno, to mate 50,- na hodinu :-)

To se na rootu nesmi publikovat disertacni prace ? (Nejlepe po obhajobe).

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.

Priznam se, ze mne nikdy vykon natolik netlacil, abych delal slozene indexy obsahujici neco s primarnim klicem, tolik zas fantazie nemam. Dostanete mozna par procent, ale .. to neni cesta, kterou bych doporucoval.

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

testoval jsem dvojku, kde asi ty nejvetsi bugy byly odstraneny. zas na druhou stranu, bez tech indexu nad cizima klicema generoval sekvencni cteni druhou nejvetsi tabulkou. Ostatni db. takovou botu neudelaly

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.

commit kazdych 50000 alebo 100000 ?? to ma byt nejaka univerzalne platna konstanta ?
;-)

Nástřel , se 100 000 tisici to jeste proslo, paraganska padina na jistotu 50 000 :-)