Názory k článku MySQL vs PostgreSQL vs Firebird
-
Jenom poznámka k tomu tvrzení, že u Firebirdu "Existuje už aj verzia pre Linux":
Firebird, původně Interbase a ještě původněji Jrd byla koncem sedmdesátých let nejprve implementována "pro počítače Apollo, VAX, PDP a HP, a v prostředí operačního systému VMS a UNIXových systémů jako je HP-UX, Solaris nebo AIX" (citát z knihy Podrobná příručka InterBase/Firebird). Na Windows - a také NetWare a Linux - byl přenesen až později Borlandem poté, co tuto databázi v roce 1989 koupil od původního autora Jima Starkeyho. Podle zmíněné knihy byla InterBase vůbec první komerční databází přenesenou na Linux. Firebird, který vznikl po uvolnění kódů InterBase 6.0 v roce 2000, byl tudíž od začátku vyvíjen jako multiplatformní databáze běžící mj. i na Linuxu.
MS Windows tudíž rozhodně není primární platforma, na níž by Firebird běžel.
Co se týče samotného testu, řekl bych, že testování rychlosti načítání jedné tabulky je od standardního nasazení docela vzdálené a jeho vypovídací hodnota je docela malá. Škoda. :-/
-
Michal Kubeček (neregistrovaný)
Upřesnění: Jim Starkey prodal InterBase (i se svou firmou) nejprve Ashton-Tate (ano, dBase), Borland posléze koupil celou Ashton-Tate i s InterBase.
MS Windows tudíž rozhodně není primární platforma, na níž by Firebird běžel.
Podle toho, co vídám v firebird-devel listu, bych řekl, že v současné době je win32 primární platformou podstatné části vývojového týmu.
-
Miroslav SuchýStříbrný podporovatel -
benzin (neregistrovaný)Par chyb a nedostatku
1) Neuvadite verze MySQL a FireBirdu (mezi 1.0, 1.5 a 2.0 jsou jiste vykonostni problemy)
2) Na import dat do Firebirda existuji nastroje, popripade primy pristup k radku db (hodne to urychluje).
3) Provest test nad nevyvazenymi indexy (postupne mazat a pridavat zaznamy, az se indexy rozbiji), mozna Firebird strati dech.
4) Provest test nad hodne menenou databazi (Firebird, zaznamy nemaze, ani neupravuje, vzdy vytvori novy a i se zmenou, takze se zaznamy postupne hromadi).
5) Provest test rychlosti s primym pristupem k tabulkam.
6) Provest test rychlosti, alespon s nejakymi agregacemi (alespon zakladnimi).
7) Otestovat rychlost advancet technologii: vnorenych selectu, kurzoru, pohledu, uloznych procedur, spojovani tabulek s vytvorenymi cizimy klicema.
Je mi jasne, ze autor se snazil provest testy kompletni, ale bohuzel neni. Jsem presvedcen, ze nap. pri vyuziti FK (Foreign Key), by PostgrSQL dosahl vyrzne lepsich vysledku nez MySQL (ktery je nemaji).
P.S.: Free nastroje na udrzbu FireBirda najdete primo na http://firebird.sourceforge.net/. FlameRobin a IBExpert. (Vetsina nastroju pro InterBase funguje i pro FireBird). -
rezna (neregistrovaný)presne tak proc se testuje pgsql 8.1 beta ale beta (dnes uz i RC) MySQL 5 je ignorovana.
jinak ten benchmark je fakt o nicem - testovat vykonnost by to chtelo tak na inner/left joinech aspon 20 tabulek kde kazda tabulka ma aspon 5k radku - proste takove minimalni bezne zatizeni vetsi aplikace.
delat benchmark pro mini aplikace a mini DB nema smysl.
navic benchmark delany pomoci PHP se mi nelibi - zavisi hodne na rychlosti extension pro danou DB - chtelo by to benchmark primo z konzoli danych DB. navic by taky neskodilo porovnani proti oracle a mssql ;) -
Filo (neregistrovaný)Otazkou je, zda ma smysl hledet pri dnesnich velikostech HDD na nejakou efektivitu ukladani nebo na to, aby select probehl co nejdrive. Osobne preferuji druhou moznost, protoze zakaznika absolutne nezajima, jak jsou udelana streva, ale jak se cela aplikace chova a 'vo tom to je' ;)
-
zz (neregistrovaný)to je pekne ale skusal si taky projekt expandovat o nove funkcie a zdroje dat? asi nie. V kancli sedim este z kamosom kazdy mame ini pristup ja mam vecsie mnozstvo tabuliek viacmenej mam tabulky na co najmensie casty a vsetko poprepajane klucmy. kamos robi co najvedsie tabulky aby to mal hned.
ja mam aplykaciu ktoru robim stale komplexnejsiu nad jednou DB a on je vdaka nie najlepsiemu navrhu buduje stale nove a nove DB a aplykacie mu chodia do viacerych DB naraz a z kazdej potom vytahuje z 20 stlpcovej tabulky 3 stlpce alwebo ma cast zaznamov duplicitnych v roznych DB fakt radost nieco nove dorobit.
troska vela roboty na DB kde mavame maximalne stovky zaznamov. -
earl365 (neregistrovaný)Agregacie:
Svojho casu som skusal rychlost PostgreSQL 8 a firebirda 1.5.2. Mal som tabulku, cca 90000 zaznamov + vytvoreny view s troma agregaciami (nejake county). Potom som robil selecty na tomto pohlade, ale zotriedene podla tych agregacii (take boli poziadavky) Na mojom pocitaci trval jeden select na PostgreSQL cca 22 sekund, kym na Firebirde asi 4-5. Takze je tam rozdiel. A velky.
Na druhej strane vie PostgreSQL veci, ktore Firebird nie (minimalne vo verzi 1.5.2). Napr. inline view. -
P.L. (neregistrovaný)Problem bude mozna v tom, ze postgres neprovadi optimalizaci agregacnich funkci (existuje jeden rozsiritelny framework, ktery je pouzit i pro count()). Nektere databaze count dovedou optimalizovat (pomoci indexu a pod).
Mozna ze by vysledky vypadaly uplne jinak u jine agregacni funkce ... ale to v realne aplikaci moc nepomuze ;-) -
anonymníad 4)
hmm, pocul ste niekedy o transakciach?
tento pristup pouziva i postgresql, ono sa vam totiz moze stat, v jednom okamihu moze mat kazda transakcia svoju vlastnu kopiu riadku (ci az vsetkych riadkov) danej tabulky. (a to je vlastne hlavny dovod, preco existuje vacuum)
btw, ako je na tom emulator databazy (mysql) v pripade, ze tabulka je vacsia ako velkost pamate? este stale ma problemy? -
anonymnínie, neudelal.
mal som nasadene mysql a vzdy, ked velkost tabulky presiahla velkost fyzickej pamate, CPU slo na 99% a niekolko sekundove requesty. pridanim pamate sa problem vyriesil.
nakoniec som premigroval na postgresql, tabulka ma momentalne 20GB a server ani nevie, ze nejake selekty robim.
a co sa tyka mssql, nasiel som uplatnenie aj pren, skutocne vyborna podlozka pod hrncek s cajom :-))) -
anonymníjj, nieco blbe som urobil, pouzil som mysql.
prikaz bol vykonany z konzoly (program mysql), jeho vystupom malo byt mizive promile (10 z 10M) riadkov.
jediny problem co som zistil bol v tom, ze index bol na celu tabulku (v mysql akosi neboli partial indexy).
a klinec do rakvy zarazil pripad:
select * from table where status > 1;
id | status
-----------
1 | 1
!!!
jednoducho mysql neprekrocilo tien php ... bordel, nefunkcnost, nestabilita. -
anonymníhmm, nevravim o databaze, ale o tabulke.
je pravda, bolo to pred 4-mi rokmi, bolo to myisam.
a chyba navrhu?
ak jeden navrh sposobi zablokovanie stroja pri mysql a postgresql nie, chyba bude inde. nebol to jediny system, kde som sa s podobnou situaciou stretol (a pravda, stretol som sa aj s tym, ze to nezablokovalo). ci to bolo indexami alebo strukturou dat, nezistoval som.
poviem to asi takto ... ak niekto odomna chce mysql, nasleduje odhovaranie, ak je neuspesne, tak zdvojnasobenie sumy s podpisom dohody o vzdani sa naroku na zaruku -
Miloslav Ponkrác (neregistrovaný)Já se přiznám, že za léta používání MySQL jsem se s ničím podobným nesetkal. Já koukám na MySQL jako na hloupoučkou, ořezanou databázi, která je ale spolehlivá, multiplatformní, dobře pracuje s thready a je dobře zdokumentovaná. Ještě nikdy se mi nestalo, že by mi MySQL udělala nějaký skutečný průšvih. Pravda je, že raději dělám s lépe vybavenými databázemi, než je MySQL, ale často jsem nucen na nich něco postavit.
Žádná databáze nebude úplně bez vroubku. Stačí si přečíst libovolný seznam chyb k libovolné databázi, pokud je tedy vývojáři zveřejňují. Nicméně myslím si, že hlavní problém bude v tom, že "nezistoval som", kde je problém. Na 99% bývá problém mezi klávesnicí a židlí, spíše, než v databázi.
Ona každá databáze chce svoje a chce trochu péči. Když mě teď posadíte k PostgreSQL, se kterou jsem skoro nikdy nedělal, tak vám pravděpodobně udělám podobná zvěrstva a bez dostatku sebereflexe dojdu k závěru, že PostgreSQL je neschopná databáze a budu od zákazníků vyžadovat zdvojnásobení sumy a vzdání se nároku na záruku. -
benzin (neregistrovaný)No nemate tak zcela pravdu. To ze ruzne databaze zvladaji ruznou zatez ruzne, je preci jasne. Musite se prispusobit. Teoreticky jde sice ten samy SQL dotaz nasadit na vice databazi, ale prakticky je vhodnejsi upravit konstrukci pro kazdy dany db stroj.
Jinak s tim nerucenim za MySQL s Vami souhlasim. MySQL nezvlada omezeni, ani FK ani trigery. Pak se spatne zajistuje konzistence dat. (Tedy nevim jak verze 5, jestli tohle jiz zvlada)
Add. MsSQL, musim rict, ze mne svou rychlosti velmi prijemne prekvapila. Ale nerozhodl bych se pro ni, existuji databaze zadarmo a pokud potrebuji opravdu dobry vykon, pak jedine Oracle. -
Fero (neregistrovaný)Heh, borec co si nevie ani len MySQL nainstalovat, nakonfigurovat a spravne pouzivat. Zaujimave, ze vsetkym to spolahlivo funguje, len jeden expert musi odhovarat a vymyslat dohody o vzdani sa zaruky :))
Doporucit klientovi Oracle bude to spravne riesenie. Za licenciu zaplati $40k a za aplikaciu $4k. Tomu hovorim "deal"! :-) -
rezna (neregistrovaný)nemyslim si ;) - MySQL rozhodne neni stavene na velke projekty, uz prave treba absenci Stored Procedur, nebo chybejicimi views (ve starsich verzich) nebo parametrickych views (v 5.0).
jako proti oraclu je mysql 'sracka' kterou bych si na projekt nevzal - jestlize mate spravovat distribuovanej system DB ktere se replikuji z centralni DB pro celou republiku a DB ma klidne pres 30GB tak proste MySQL nema sanci ani kdyby se na hlavu stavela. -
Chhhh.
Nevies rozlisit medzi rozsiahlostou a druhom projektu a tym, ci na to chces pouzit Oracle alebo MySQL. Niekto skratka nepotrebuje Oracle na fungovanie na projektoch, ktore su mensie nez tvoj distribuovany system replikovanych databaz pre celu republiku. Mozno tam MySQL nema sancu, mozno ale na niecom mensom vie byt MySQL so svojim features vhodnejsi kandidat nez Oracle. Tvoj pristup je stylom, kupim si dvojliter auto, jazdim s nim z prace a do prace, ved ta jednadvojka je o hovne, to nema 2 litre! Absolutne neefektivne pouzitie v danom pripade. Neber teda ze Oracle je vseliek najlepsi na vsetko, su nasadenia, kde proste je zbytocny. Lenze ty si a priori zaujaty. Skoda. Preto mozno pri svojich projektoch a Oracloch castokrat prehajdakas vagon penazi, lebo proste nie si schopny najst ine, efektivnejsie riesenie, lepsie aplikovatelne na danu situaciu.
Ak sa mylim, tak ma oprav prosim. A prepac, ze som sklzol troska do osobnejsej roviny a jemne mimo temu debaty :). Len ma unavuju bitky medzi Oracle vs MySQL, Linux vs Windows a podobne. -
anonymnílol fetujes? ... keby si nenapisal tu zatvorku, mozno by som sa k tvojmu nazoru priklonil.
ale uvedom si, ze ak v takejto aplikacii presadis nieco ine, tak vsetko co padne, padne na tvoju hlavu.
v tomto pripade je otazka, ci ten oracle je nutny (resp, ci to nie je kanon na vrabce). ale tvrdit ze mysql sa na takejto urovni dokaze co i len pozriet na oracle, to uz hranici s fanatizmom. -
marx (neregistrovaný)Je síce pekné, že FB často dosahuje slušné rýchlosti. Ale priznám sa, že by som sa radšej poobzeral po niečom inom. FB je síce viac-menej prepísaný InterBase, ale hlavne pri skutočnom využívaní narazíte na viacero problémov. Základnou chybou je brutálny nedostatok informácií pre programátora (napr. k C API) a spolieha sa na dokumentáciu k InterBase, na čom by samozrejme nebol nič tak hrozné, keby sa kde-tu niektoré veci chovali 'o kúsok' inak. V mailing listoch sa toho príliš nedozviete, pretože väčšina ľudí používa niečo postavené nad týmto API (takže vám zostávajú len tvorcovia API pre PHP, Perl, C++, ...). O problémoch pri práci s BLOBmi, či nikdy nekončiacimi memory-leakmi (bežne vám po commitnutí tranzakcie ostáva v pamäti zopár mega, až kým sa od DB neodpojíte; dá sa dosiahnuť žravosť cez 4MB/s :) ).
-
Almad mluvi o Developer CD od nas (IBPhoenix). Uz par let jsou na nem e-knihy Using Firebird a Firebird Reference (mimo jine, prubezne rozsirovane specializovane dokumentace pro "pokrocile"). Dokoncuje se Firebird API Guide. S novou verzi FB neni treba kupovat nove CD, protoze rozdily jsou popsane v Release Notes dane verze. BTW, na CD je samozrejme vic nez jen dokumentace.
Co se obecne moc nevi je, ze dokumentace produkovana IBPhoenixem je s drobnym zpozdenim (cca 2 roky, nejak musime kompenzovat nemale naklady na vytvoreni) uvolnovana Dokumentacnimu projektu Firebirdu (viz web projektu Firebird), a zminovane dve prirucky jiz byly projektu poskytnuty. Bohuzel je to spousta textu, a nejakou dobu jim potrva, nez si to prevedou do XML (pokud si dobre vzpominam, ted je hotovo cca 80%) ktery pouzivaji. Pokud chcete co nejdrive volne dostupne e-knihy o Firebirdu, doporucuji jim trochu pichnout ,-)
Jinak jsou k dispozici i tistene knihy. Ta co vysla v cestine u Computer Pressu pokryva Firebird 1.0 a 1.5 (nemluve o IB 6.0 - 7.0), vcetne rozdilu a kompletniho prehledu prikazu. Za cca 450.- penez to pro nasince vyjde docela levne. Pak je k dispozici i naprosto skvela THE Firebird Book v anglictine vydana APressem (cca 1000 stran), a ktera je cela jen o Firebirdu. Jeji jedina nevyhoda je absence prehledu SQL prikazu. -
Miloslav Ponkrác (neregistrovaný)Blahopřeji vám k vaší činnosti, nicméně si myslím, že ideální situace je taková, kdyby vaše činnost nebyla vůbec potřeba.
Váš příspěvek mi jen potvrzuje, že Firebird má katastrofální stav dokumentace, a že to tak nejspíše bude i nadále. Dovedu si představit, jak aktuální budou informace, které po dvou letech přijdou Dokumentačnímu projektu Firebirdu, které jsou pak ještě pozdrženy dalšími převody do XML. Nezlobte, ale s tímto opravdu pomáhat nebudu, ač jsem se již na pár projektech podílel. Rád se budu podílet a věnuji určitý svůj čas na tvorbu AKTUÁLNÍ dokumentace, ale určitě nebudu ztrácet čas s dokumenty, jejichž hlavní hodnota je historická.
Následující věty jsou jenom můj názor. Podle mého Dokumentační projekt Firebirdu jen ztrácí čas. Neměl by tříštit síly na hafo příruček, ale měl by to udělat tak, jak to vidím u dobře zdokumentovaných projektů jako jsou například MySQL, nebo PHP. Ideální je mít JEDEN velký dokument, ve kterém by bylo vše potřebné. Takový jeden dokument by se jednak dobře udržoval aktuální s mnohem menším nasazením lidské práce, než je současný stav. Jednak by se zbytečně neduplikovaly informace a IMHO je to ta nejlepší forma dokumentace, kterou znám.
Knihu od Computer Pressu jsem měl v ruce. Mohu o ní říci jenom to, že je to skvělá kniha, ale není to nic víc, než úvodní partie do Firebirdu/Interbase.
Abych se přiznal, pro mě je to pořád začarovaný kruh. Špatná dokumentace k Firebirdu u mě vede k tomu, že jej prostě nepoužívám. -
Mno, dovolím si nesouhlasit.
Jednak dokumentace postoupená projektu není nijak zastaralá, jen Reference Guide by potřebovala doplnit o info (o stejně zatím nevydané) verzi 2.0. Vzhledem k zpětné kompatibilitě v podtatě nic nezastarává, pouze se doplňuje.
Druhak jeden jediný dokument je krajně nepraktický, speciálně v PDF. Kniha Using Firebird má 766 stran, Firebird Reference má 413. Pokud se k tomu přidá Firebird API Guide a nějaké "kapitoly" na speciální témata, tak by se váš "univerzální dokument" vyšplhal na 1500-2000 stránek. A s tím se prostě dělat nedá, ať už by byl v PDF, HTML nebo i na papíře (jen The Firebird Book má přes 1000 stran, tloušťku 7 cm a váží tři kila).
Volně dostupné dokumentace je hodně, stačí jen chtít ji najít (v podstatě vše je dostupné z našeho a webu projektu). Že není volně dostupná dokumentace přehledně strukturovaná je sice pravda, ale co by jeden za ty peníze nechtěl :-) Tým PostgreSQL měl na tvorbu dokumentace víc času než Firebird, do dvou let bude mít FB taky takovou. A ti co nechtějí čekat si vždycky můžou koupit knihu. O FB jich už vyšlo docela hodně v mnoha jazycích. -
Miloslav Ponkrác (neregistrovaný)Netvrdím, že vaše dokumentace z doby před dvěma lety není použitelná. Jako z nouze ctnost proč ne.
Formát jednoho dokumentu je praktický i při rozsáhlých projektech.
Co se týká formátu PDF tak jej považuji za formát vhodný pro tisk, ale naprosto nevhodný jako normální manuál používaný pro praxi. I když je pravda, že se setkávám v mnoha projektech (ať už komerčních, nebo free) s tendencí vydávat dokumentaci v PDF, snažím se vždy sehnat manuál v jakémkoli jiném formátu, než PDF. Skoro cokoli je lepší, než PDF, pokud to mám používat dnes a denně na vyhledávání informací při vývoji nějakého projektu. PDF je ve skutečnosti spíše grafický formát, než dokument.
Pro praktické používání je daleko vhodnější třeba vhodně indexovaný HTML. Nevím, co Vás vede k názoru, že se takto nedá dělat s rozsáhlými dokumenty. Například dokumentace k Java 1.5 SE v HTML obsahuje 9765 stránek (většina stránek je svým rozsahem na několik tištěných stran) a vůbec nemám pocit, že by to bylo nějak na závadu přehlednosti a pracuje se s tím velice dobře. Požadovanou informaci v tom najdu v okamžiku. Dokumentace k MySQL stylu vše v jednom v HTML formátu také obsahuje velmi mnoho stránek určitě přes tisíckovku a je to velmi dobře použitelné. Dokumentace k PHP je také značně rozsáhlá ve stylu vše v jednom. Prostě běžně prakticky dělám již řadu let s rozsáhlými dokumenty v HTML/CHM podobě, kde rozsah jednoho dokumentu řádově přesahuje to, co mi tu líčíte jako výsledek u Firebirdu a nemohu si to vynachválit. Naopak obrovská řada projektů má jeden dokument, který svým rozsahem značně přesahuje veškerou dostupnou dokumentaci Firebirdu .
Je jasné, že taková dokumentace není určena k tisknutí na papíře, to dá snad rozum. Argumentovat nějakou knihou je stejné jako vytýkat Microsoftu, že jeho MSDN přesahuje rozsah knihy.
Ano, volně dostupné dokumentace je dost, jsou tu ale dvě ale. Na to, abyste se seznámil se základními funkcemi Firebirdu vydáte několikanásobek času, než u jiných srovnatelných databází, který strávíte hledáním a dáváním si různých střípků informací dohromady. A to ještě příznivě podpořeno tím, že naštěstí tu máme slušnou příručku od Borlandu k Interbase. Druhé ale je, že se velmi těžko pátrá po dokumentech, které by trochu popisovaly Firebird do hloubky. Byl bych rád, kdybyste mě zejména v tomto bodě přesvědčil o opaku, a já rád vše odvolám.
Koupení knihy nic neřeší, protože zkrátka rozsah jakékoli knihy může být jenom zlomkem toho, co může být v kvalitní dokumentaci. Kniha je dobrá věc, ale neřeší vše.
Závěrem podotýkám, že velmi rád přiložím ruku k dílu, pokud Firebird začne dělat dokumentaci ROZUMNÝM způsobem. Mám ale pocit, že je od toho velmi daleko, a že příliš nevěřím tomu, že Firebird bude mít do dvou let taky takovou dokumentaci. Tedy pokud to bude plichtit stejným způsobem jako dosud.
Aby nedošlo k mýlce, velmi si Vás vážím a velmi si vážím práce, kterou jste na poli Firebirdu/Interbase udělal. Výše uvedené skutečnosti jsou jenom povzdechy nad tím, co jsem zažil při pokusu o hlubší práci s Firebirdem. -
Nezlobte se, ale pokud říkáte jeden dokument, pak si pod tím představuji jedinou knihu, případně PDF či HTML soubor. Skupinu HTML stranek třeba i zabalených do CHM nepovažuji za dokument. Proto jsem se divil, že se vám nelíbí rozdělení dokumentace FB na dokumentů, protože i skupinu PDF lze prolinkovat do jediného "dokumentu". Mimochodem i PDF umožňuje hypertextové odkazy v rámci dokumentu, a zmíněné dvě knihy toho hodně využívají. Mezi PDF a HTML tedy nemusí být až takový rozdíl, nicméně uznávám, že vytvořit HTML je jednodušší.
Nicméně Dokumentační projekt Firebirdu používá DocBook, a produkuje tedy jak PDF, tak čistě HTML verze. Bohužel knihy Firebird Reference a Using Firebird jsou ve FrameMakeru, a převést je do DocBook formátu není až taková trivialita. Základní konverze byla sice strojová, ale vyžaduje to drobné manuální korekce. Vzhledem k rozsahu je to vleklá nudná práce, kterou je jen málo kdo ochotný dělat. Jakmile ovšem bude dokončena, budete mít rázem cca 1200 stránkovou dokumentaci k Firebirdu dostupnou ke stažení či brouzdání přímo na webu projektu.
Ohledně nedostatku dokumentace a její "roztříštěnosti" se bohužel často zapomíná, že:
a) Napsat dobrou dokumentaci je zdlouhavá práce, která v případě technické dok. vyžaduje navíc jak znalost problematiky, tak i schopnost jasně a srozumitelně psát. Dobrých tvůrců *ucelené* dokumentace je tedy jako šafránu, a prakticky nikdo z nich není ochoten to dělat úplně zadarmo (ne že by se vydávání tech. knih nějak zvlášť vyplatilo, ale lepší něco než nic). Proto např. dokumentace kterou vytváří IBPhoenix jde přednostně na placené Developer CD (verze Subscription je Firebirdí verze MSDN), a je uvolněna až se spožděním.
b) Dokumentační projekt si nemůže přivlastnit práci jiných, aby mohl vytvořit jediný superhyperdokument, pořád je zde něco jako autorská práva. Proto je dokumentace poněkud "roztříštěná", a člověk musí informace dohledávat z drůzných zdrojů. To nejlepší co zatím můžeme nabídnout je nashromáždit odkazy na nejdůležitější dokumenty na jedno místo. Obecně je za toto místo uznáván web www.ibphoenix.com nebo .cz
Ano, volně dostupné dokumentace je dost, jsou tu ale dvě ale. Na to, abyste se seznámil se základními funkcemi Firebirdu vydáte několikanásobek času, než u jiných srovnatelných databází, který strávíte hledáním a dáváním si různých střípků informací dohromady.
Tenhle problém "zatím" řeší knihy tištěné či na Developer CD. Až se dokončí konverze, budou dvě základní knihy dostupné i volně na webu projektu.
A to ještě příznivě podpořeno tím, že naštěstí tu máme slušnou příručku od Borlandu k Interbase.
Ta se běžně nedá legálně sehnat, je třeba ji koupit spolu s InterBase. Volně dostupná je pouze dokumentace k IB 6.0, a to jen díky tomu, že nad tím Borland zavírá oči.
Druhé ale je, že se velmi těžko pátrá po dokumentech, které by trochu popisovaly Firebird do hloubky. Byl bych rád, kdybyste mě zejména v tomto bodě přesvědčil o opaku, a já rád vše odvolám.
Mno, zrovna některé knihy jdou překvapivě hodně do hloubky, a popisují i témata které jiné dokumenty moc neřeší (funkce optimalizátoru, struktura databáze, vnitřní mechanizmy funkce serveru apod.). Jinak na webu www.ibphoenix.com jich je celá hromada (bohužel ne nijak přehledně strukturovaná, navíc jsem si teď všiml, že na nedávnou sérii článků pro expery od Ann Harrison není odkaz jinde než v news archivu, což napravíme). To vše a mnoho dalších je součástí Firebirdího MSDN. Já vím, že dost toho je to placené, ale dostupné to je, a je to průběžně uvolňováno pro Dokumentační projekt.
Koupení knihy nic neřeší, protože zkrátka rozsah jakékoli knihy může být jenom zlomkem toho, co může být v kvalitní dokumentaci. Kniha je dobrá věc, ale neřeší vše.
To je s prominutím pěkná hloupost. Pokud chcete začít dělat např. v C#, nemusíte si přece hned kupovat MSDN, stačí *dobrá* kniha. Ani např. dokumentace k PHP nebo Pythonu neobsahuje "úplně všechno". A i kdyby obsahovala, tak tím spíš se mi vyplatí nějaká dobrá kniha, která mi jasně a přehledně podá to podstatné co potřebuji (sám mám pár knih o PHP a Pythonu, a nikdy jsem investice nelitoval). Z osobní zkušenosti vím, že taková "úplná" dokumentace je dobrá tak leda jako referenční příručka, kde rychle najdu to co hledám, ale musím nejdřív vědět co hledám. Na učení a informace které bych měl o daném tématu znát mě vždy upozornily spíš knihy.
-
Miloslav Ponkrác (neregistrovaný)Ano, vaše argumenty jsou vcelku rozumné. Já bych dodal jenom toto:
1) Napsat dobrou dokumentace chce určitě jak znalosti, tak určitý talent. Přesto si myslím, že model typu dokumentace v PHP tyto nároky podstatně snižuje. Postavíte prostě osnovu dokumentu a různí lidé mohou doplňovat různé části. Nevznikne tak sice geniální dílo, ale dílo dostatečné kvality ano. K takové dokumentaci může přispět poměrně značné množství lidí a vzniká tak jakási databanka znalostí. Takový dokument má po čase značnou hodnotu.
2) Dobrá dokumentace je schopna ušetřit obrovské množství člověkohodin práce i vlastním vývojářům produktu. Jde to dokonce tak daleko, že třeba v případě MySQL, nebo PHP máte běžně v dokumentaci budoucí plánované vlastnosti. Jinak řečeno taková dokumentace kromě toho, že je víc než aktuální slouží i vlastním vývojářům k orientaci. Je pak daleko snažší se zapojit i do vývoje projektu a i samotný projekt z toho velmi prosperuje.
Rád bych ještě vysvětlil můj názor na knihy. Problémem je, že existuje jen mizivé procento knih, které jsou pro mě přínosné. Upřímně řečeno, rezignoval jsem na knihy kromě několika málo autorů jako je třeba Jeffrey Richter. Sám jsem se naučil programovat třeba v PHP podle manuálu staženého z www.php.net a myslím si, že to umím docela dobře. Pokud jsem si listoval knihami o PHP v knihkupectví, nenašel jsem žádnou knihu, která by mi byla užitečná. Python jsem se také učil z internetové dokumentace a neměl jsem problémy. C# jsem se také učil na internetu a pozor! Z knihy od Jeffreye Richtera.
Souhlasím s tím, že když se něco učím, tak musím vědět, co hledám. Jenže zrovna třeba programovací jazyky jsou zrovna plus mínus na jedno brdo. Naučíte se novou syntaxi, pochopíte pár zvláštností nového jazyka, prolistujete si základní knihovny a pak to chce pár příkladů a praxi. Nic, k čemu bych nutně potřeboval knihu. A programovací jazyk ve skutečnosti spíš dělají knihovny, než cokoli jiného a málokterá kniha je tak rozsáhlá aby mohla být i referenční příručkou. Zrovna programovací jazyky se mi mnohem lépe učí bez knihy. -
Ad 1)
Dokumentační projekt Firebirdu takhle funguje. Bohužel používají DocBook místo Viki, což značně snižuje počet možných tvůrců dokumentace, protože mezi uživateli FB není mnoho zběhlých uživatelů DocBooku. Že na webu není vidět celá osnova je jejich rozhodnutí, protože většina stránek by zatím byla prázdná, a jenom by to komplikovalo navigaci k dokumentům, co už jsou hotové. Jak skounčí koverze IBP knih do DocBooku, bude kompletní dokumentace na webu, a bude se průběžně doplňovat a korigovat. Ad 2)
Zajímavá myšlenka. Určitě by fungovala při použití Viki, ale pochybuju, že vývojáře donutíme používat DocBook. On je vůbec problém je donutit napsat jakoukoliv dokumentaci. Jinak na dokumentaci plánovaných a vyvíjených věcí je Roadmap, dokumenty přímo u zdrojáků v CVS a Jim Starkey udělal i něco jako Viki v Netfrastructure. Co se vašeho názoru na knihy týká, já vám ho neberu, ani vás nepřemlouvám. Ale pokud svůj osobní názor prezentujete jako obecně platný fakt, tak se prostě musím ozvat. -
Miloslav Ponkrác (neregistrovaný)Děkuji za vysvětlení.
Chápu, že použití DocBooku spoustu lidí odradí. On přeci jenom Firebird je z velké části záležitost Windows a rozchodit na Windows celý fungující systém s DocBook není až tak triviální záležitost. Pokud vím, tak ani na Windows neexistuje žádný balík, který by to lidem ulehčil a nainstaloval vše potřebné. To je dost vysoká překážka přispívání do dokumentace.
Co se týká mého názoru na knihy, netvrdím, že jde o objektivní názor. Ostatně pro někoho jiného mohou být knihy klidně to pravé. Já jen při koupi většiny knih jsem neustále znovu a znovu zklamáván, ač se občas vyskytnou i knihy, které mají mé vysoké hodnocení. Zjistil jsem, že nejhorší úroveň (z mého pohledu samozřejmě) má většina knih vydávaných Microsoft Pressem. -
MaReK OlšavskýZlatý podporovatel
Pavle také si dovolím nesouhlasit, ale s Tebou :-) Podle potřeb projektů používám MySQL, PostgreSQL a FirebirdSQL. Poslední jmenovanou zejména díky kvalitnímu propojení s Borlandími vývojovými nástroji.
Dokumentace FbSQL není v nejoptimálnějším stavu, to je fakt. Pravdou je, že proti PgSQL/MySQL je tento server o mnoho pátků mladší a tudíš je to pochopitelné.
- Co mě u FbSQL chybí? (je to jen malinké zrcadlo toho, co jsem napsal na dbsvete o tom, co se mi libi na PgSQL)
- má poměrně málo typů a vytváření ekvivalentu serial je trochu \"přes ruku\"
- Nemožnost použít pro stored procedury jiný jazyk, než vestavěný PL/SQL (zde jasně vede PostgreSQL) i když srovnám-li, co uměl PL/SQL v FbSQL 1 a co umí nyní, je to teď o 200% lepší.
Líbí se mi existence Embedded verze a to je veliké plus, protože většina malých projktů nepotřebuje plnou instalaci serveru. Líbí se mi učebnice, kterou jsi napsal, byť zcela logicky nemůže pokrývat celou šíři toho, co FbSQL umí a nabízí.
btw: Doufám, že nevadí, že jsem na tomto serveru zvolil tykání :-)
-
S novými datovými typy nemohu sloužit. Tohle se plánuje až po sloučení Firebirdu a Vulcanem, tedy až po FB 3.0, kdy pro to budou vhodnější podmínky. Nicméně uložené procedury a spouště v jiných jazycích už jsou dostupné v rámci projektu Fyracle (Oracle mode pro Firebird). V poslední verzi Fyracle 0.8.9 je možné na serveru používat vedle PL/SQL Oracle i jazyk Java.
-
Datovy typ serial se Vam bude u PgSQL libit do doby, kdyz na vlastni kuzi poznate, ze datovy typ serial a default nextval('seq') je trochu v praxi neco jineho... (ano, oboji vede na vytvoreni sequence, bohuzel nastavit hodnoty sequence na pozadovane, pokud nevyhovuji defaultni je opravdu porod).
PS: Mluvim o PgSQL 8.0.X, nikoli starsich verzich.
-
marx (neregistrovaný)Pokúsim sa zhrnúť to, čo si pamätám bez hľadania zdrojákov. Viac info cez mail (marx@linux.sk).
Takže pracoval som s veľkou databázou, ktorá bola stromovo orientovaná a listami boli súbory uložené v BLOBoch. Rýchlosť práce s BLOBmi klesala úmerne s veľkosťou DB a niektoré funkcie mi vyslovene chýbali (FB spred cca pár mesiacov). Tá rýchlosť bola miestami pod hlboko pod tým, čo by som očakával, ale nakoniec sa to dá zniesť.
Problém so žraním pamäte DB servera bol vcelku jednoduchý. Po uzavretí tranzakcie sa miesto v pamäti neuvolnilo (prip. znovu nepoužilo) a bolo potrebné spraviť disconnect/connect v dobe, keď nebola otvorená žiadna tranzakcia. V mojom prípade som sa o to snažil po 10+ vykonaných operáciach. Toto inžinierske riešenie funguje a tak ma to prestalo trápiť. Samozrejme, že je možné, že som pozabudol na uvoľnenie niečoho (aj keď si myslím, že skôr nie), ale na druhej strane väčšina mojich výsledkov mala výsledky v jednotkách záznamov, takže by som skôr povedal, že to bolo niečo čo som vidieť ani nemal. Ale ako som písal stačí sa znovu pripojiť a pamäť je v pohode.
Skúsenosti s JDBC, príp. inými high-level API nemám. -
Pokud jste používal přímo API Firebirdu, pak je problem jasný: neuvolnil jste statement handle svých příkazů. Ukončení transakce totiž statement handle (i.e. SQL příkazy) neuvolňuje, protože se nejedná o resource transakce, ale spojení k databázi (lze je použít ve více transakcích). Firebird v tomto směru zkrátka funguje jinak než jiné databáze. Toto rozhodně není memory leak.
-
marx (neregistrovaný)Tak som sa na to schválne pozrel :) Dokumentáciu k API InterBase som mal preštudované myslím dosť slušne a poctivo som uvoľnoval, čo šlo. Pokiaľ uvoľňovaním statement handle myslíte:
isc_dsql_free_statement(status_vector, &stmt, DSQL_close);
tak vedzte, že toto som robil. Skutočne si myslím, že to bude memory leak. To samozrejme neznamená, že sa vyskytuje všade. Len ja mám na netradičné bugy v programoch jednoducho šťastie. -
anonymníTak pod to se můžu podepsat. Když jsem si stěžoval na naprostý nedostatek dokumentace k Firebirdu, bylo mi nadáváno. Jediná trochu kompletnější dokumentace je k Interbase a ta samozřejmě ani nemůže odrážet poslední vývoj Firebirdu. Jinak vám zbývá pár střípků rozházených tu tam, tu onde, ale nic kompletního se nedozvíte. Pak musíte s každou ptákovinou otravovat přímo vývojáře Firebirdu a často si nejste jistí, jestli to, co vám provádí zrovna databáze je bug, nebo feature, nebo něco jiného. Pro mě samotného to bylo důvodem k zamítnutí Firebirdu.
-
pkm (neregistrovaný)Občas pracuji s IB. FB je mezi free databázema, co se fíčur týče, snad nejnamáklejší ze všech. Rychlost taky evidentně fajn. Ale je to takové "málo zdokumentované" a "málo prověřené" řešení. Když jsem se snažil připojit FB k Monu, narazil jsem na divné problémy s právy (asi chyba Mona, ale stejně) a nebyl jsem schopen k tomu zjistit pořádné informace. No a ty memory-leaky jsme několikrát řešili v práci, no tam má zase díl viny svéhlavý JDBC driver.
Musím uznat, že výkonové charakteristiky mi vyrazily dech, až mám pocit, že je někde chyba. Postgres je pomalá sračka, když vidí složitější dotaz, vykašle se na optimalizaci a klidně sjede tabulku s milionem záznamů sekvenčně, fuj. -
Miloslav Ponkrác (neregistrovaný)Já osobně bych se taky Firebird příliš neodvážil nasadit. Právě díky jeho "tajemnosti". Jasně, že není problém používat Firebird základním způsobem, ale raději pracuji s databázemi, o kterých vím něco víc.
Problém je, že jakmile nastane skutečný problém, často nevíte, co je vlastnost databáze, protože podrobnější informace často chybí. A dokud projekt Firebird nezaloží jeden jediný dokument, do kterého se budou doplňovat informace o Firebirdu, tak situace nebude lepší.
Co se týká výkonových charakteristik Firebirdu, tak na místě autora bych se první ptal, kde je chyba. Netvrdím, že Firebird nemůže být pekelně rychlý, ale ty výsledky jsou opravdu podezřelé a určitě bych se pokusil dopídit, proč jsou takové. Moc jim nevěřím, abych se přiznal. -
Mistře, nestrašte nám tady lidi nějakou "tajemnou" databází. Firebird je tu pod tím či oním názvem už přes dvacet let. K dispozici je dost knih, dokumentů, školení, komponent, aplikací, veřejná databáze chyb, lidí v konferencích s dloholetou zkušeností i přímo vývojářů kterých se kdokoliv může na cokoliv zeptat, nebo jen tiše sledovat cvrkot, a konečně jsou tu kompletní zdrojáky volně k stažení pro kohokoliv. Firebird tedy rozhodně není žádná "tajemná" databáze pro nikoho, kdo se o ní chce něco dozvědět, nebo vyřešit konkrétní problém.
-
Miloslav Ponkrác (neregistrovaný)Myslím, že vám to tak pane Císaři připadá z pohledu člověka, který tomu věnuje spousty času. Moje zkušenosti jsou takové, že k získání stejného množství informací ve srovnání oproti jiným databázím musí člověk u Firebirdu věnovat několikanásobek úsilí, času, případně peněz. Jasně, když za tím tvrdě půjdete a nebudete hledět nalevo, ani napravo, tak nějaké informace nakonec získáte, ale to platí o všem, nejenom u Firebirdu.
-
benzin (neregistrovaný)To je hodne subektivni pohled. Take jiste zalezi na tom z jakeho prostredi prichazite (Unix X Windows, C/C++ X Delphi X Java). Ja osobne jsem odchovancem Delphi vyvoj ve FireBirdovi mi nedela sebemensi problemy, kdezto MySQL umi pouzivat jenom na zakladni bazi. Nejsem zvykli pouzivat primo zakladni API pokud to neni nutne, radeji vyuziji komponentu nebo Bean.
Z teto pozice musim rict, ze FireBird je na tom lepe nez MySQL a jeste vic nez PostgrSQL.
Verim, ze pri pouziti Cecka muzou nektere veci cinit jiste problemy, ale nesnazte se to zobecnovat. -
benzin (neregistrovaný)To je hodne subektivni pohled. Take jiste zalezi na tom z jakeho prostredi prichazite (Unix X Windows, C/C++ X Delphi X Java). Ja osobne jsem odchovancem Delphi vyvoj ve FireBirdovi mi nedela sebemensi problemy, kdezto MySQL umi pouzivat jenom na zakladni bazi (a to s nim delam daleko dele). Velmi problematicky se mi hleda co vlastne ta ktera verze MySQL umi a jak jsou ty ktere veci implementovany. FK se mi nepodarilo vytvorit doted. Chyba je jiste mezi klavesnici a zidli, protoze proste neumim v dokumentaci MySQL hledat, ale stejne to bude u Vas a FireBirdu.
Nejsem zvykli pouzivat primo zakladni API pokud to neni nutne, radeji vyuziji komponentu nebo Bean. Z teto pozice musim rict, ze FireBird je na tom lepe nez MySQL a jeste vic nez PostgrSQL.
Verim, ze pri pouziti Cecka muzou nektere veci cinit jiste problemy, ale nesnazte se to zobecnovat. -
Miloslav Ponkrác (neregistrovaný)Výborná myšlenka, doufám, že to myslíte ironicky.
MySQL je rozhodně výborně zdokumentovaná databáze a tvrdím, že jsem ještě neviděl otázku ohledně MySQL ať už položenou tady, nebo na jakémkoli jiném diskusním fóru, na kterou byste nenašel odpověď v základním manuálu MySQL. Ještě se mi někdy nestalo, že bych se potřeboval ohledně MySQL někdy někde někoho na něco ptát. A to jsem dělal s MySQL lecjaké skopičiny a potřeboval jsem znát informace hodně do hloubky. To u jakékoli jiné databáze jsem se snadno dostával do stavu, kdy jsem prostě musel shánět informace i jinde. A upřímně řečeno, Firebird je z tohoto hlediska, tedy z hlediska dokumentace, to nejhorší co jsem zažil. Proto mluvím o "tajemnosti" Firebirdu.
MySQL je rozhodně i dobře prověřená databáze. Jako databázový server je MySQL nasazena poměrně ve značném počtu kusů a k prověření samozřejmě přispívá i to, že jí každý php trouba použije pro své webové stránky. Já sám osobně ji za prověřenou a spolehlivou považuji, protože po řadě let zkušeností mě z tohoto ohledu nikdy opravdu nezklamala.
Jiná věc samozřejmě jsou schopnosti MySQL, ty jsou i v MySQL 5.0 dost pozadu za schopnostmi mnoha jiných databází. Když k tomu připočtu i to, že za komerční použití MySQL se musí platit, a IMHO podle mě příliš vysokou částku v poměru ke skutečným schopnostem MySQL, tak mi z toho vychází, že preferuji spíše jiné databáze. -
Ludvik Roubicek (neregistrovaný)Firebird je v Linuxu pomerne stabilni, ale pomala databaze. Nedostatek dokumentace me stval take, ale dalo se to vetsinou prekonat. Jediny vaznejsi problem, ktery jsem mel, se tykal presnosti cisel s pohyblivou radovou carkou v jednom z dialektu SQL. Doloval jsem data a vysledkem bylo, ze 0 > 0 (kvuli nepresnosti v x. radu). Kdyz jsem zmenil podminky, sice to fungovalo, ale pooooomaaaaaluuuuu.
Zpracovani nekolika tisic faktur pro vytvoreni jejich seznamu (JOIN nekolika tabulek) trvalo v nasazenem ucetnim programu desitky sekund az jednotky minut. A to pri pripojenych pouze 5ti uzivatelich...
MySQL je vyrazne rychlejsi - testovano v podstate na stejnych datech, pouze v jinem ucelu vyslednych dat. SELECT v MySQL je take intuitivnejsi, zejmena pri seskupovani dat (GROUP BY).
Testovano v praxi na P4HT 3GHz, 1GB RAM, 2xIDE 120 GB/8MB sw. mirror. Mandrake nabiha v teto konfiguraci do konzole behem ani ne 20s od zapnuti pocitace :)
Osobne bych na produkcnim serveru MySQL za Firebird nevymenil. Alespon dokud bych se obesel bez ulozenych procedur atd.
Pokud autor nenasel nastroj pro administraci Firebirdu, bud neumi anglicky nebo se na web Firebirdu ani nepodival. Perfektni, lec jeste nedodelany je FlameRobin.
BTW: testovat databazi ve Windows a jeste ke vsemu na 20GB pomalem disku, je amaterismus. Zajiste takto pobezi vetsina databazi, ze? A priste co? Budou se testovat databaze pod VMware??? Prosil bych seriozni srovnani, tj. na stroji, ktery se pro provoz databaze hodi vice (nemusi jit nutne o xeon), v systemu, ktery se pro server hodi vice (Linux v konzoli, MS Win SERVER, Unix), s testy, ktere alespon priblizne simuluji bezne nasazeni, tj. vkladani, nacitani, odstranovani v nahodnem poradi, spojovani tabulek, seskupovani dat...
Clanek nema valnou informacni hodnotu, je pouze projevem nadseni autora z objeveni Firebirdu. -
misch (neregistrovaný)testovat databazi ve Windows a jeste ke vsemu na 20GB pomalem disku, je amaterismus
Nerozumím téhle poznámce. Smyslem testu bylo myslím porovnat databáze mezi sebou, a ne vytářet nějaké ABSOLUTNÍ benchmarky. Není jedno, jestli databáze na "20 GB pomalém disku" vrátí výsledek za 10 vteřin (přičemž na lepším serveru by ho vrátila za 2 vteřiny), když měl autor v úmyslu pouze porovnat výsledky různých databází a SELECTů mezi sebou?
-
Ludvik Roubicek (neregistrovaný)Jednoduse a strucne: vetsina databazi, u nichz zalezi na vykonu, bezi na unixovych, linuxovych a jinych serverovych systemech. Nehlede na to, ze Firebird pod Linuxem muze bezet jako klasicky server nebo super server (verze CS, SS). To ma docela podstatny vliv na vysledne chovani. Zrovna tak bude databazovy server behat s nejvetsi pravdepodobnosti na procesorech s hyper threadingem, ne-li na viceprocesorovem stroji - zase: jak to bude pri pouziti CS a SS?
Takze jeste jednou: jestli pobezi rychleji v nejakych desktopovych Windows ta ci ona databaze, je vcelku jedno.
Pokud budu porovnavat auta, take s nimi nepojedu 50m, ale nekolik kilometru. A take s nimi projedu nejakou tu zatacku, abych vedel, jak se chovaji, a urcite nepojedu 20 km/h a uz vubec ne na dalnici... -
Jan Sunavec (neregistrovaný)Co sa tyka benchmarkou a hardwaru je to dost problem. Testoval som to na slabsom stroji lebo tam viac vyniknu rozdiely medzi platformami. Taketo testy sa daju robit na X hardwarovych konfiguraciach. Jedine co mal test vypovedat, je ze na stroji X, bezia databazi takto..
Co sa tyka nadsenia z Firebirdu, som skor zastanca PostgreSQL, MYSQL je sice rychla, ale moznosti su dost slabe.
Dokumentacia Firebirdu je fakt dost zla, ako produkcnu databazu by som to urcite nenasadzoval ani v krajnom pripade. Ten flameRobin som vyskusal ale ako ste sami povedaly, je to nedokoncene.. -
Ludvik Roubicek (neregistrovaný)Ja vim, ze to neni jednoduche, ale pro zvyrazneni rozdilu bych pouzil vetsi objem dat. Spise bych to testoval pod Linuxem nebo pod Unixem, popr. jeste pod serverovymi Windows. Proste v nejakem realnem prostredi, s realnou zatezi a realnym objemem dat. Ony se pak jednotlive databaze mohou chovat jinak nez ve vasem pripade. Dtto hardware - testoval bych to alespon na procesoru s HT, protoze nektera databaze ho umi vyuzit lepe, nektera hure a pak to velmi ovlivni porovnavane vysledky. Takze v podobe, jak to bylo provedeno, je toto srovnani pro me nepouzitelne. Zajimave ano, pouzitelne ne.
Ad FlameRoobin - je sice jeste nedodelany, ale pouzivam ho uz od nejake alpha verze (nepamatuji si presne, ale byla to urcite verze < 0.2) a funguje, pouze jsou postupne doplnovany dalsi funkce. Nedodelany, ale velmi dobre pouzitelny.
Jako vzdy - pri vyberu databaze je samozrejme potreba vzit v uvahu co umi, co podporuje, jak je v danem pripade rychla, proste k cemu se hodi a k cemu ne. Ale jako podklady k rozhodovani potrebuji jine informace. -
Nesouhlasim s tvrzenim o BLOBech a memory-leacich. Pouzivame v praci FB 1.5.2 uz od doby jeho relesu (asi rok a pul) a ma samozrejmne sve mouchy, ale jinak bezi perfektne. Pristupujeme na ni pres zakladni C-api a k zadnym memory leakum nedochazi ani k prebytecnemu zrani pameti nedochazi. A to podotykam, ze vyuzivame 95% ze vsech funkci, ktere jsou v API k dispozici (jedine co nepouzivame jsou commit_retaining, ci tak nejak, a souvisejici savepointy (zasveceni urcite vi, o co jde)).
Prace s BLOBy je sice ponekud komplikovanejsi, ale zato je efektivni a setrna k prenosovemu pasmu pri komunikaci po siti apod.
Co se tyce spotreby pameti. Ono se po commitnuti transakce musi take uvolnit z pameti statement handler a popr. alokovane XSQLDA struktury (zasveceni opet vi, o cem je rec).
PS: Pokud pouzivate vlozene procedury (PSQL) tak je vhodne skutecne pristupovat primo na rakdy (resp. na jejich aktualni verzi) pres RDB$DB_KEY identifikator, ktery se vramci jedne aktualni transakce nemeni. Pak je skutecne FB 1.5.2 rychly jako blesk ... -
Já mám jen ty nejlepší. Oslovila mě knížka pana Císaře, od té doby naprosto v pohodě. Zkušenosti mám tedy jen s TYPE4 ovladačema (nebo jak se to ... ty co se připojují přes inet sockety).
Výhodou je hw nenáročnost Firebirdu. Zajímalo by mě však větší nasazení Java-Firebird (například nějaký web), moje pokusy jestě nic nedokazují. -
jozef (neregistrovaný)Potvrdzujem ze JDBC je v pohode. Bohuzial web nemozem uviest lebo sa jedna o intranet. Aplikacia bola vyvijana na Windows (Tomcat, Struts, iBatis DB Layer), u zakaznika je Linux a PostgreSQL. Nase skusenosti su jednoznacne v prospech Firebirdu, omnoho lepsi vykon. PostgreSQL je nutne pravidelne "vakuovat" lebo vykon zdochyna (chcipa ?). BLOBy nepouzivame, takze nemozem potvrdit ani vyvratit problemy z tejto diskusie. Produkcna PostgreSQL databaza stale narasta lebo sa v nej ukladaju data z vyroby, jej aktualnu velkost mozem zistit ak by bol zaujem.
-
Marian (neregistrovaný)Pokiaľ ide o Firebird a JDBC, naposledy, keď som sa tomu venoval (Firebird 1.5.1 a s ním súvisiaci release JDBC drivera) bolo takmer nemožné sa dopátrať informácie, či JDBC driver je thread-safe alebo nie. Druhým vážnym nedostatkom v tom čase bola absencia Linuxovej embedded verzie Firebirdu.
-
Dakujem autorovi za clanok. Sice pouzite testy vazne neodpovedaju realnej prevadzke a aj platforma Windows pre mna nie je zaujimava, aspon mi autor nasadil do hlavy chrobaka ohladom databazy Firebird. Vzdy beriem tieto testy ako nerealne a preto vysledky z nich jednoznacne ignorujem, ale urcite su dobre aspon na to, aby ma prinutili pohnut svojim tucnym zadkom a skusit nieco nove. Takto som napriklad pred casom presiel na ReiserFS a tomu testu, ktory ma s nim oboznamil som neuveritelne vdacny. -
P.L. (neregistrovaný)Bez vacuum analyze postgres opravdu nefunguje dobre.
Pokud se nepletu, tak se autovacuum spousti napozadi v zavislosi na poctu zmen v tabulce ... ale s velkou pravdepodobnosti mu to nejakou dobu trva (pouzivam postgres 7.4, u 8.1 to ale bude podobne)
Docela by bylo zajimave videt vystup z explain analyze pro prislusny 'pomaly' dotaz. Pomerne snadno se pak da najit, v cem je chyba. -
Jirka (neregistrovaný)Asi bych to upresnil...je problem najit dobry nastroj zadarmo.
Nastroju zadarmo je hodne, ale nejsou prilis zdarile, tech placenych uz je mene, zato jsou vytecne, napriklad:
http://www.ibmanager.com/
http://www.ibexpert.com/ -
Pokdu vám nevadí windows, tak skvělý nástroj zadarmo je IBExpert Personal. Má sice ořezané některé pokročilé funkce, ale na běžnou práci toho umí vic než dost.
-
Buthrakaur (neregistrovaný)pro windows je docela zdarilej freeware nastroj IBQuery (http://www.mitec.cz/ibtools.htm)...
-
Ondrej Jombík (neregistrovaný)SQLite je velmi sikovna a uzitocna databaza. Samozrejme hodi sa len na urcite veci. Priklad: predstavte si, ze mate nejaku aplikaciu, ktoru pravidelne distribuujete svojim klientom. Ta aplikacia nieco pocita, konieckoncov, to robi vacsina programov ;-)
Ked navrhnete dostatocne univerzalne API a priclenite SQLite databazu, mozete releasnut len jednu verziu kodu a klientom uz len dodavat databazove updaty -- nove tabulky, ciselniky, atd. Rovnako tak to funguje aj pre update pripadnych algoritmov. Akou technologiou budu algoritmy implementovane a vykonavane uz prenechavam na vlastnu kreativitu; PHP, Perl, Python, Pike, Ruby, Lua, ... skratka moznosti je velmi vela. -
Michal Kára (neregistrovaný)Souhlasim s predreciky, ze zvolena metodika je dost nanic a vysledky maji zhruba stejnou vypovidaci hodnotu jako kdyby byly z vystupu nahodneho generatoru...
Udelat DOBRE porovnani neni vubec zadna legrace. Uplne nejjednodussi test bych si predstavoval tak, ze bych mel treba jednu tabulku (samozrejme zaindexovanou - pokud se musi casto delat scan tabulky, je to chyba aplikace). Generoval bych pseudonahodne N dotazu za sekundu, z cehoz treba 10% by byly insert, 70% update a 10% delete. Ty dotazy by bylo nutno pridelovat threadum testu, aby se pri zatizeni databaze nesnizil pocet dotazu za sekundu. Zacinalo by se z predem definovaneho stavu, udelalo by se treba 10 tisic dotazu (pro natazeni indexu do caches atp.) a pak by se teprv zacalo merit.
Pocet dotazu za sekundu by se postupne zvysoval a merila by se doba odezvy pri postupne se zvysujicim N.
Takze asi tak. Ale tohle rozhodne neni test na jedno odpoledne a stejne meri jen urcity rezim prace databaze - pro jine rezimy by jeho vypovidaci hodnota byla mala. -
Michal Kára (neregistrovaný)Nelze pochopitelne udelat test, ktery by dal vysledek "databaze A je obecne lepsi nez databaze B". Vzdycky udelate test, ktery ma nejake parametry - zpusob pousteni dotazu (konstantni pocet dotazu za sekundu, nebo konstantni pocet threadu), pomery, strukturu DB, velikosti tabulek atp. Pro takovyto konkretni test dostanete odpoved "databaze A je o tolik a tolik lepsi nez databaze B". Kdyz se pak budete v praxi rozhodovat, kterou databazi pouzit, tak musite mit test, ktery se vasi realne situaci co nejvice blizi.
Co chci rict je, ze test pouzity ve clanku neni moc realisticky ve smyslu ze zrejme existuje velmi malo praktickych aplikaci, kterym by byl podobny. To co jsem popsal ja uz je IMHO podobne mnohem vice aplikacim. -
anonymníPokud jde o MySQL, je třeba použít tabulky typu InnoDB. Ty kromě toho že mají vyšší výkon podporují na rozdíl od defaultního MyISAM i zmiňované cizí klíče (foreign key). No a nebylo by od věci proměřit i MySQL 5.0, když už je teď final (a v době testů bylo ve fázi posledních příprav na final, podobně jako PostgreSQL 8.1). Bez InnoDB tohle testování nevypovídá o plných schopnostech MySQL - to je asi jako kdybyste měřili maximální rychlost auta a nezařadili víc než dvojku...
-
Miloslav Ponkrác (neregistrovaný)Já se přiznám rovnou bez obalu, že jsem netestoval elementární akce typu rychlost INSERTu. Prostě jsem u několika databází různých velikostí a různě složité datové struktury pokusně zkusil switchnout tabulky z MyISAM na InnoDB. Výkonnostní nárůst mě opravdu překvapil. Co mě překvapilo ještě více byl fakt, že po přečtení několika stránek v manuálu MySQL ohledně InnoDb a vyladění konfiguračních parametrů MySQL plus některé drobné změny ve struktuře databáze znamenaly další výrazné urychlení práce s tabulkami InnoDb oproti MyISAM.
Přikládám to tomu, že InnoDB je mnohem lépe vymyšleno a pokud vím, tak InnoDB není dílem firmy, která programuje MySQL. Mám dokonce dojem, že společnost, která vyvíjela InnoDB koupil teď někdy Oracle a bude pokračovat ve vývoji on. -
no je pravda, ze jsem pouzival autocommit, kdyz jsem si s tim chvili hral, tak jsem se dostal pod myisam docela rychle, takze asi mate pravdu (cimz vznika otazka smyslu existence myisam)
ano, innobase byla koupena Oraclem (viz tiskova zprava: http://www.oracle.com/corporate/press/2005_oct/inno.html ) -- predpokladam, ze mysql maji dostatecne kvalitni smlouvu, aby v pripade neochoty oraclu pokracovat mohli udelat vlastni fork -
Meesha (neregistrovaný)MyISAM je rychlejsi v pripade, ze se z tabulky prevazne selectuje. InnoDB (krome toho ze podporuje FOREIGN KEY pro zavedeni relaci) je rychlejsi u tabulek, do kterych se prevazne insertuje a updatuje v nich (protoze nezamyka celou tabulku, ale jen aktualni radek). Prakticky jsem to vyzkousel u sebe a pokud jsou tabulky typu MyISAM, web lita rychleji a zatez serveru je pres cely dan stabilnich cca 10%. Zmenil jsem tabulky na InnoDB a web je znatelne pomalejsi a zatez serveru je 20%. Poznal jsem to hlavne v tabulce, kde je 1 200 000 zaznamu, co zaznam jedno bezne slovo do 10ti znaku. Nad touto tabulkou se provadi select name='slovo' a potom group by (polozka_id). Toto bylo z MyISAM tabulky hotove za 0.1 vteriny a tedka s InnoDB ten stejny dotaz, jen jiny typ tabulky trva 1.5vteriny. Jeste budu testovat Firebird, jak si s timto poradi.
-
Petr Bravenec (neregistrovaný)Nechci nijak hodnotit článek - neznám ani MySQL ani Firebird.
V databázi PostgreSQL mám hrubě přes deset miliónů záznamů. Pro databázi mám vyhrazených 1.5 GB RAM. Největší tabulku (zhruba 9 mil. záznamů) procházím sekvenčně nějakých dvacet vteřin, občas (jednou za měsíc) potřebuju přepočítat nad tabulkou nějaké statistiky, pak mašinka chrastí s disky několik minut. V reálném provozu je ale práce s těmito daty řádově v milisekundách. Takto rozsáhlý objem dat mě nutí psát aplikace jinak - vytvářet pomocné tabuky a krmit je přes triggery. Databáze je složitější o pomocné tabulky a pár funkcí a triggerů, aplikace je napsaná trochu nelogicky (data sypu to jedné tabulky, ale statistiky tahám odjinud), ale v reálném provozu díky tomu položím na lopatky kteroukoli nejrychlejší databázi bez těchto možností. Rychlost databáze pro mne NENÍ podstatná, v objemu miliónů záznamů bude každý databázový stroj pomalý. Podstatnější je, jestli databáze má dostatek prostředků pro vytváření "zkratek" a jestli dovede udržet tyto "zkratky" v konzistentním stavu. -
Pedro (neregistrovaný)K tomuto nazoru sa ciastocne pridavam. ciastocne preto, lebo pri velkych objemoch dat (nielen poctom zazanmov, ale aj velkostou dat) a netrivialnych manipulaciach s datami je vyladeny postgres asi stale najrychlejsi. Tento clanok by bol fajn, keby autor na zaciatku uviedol, ze testuje vhodnost pouzitia DB na webovy chat s jednou - dvoma tabulkami.
-
Boss (neregistrovaný)Ja mam v postgresql 8 asi 5GB dat a nemuzu si ji vynachvalit. Ja bych jeste podotknul, ze neni od veci obcas nechat zanalyzovat vsechny tabulky. Planer ma pak statisticke informace o jejich velikosti a dokaze tak lepe optimalizovat dotaz. Musim portvrdit, ze pri vyberu DB u me hrali roli predevsim vlastnosti DB.
-
podlesh (neregistrovaný)Kromě jiných nedostatků tam chybí sledování vytížení procesoru. Konkrétně to byl náš důvod proč jsme museli přejít z Postgresql na MySQL - rychlostně bylo všechno v pořádku, dokud měl vlastní stroj. Jenomže když to mělo být všechno na jednom stroji (reálné nasazení), tak se ukázalo že žere 30-50% výkonu a to v tomto případě dost vadilo (aplikace ho sama dost potřebovala). Jenomže už je to pár let, tak nevím zda se to změnilo k lepšímu...
-
anonymníPripajam sa k ovaciam. Tiez som sa dlho nepobavil. Tento test by som skor hodnotil ako test s nazvom "Ake databazove servre pozname zadarmo" .. ale urcite nie na porovnavanie vykonu. Taketo t.z. benchmarky su velmi zavadzajuce a nepresne a dovolim si povedat, dost od veci. Ale snaha sa vzdy ceni :).. Ale tu snahu by som skor smeroval niekde tam, kde to bude mat aspon opodstatnenie.
-
MySQL je licencováno duálně, přičemž jedna z licencí je GPL. Pokud MySQL používám pod GPL a v souladu s ní, už mě nic jiného nemusí zajímat a také nezajímá. Druhá licence mě zajímá pouze pokud MySQL chci používat v rozporu s GPL. Pokud kdokoli tvrdí cokoliv jiného, je to jeho věc a mě to nemusí zajímat a také nezajímá. A to včetně MySQL AB, ti dokonce mohou v rámci svých vlastních obchodních záměrů mohou klidně i lhát a já jim to nehodlám zazlívat. Vaši motivaci však nechápu. Takže si to ještě jednou nechte pěkně projít hlavou a pak sem piště podobné bláboly.
-
Na podobné "výlevy" obvykle neodpovídám, ale mystifikujete tady, a to se mi nelíbí. Duální licencování není nic špatného, nic v rozporu s GNU GPL.
MySQL prostě nemůžete použít v closed-source projektech, které nejsou webové (resp. které nejsou v souladu s tím, co píše MySQL AB). Nemůžete s ní dělat byznys, to je vše. Lidi to často ani neví. -
No teď jsem si ty příspěvky znovu pozorně přečetl a musím se omluvit. Ty formulace ve tvém i předchozím příspěvku jsou sice citově zabarvené, ale pravdivé. MySQL opravdu nelze použít všude zadarmo narozdíl od BSD licence PosgreSQL. Nicméně ji lze použít zadarmo i v komerčních projektech a nejen "na webu". Jestli někomu vadí "virovost" GNU GPL, tak opravdu produkt pod GNU GPL není pro něj, ale musí se poohlédnout po jiné licenci a i to mu MySQL umožní akorát už to není zadarmo.
-
A vše se vyřešilo. Já si uvědomuji vážnost a důležitost GNU GPL, ale nechápu přístup firmy, která ji tak trochu "zneužívá". Sama chce vydělávat, ale ostatním to svým způsobem ztěžuje. Asi jsem měl slova volit tak, aby to neznělo tak v "neprospěch" GNU GPL. Licence jako taková pochopitelně není virus, jen je orientovaná spíše na obranu komunitního způsobu vývoje. MySQL to převrací, ale DB je to fajnová. Kdyby byl tehdy Firebird, asi bych svůj systém vytvořil na něm...
-
Neřekl bych zneužívá. Vůbec ničeho nezneužívá. Prostě MySQL AB něco vytvořila a může si s tím dělat co chce. To že to ještě ke všemu dá k dispozici pod GPL je její obrovské plus. To, že to pokytuje i těm, kteří nemohou (spíš neumějí) vyhovět GPL, je její byznys. V tom není žádné zneužívání. Naopak já v příspěvku uvádím příklad jak se toho dá snadno zneužít. Stačí si vzít zdrojáky mysql řádkového klienta a popsaným postupem můžete GPL snadno zneužít a nikdo vám v tom nemůže zabránit. Stačí ještě vyhovět některým nuancím 2. hlavy GNU GPL týkající se distribuce a zneužijete GPL levou zadní.
-
Mimochodem vyloženě lživý je například výrok: "Nemůžete s ní dělat byznys, to je vše." viz. Tento váš příspěvek. Dokážu si třeba představit model vytvoření GPL metaserveru nad GPL knihovnami MySQL a potom k němu napsat úplně closed source klienta. Prostě oddělit GPL část od svého produkty a s drobnou ztrátou výkonu (která při vhodně navrženém rozhraní, třeba unixovou pipe nemusí být vůbec bolestivý) a mám komerci jak bič a MySQL AB se může se jít klouzat a nedostane ani korunu. Budou to oddělené procesy a ani RMS nemůže říct ani popel.
-
Já jsem tušil, že to mám víc zpřesnit :-)
Podle licence _nemůžete_ zdarma používat MySQL, pokud je těsně svázaná s aplikací. Musí být zajištěno, že aplikace bude fungovat i na jiných DB strojích. Takhle to bylo v dobách verze 3.X, kdy jsem si licenci pečlivě nastudoval a nepředpokládám, že by tomu bylo jinak. Nepomůže tomu ani tisíc vložených vrstev - mají to ošetřeno.
Stavět moji údajnou "lež" na jakémsi pochybném "hacku" se mi nezdá příliš vhodné. A vůbec, nechme už toho... -
Miloslav Ponkrác (neregistrovaný)Tady by stačilo zhruba dvacet minut věnovat přečtení manuálu MySQL a snadno a rychle tam najdete jak tyto věci nastavit. Právě nastavení velikosti paměti několika bufferů, které si MySQL drží, a jejichž velikost můžete v e velkém rozmezí škálovat je docela dobrá věc. MySQL tak nějak předpokládá, že si těch prá parametrů nastavíte podle toho, co potřebujete. Pokud použijete prefabrikované řešení typu my-small.cnf, tak se nesmíte divit.
Právě možnost tyto informace rychle najít a použít, kterou mám u MySQL mi hrozně chybí u Firebirdu, kde v podstatě nemám možnost podobné údaje vůbec najít. -
Miloslav Ponkrác (neregistrovaný)Jestli chcete optimalizovat MySQL na šetrnost k prostředkům počítače, nepoužívejte InnoDB. InnoDB je trochu kanón na vrabce a je dělaná na výkon a rozhodně prostředky počítače nešetří. Pokud vám záleží na každém bajtu, který databáze zabere, postavte to na MyISAM a pohrajte si s hodnotami bufferů.
Mám takhle na stařičkém notebooku (Pentium 166 MHz, 32 MB paměti, Windows 95) databázi nemovitostí v MySQL s několika stovkami tisíc záznamů a asi třiceti tabulkami a databázový server MySQL zabírá v paměti asi 1,5 MB. Práce s databází je velice rychlá.
Je třeba si také uvědomit určení databáze. Pokud potřebujete kvalitní databázi se všemi vymožnostmi relačních databází, myslím si, že MySQL není dobrá volba. Pro mě je MySQL takové inteligentnější pokračování DBF databází. -
Tady jste mě asi nepochopil. To, že potřebuji minimalizovat nároky na pamět nutně neznamená, že se nejedná o mission-critical aplikaci. Je to klíčový informační systém firmy, který nelze na MySQL provozovat na jiných tabulkách, než typu InnoDB.
MySQL určitě nebyla dobrá volba, ale jak se aplikace rozrůstala, tak se stalo prakticky nemožné migrovat jinam. Používám příliš proprietárních věcí a když bylo potřeba použít vlastnosti dostupné na InnoDB, tak se to prostě přeplo. Proč taky ne, když to MySQL nabízí. Jinak jsem s provozem spokojen, po dobu 2 let žádný výpadek, zálohy probíhají korektně od prvotního nastavení. Jen té paměti si to žere... -
Miloslav Ponkrác (neregistrovaný)Aha, rozumím. To je potom těžké, protože InnoDb je opravdu žravé. I když i to se dá částečně vyladit. Chce to pohrát si s konfiguračními volbami pro InnoDb, je jich slušná řádka. Ale samotná MySQL počítá s tím, že pro ní bude vyhrazeno asi 80% paměti stroje, na to byla navrhovaná. Dá se samozřejmě vyladit na daleko menší spotřebu, ale chce to si chvíli hrát s konfigurací.
-
Miloslav Ponkrác (neregistrovaný)To máte naprostou pravdu. Taky mi někdy připadá, že InnoDb je v MySQL v podstatě cizí element.
S laděním MySQL jsem si už v životě docela dost užil. Asi největší zkušeností pro mě bylo, když jsem administroval MySQL pro dnes už neexistující DC hub - CZ PRO. Nad MySQL běželo několik náročných klientů a jedním z bych byl verlihub, ke kterému bylo běžně připojeno kolem 6000 uživatelů. Jak verlihub, tak i MySQL byli paměťoužrouti a bylo potřeba u MySQL nechat vysoký výkon za rozumné spotřeby paměti. Co mě ale velice překvapilo, že mě bohatě stačily k ladění informace z manuálu k MySQL.
Tedy k vašemu problému. Jak se ladí MySQL? Nejdříve si musíte uvědomit, jaké SQL oprerace se na něm skutečně provádějí, a které z nich jsou kritické. To asi nejvíce víte vy sám, co vám tam běhá.
1) Nejdříve je dobré nastavit obecné velikosti bufferů v konfiguraci MySQL serveru, které nezávisí na typu tabulek. Informace o tom v manuálu jsou, ale jsou bohužel rozházeny na různých místech. Klíčové je vhodně nastavit parametry key_buffer_size, join_buffer_size a sort_buffer_size. Jejich význam si snadno najdete v manuálu pomocí fulltextového vyhledávání.
2) Potom je vhodné nastavit parametry, které se týkají pouze InnoDb tabulek. Těch je trochu více a je potřeba jejich význam pochopit trochu do hloubky. Zde je ale manuál dobře popisuje, jejich přehled se základním popisem dostanete třeba zde (doporučuji ovšem návdavkem přečíst celou část o InnoDB):
http://dev.mysql.com/doc/refman/5.0/en/innodb-start.html
Pokud uděláte první pokus, nejspíše se dostanete na dost vysokou hodnotu ve spotřebě paměti, ale je potřeba body 1) a 2) párkrát opakovat, než to iterací dojde do vyladěného stavu.
Také velmi doporučuji přečíst si část pojednávající o optimalizaci MySQL obecně:
http://dev.mysql.com/doc/refman/5.0/en/optimization.html -
Milan (neregistrovaný)Toto testovani ma jednu obrovskou chybu, ktera zcela znehodnocuje vysledky - nestaci pro kazdou databazi poslat xxx_query().
Nerikam, ze vidim uplne do hloubky, ale tento prikaz posle SQL dotaz do DB, DB prikaz rozparsuje, zanalyzuje, zoptimalizuje a pripravi vse mozne, ale vysledna data nevrati! A to se v praxi prece nedeje, vzdy je treba projit ve smycce (ktrera s daty klidne nic neudela, ale projde je) vsechna vracena data.
Muze autor clanku provest retest s tim, ze ve smycce projde ziskana data? -
anonymníZrovna pro MySQL je použité měření v pořádku - autor použil mysql_query(), to donutí PHP aby všechna data načetlo z MySQL serveru do svého bufferu (můžou s tím být problémy, pokud PHP nemá k dispozici dostatek paměti). Podvod by byl kdyby se použilo mysql_unbuffered_query() a pak by se data nezpracovala. Jak je to pro jiné databáze to nevím, ale možná to bude podobné. Nebo že by to měl Firebird vyoptimalizované a proto byl tak podezřele rychlý?
-
Michal Kubeček (neregistrovaný)Asi jste přehlédl podstatný detail: do PHP nemá celkem co proudit, ten dotaz totiž vrací jen jeden řádek. Takže to, jestli ten jeden řádek načtete do PHP nebo ne, nehraje nějak zásadní roli, vše podstatné se děje už při volání
ibase_query()(nebo, chcete-li,ibase_dsql_execute()) a ten jeden fetch nemá šanci výsledky podstatným způsobem ovlivnit. Stejně tak je v tomto případě celkem jedno, zda takový typ testu provádíte přes PHP API, céčkové API nebo třebaisql. -
Michal Kubeček (neregistrovaný)
Dobře, tak jsem to zkusil. Výsledek: 528 ms
ibase_query(), 63 msibase_fetch_object()iibase_fetch_row(). Aby byly výsledky méně zkresleny náhodnými fluktuacemi, zkusil jsem ještě totéž pro 1000000 náhodně vygenerovaných záznamů místo 266266. Dostal jsem 2058 ms versus 89 ms, tentýž dotaz visqlukáže 2.23 s. Takže není pravda ani to, že by byl výsledek ovlivněn efektivitou PHP API, ani to, že by byl (zásadně) ovlivněn chybějícím fetchem.Pravdu byste měli pouze u druhého testu (s indexem), pak to pro milion záznamů vychází 1 ms na
ibase_query()a 730 ms naibase_fetch_object()Na druhou stranu se mi moc nezdá to, co píše autor o importu dat do tabulky. Mám podezření, že z neznalosti používal na každý řádek
ibase_query(); při použitíibase_prepare()aibase_execute()jsem měl tabulku naplněnou za 25 sekund, což by podle výsledků prvního testu odpovídalo necelým třem minutám na jeho systému. -
Prectete si treba tohle, nez budete delat nejaky 'benchmark':
http://www.zedshaw.com/blog/programming/programmer_stats.html
Precetl jsem si na abclinuxu tradicne hodnotny clanek: preklad kernel traffic a pak jsem zacal cist na rootu tehle benchmark a akorat me to otravilo, spolecne s tim poslednim 'komixem', proste root.cz je v kytkach, zasla slava, je to vycpele :-(
Nekdy mene je holt vice. -
rezna (neregistrovaný)rekl bych ze tech clanku co by tu nemely co delat je tu vic :) - vzpomenme treba na genialni clanek o skype - taky jenom blbe tlachani do vetru a haneni closed source aniz by autor vedel o cem pise.
a btw proc na serveru kde se sklonuje linux ve vsech padech delate testy na MS Widlous? - Kdyby to ten clovek aspon testoval na serverove instalaci na 2 procesorove stanici a ne na domacim celeronu kde to ma hoouby vysledky. Navic ani tak neni MS Widlous platformou kde by se tyhle DB pouzivali. POkud nasazuju server jako windows tak jedine s MSSQL nebo Oraclem (zalezi kolik zakaznik zaplati). -
honzucha (neregistrovaný)No kdyz uz teda srovnavate, tak by bylo dobry srovnavat nejen podle rychlosti, ale i podle vlastnosti, napriklad mysql ma pochybnou implementaci trigeru, vubez zadnou proceduralnich jazyků (takze to ze mysql nekde neco nejakym zpusobem vuselektilo rychleji, pro me nema smyslu, protoze me pripravuje o robustnost aplikaci, napr. prevest pl/sql fkce z oracle db je ve vetsine pripadu o minoritnich zmenach a pod). Jako docela dobry zdroj informaci doporucuji http://monstera.man.poznan.pl/jra1-wiki/index.php/Mysql_vs_postgres
-
MatBa.FDF (neregistrovaný)Mne teda uz na zacatku zarazilo ta kofigurace:
Ako počítač bol použitý:
Intel Celeron 2.2 MHz
768 MB RAM
20 GB Disk
MS Windows
Ja se priznam, ze nevim jestli intel vyrabel celerony uz v nekdy v roce 1990.
Ale jinak je to urcite zajimavy clanek pro ty, ktery chteji zacit vyvyjet aplikace provazane na databaze. -
next (neregistrovaný)Tie grafy by si zasluzili 5 min prace, nasledne by boli 3x citatelnejsie.
a) nadpis - z "Meranie 1." sa nedozviem vobec nic -> neviem o com je graf
b) X a Y osi nemaju popisku -> zas neviem, o com ten graf je, ake informacie zobrazuje
c) bez popisiek osi nie je jasne, ci je "lepsia" mensia alebo vacsia hodnota na Y osi.
Keby som taky graf odovzdal v skole, vyhodili by ma zavretymi dverami. A mali by pravdu. -
rezna (neregistrovaný)kdysi jsme v notne podnapilem stavu odhodlali ke stvoreni apriloveho zertu - http://www.ceskehry.cz/magazin/view.php?cisloclanku=2004040101 .
tato recenze mi ho velice pripomina ;) -
Dusan (neregistrovaný)Nechcem len kritizovat, ale tu sa da ocenit iba snaha. A najma vytvorenie dalsieho zbytocneho flamewar-u.
Ale miesto zabitia casu takymto "porovnanim" by bolo lepsie nastudovat tych X existujucich benchmarkov, co su na nete uz davno.
Ak je to s tym FB (nespustenie SELECT) naozaj tak, potom je to dost zabavne :-) Ze to autorovi vobec nenapadlo ... v kazdom teste 10-50 nasobne rychejsia DB ako je mysql, ci postgres ....
*** ROFL ***
Nerozumiem ani, preco na tom serveri vlastne bezal apache.
Lepsie by bolo pouzit http://vegan.net/tony/supersmack/ a definovat tam vlastne query .
Cisty amaterizmus. -
anonymníChtel jsem pridat k clanku reakci, ale po shlidnuti toho, kolik je toho tady napsano, jsem se prece jen rozhodl, ale nebudu kritizovat tolik.
- Testovat databazi v domacich podminkach je smesny.
- U grafu je jen nadpis "test c. 1" a podobne. No co to je? Hodnoty jsou tam ale kde jsou jednotky? To kvuli debilne udelanymu grafu musim cist cely balast hovadin, jen abych nekde uprostred vety nasel hlasku, ze na ose jsou sekundy, to nejde do toho grafu napsat tuto: [s]
Tim pro me cteni clanku skoncilo, pac nesplnuje zakladni sdelovaci podminky. To ze se autor zabyval tematem testovani rychlosti, neznamena to, ze tematu rozumi. Jen dospel k zaveru ze ... -
anonymníto testovanie nie je smiesne, smiesne su len navrhy testov.
vsetky testy sa robia za predpokladu, ked sila hardware prevysuje zataz testu.
v testoch zameranych na pretazenie systemu mal zas navrch postgresql ... dokonca trojnasobne oproti mysql.
v malych tabulkach mysql vedie, ale v komplexnosti a stabilite body straca.
nevraviac o sfetovanom manikovi, co im navrhuje syntax sql, asi by ho mohol niekto upozornit, ze existuje aj dajaky ten standart. -
MaReK OlšavskýZlatý podporovatel
- Reálný test si představuji trochu jinak a napsat testovací sadu je trochu složitější:
- Rozhodně pro tento účel není vhodný scriptovací jazyk, ale jednoznačně například C++
- Máte jistotu, že jste buď vždy převzal (fetch) data z SQL databáze, nebo že jste ji nechal přikaz udělat jen na prázdno?
- Jaký typ indexu jste v PgSQL zvolil? A byl vhdný?
- Operace na jedné tabulce a jen prosté SELECTY? Proč ne JOINy mezi tabulkami, výběry pomocí regulárních výrazů, subselecty, vkládání mazání a update ve vhodném poměru?
- Takto to opravdu vypadá, že jste chtěl honorář a předvést, že nějaké databáze znáte.
IMO na konkurenčním serveru píšeme s kamarádem seriály o MySQL a PostgreSQL, do srovnání rychlosti se nehrneme a víme, proč to děláme ono stačí navrhnout testovací strukturu a indexy tak, že MySQL propadne o 500% i když tam bude jen 100 řádek.
-
anonymníhej? a aky je dovod pouzit prave C++?
dolezite je predsa, aby pre kazdy jazyk bola pouzita "ta spravna metoda".
ak to niekomu vadi ...
imho je jedno v akom jazyku sa vykona. kludne aj sposobom "time $console -f $file"
ak, tak testovat C/C++, Java, Perl, PHP, Python, mozno sa najde aj dakto, kto spominane testy napise v Ruby. ale samozrejme, vzdy aj cez konzolu daneho stroja.
dolezity je navrh testu. vypracuj(me/te) pre vopred zadany hw a sw
- konfiguraciu sluzby (spolu so startup skriptami
- navrh struktury tabuliek
- inicializacne data, postup inicializacie
- testy
pred kazdym testom reboot, spustenie len testovanej databazy.
testy:
a) priame vykonavanie SQL
- synteticke selekty
- cykly select - insert - update
- triggre, view, ...
b) s vyuzivanim roznych optimalizacii prace (prepare statementy, vypnuty autocommit, ...)
synteticky test je jednouzivatelsky
realny test je test pri pripojeni viacerych klientov (navrhujem testovat 8, 16, 32, 64, 128, samozrejme s moznou roznou optimalizaciou na predpokladanu zataz)
a spravit rovno "velky test" na
postgresql 7.4, 8.0, 8.1
mysql 4.0, 4.1, 5.0 (ak existuju dolezite dalsie verzie, doplnte)
firebird
(a vsetky mozne i nemozne dostupne db, ako oracle, db2, sybase)
priklanal by som sa k testu pod linuxom, s odporucanou konfiguraciou kernelu (2.4 / 2.6 by tiez stalo za uvahu do testu zahrnut).
samozrejme, vsetky nastavenia/utility/generatory atd pod GPL (alebo aspon LGPL).
do banku davam
- stroj pre domace pouzitie (p4 2,4; 512 ram; 200GB sata)
- svoje znalosti perlu a postgresql -
MaReK OlšavskýZlatý podporovatelMno s pozadavkem na C++ jsem to mozna prepiskl, ale zase na druhou stranu je IMO lepsi kompilovany jazyk, nez scriptovaci (scriptovaci muze jet jako opravdu interpretovany, pripadne muze byt pri prvnim pruchodu interpretovany, ale dalsi prubehy cyklu mohou byt v jiz zkompilovane z cache..., anebo pred prvnim startem scriptu je docasne prelozen do strojoveho kodu a pak spusten, ...)
Ale zcela vazne, takto, jak bylo v tomto clanku test nema zadnou vypovidaci hodnotu, pouze vypovida o autorovi, ze si chtel vydelat a ukazat, ze zna nejakou databazi. (Nebo ze by redakce zverejnila clanek, pod nimz flame vyvola vetsi pocet zobrazeni reklamy, zamerne? :-D (Dobre, tak tomu sam neverim...))
btw: Reboot by nebyl potreba, ono by melo stacit zrestartovat daemona a je-li to v PHP i httpd, pak by v cache nemelo byt nic predzpracovaneho z minula. -
Richard (neregistrovaný)Takéto benchmarky sú dosť nezaujímavé a nepraktické. Mám za sebou dosť veľa aplikácií v MySQL, PostgreSQL a v Oracle aby som vedel čo je pre vývoj a nasadenie aplikácií dôležité a čo nie.
Ďaleko viac ako rýchlosť si na databázach cením spoľahlivosť a bezproblematická práca s danými databázami. V 90. rokoch som nedal dopustiť na Oracle ale to bolo v časoch client-server aplikácií, keď bolo dôležité aby server zvládal veľké množstvo pripojených užívateľov a časť logiky aplikácie bola písaná v triggroch a stored procedúrach. V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.
V súčasnosti ale nevidím ani jednu výhodu Oracle pred MySQL. S Oraclom bývajú niekedy dosť vážne inštalačné problémy, najmä v kombinácii s jeho vlastným aplikačným serverom. Oracle je pomerne dosť veľký žrút zdrojov - zatiaľ čo pri MySQL si môže každý programátor nainštalovať svoj vlastný server na počítač. MySQL má veľmi jednoduché možnosti na export a import (oproti Oracleovskemu exp a imp kde neexistuje jednoduchy export a import dat bez zbytocneho balastu) a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS a verziu MySQL.
Nechcem tvrdiť že MySQL je dokonalá, už ma tiež raz alebo dva krát sklamala ale zistiť kde je chyba a opraviť konfiguráciu je vďaka jednoduchej príručke a širokej komunite jednoduchšie ako v Oracle.
Čo sa týka PostgreSQL tak sa mi zdá trochu nekonzistentná. Ako keby každý programátor PostgreSQL čo mal nejaký nápad tak ho do implementoval bez ohľadu na nejaké koncepčné riešenie (napríklad syntax príkaz v commandline clientovi nemá nič spoločné s SQL). Pri nasadení novej verzie sa mi napríklad stalo, že sa zmenila syntax (pre LIMIT) a musel som v aplikácii opravovať SQL príkazy. Nekonzistetná je aj príručka. Keď som hladal CREATE TABLE tak ako prvú som našiel stránku http://www.postgresql.org/docs/8.0/interactive/tutorial-table.html kde vôbec nie je odkaz na stránku, ktorú som naozaj potreboval: http://www.postgresql.org/docs/8.0/interactive/sql-createtable.html. O problémoch, ktoré boli s inštaláciou predchádzahjúcej verzie na windowsoch by sa dal napísať samostatný článok.
Pri tvorbe ponuke zákazníkom vždy doporučujem MySQL - ale aj tak sa 90% percent zákazok robí v Oracle :) -
honza (neregistrovaný)[...]V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.[...]
V diskuzi k mysql na heise.de je asi 80 prispevku k teto problematice. Zhruba 80% respondentu NENI vaseho nazoru. I v jinych diskuznich listech je obdobne mineni. Nezda se Vam to podivne? -
rezna (neregistrovaný)tady si dolovim tezce nesouhlasit ;) - na vykon se sice v urcite mire nehledi, ale hledi se na spolehlivost a hlavne na jednoduchou konfigurovatelnost byznys vrstvy s tim ze pokud mate slusny model ulozeni byznys objektu (napr. XML nebo vlastni textovy format) tak jste schopen z neho generovat i strukturu DB a tim vlastne vydefinovanim jedne vrstvy pokryjete ihned vrstvy 2 coz u stored procedur je trocha mimo ;) - SP maji mozna o neco vyssi vykon ale zase to jejich debugovani je silene a spousta obecnych resenich ktere se v nich pisou je uplne silena.
-
rezna (neregistrovaný)jasne - pokud SP prinese urychleni z n^3 na n*log(n) - OBRAZNE RECENO - tak ji lze aplikovat - ale jde o to ze min. 90% byznys prace by mela obhospodarovat skutence oddelena byznys vrstva a ne DB protoze co kdyz se v pulce projektu zjisti ze nasazena MySQL nestaci a je potreba neco vetsiho - potom by to bylo dost v pytli byt zavisly na jedne DB
-
Petr (neregistrovaný)Ja to slovo "zrychleni v radu" ctu jako "zrychleni desetkrat" ("o rad"), ne jako "prechod na en-log-en". A musim rict, ze je sakra rozdil, jestli batch job, ktery se spousti denne, bezi tri hodiny nebo tricet hodin.
Psani jednoduche DB vrstvy a slozite aplikacni vrstvy vypada dobre na papire, dokud nezjistite, ze si nejste az tak uplne jistej, co delat s gigabajty dat, ktere byste z databaze musel vytahat a zase do ni vracet. (Samozrejme ted nemluvim o webshopu :-)) -
Richard (neregistrovaný)Ne, nezda. Myslim, ze diskusii o databaze sa vacsinou zucastnuju ludia ktori o databazach vedia vela a problemy, ktore ma aplikacia riesit casto riesia prostriedkami, ktore ma databaza. Musim priznat, ze aj som to tak kedysi robil. Ale ak mam business logiku na aplikacnej vrstve, tak nemam vela dovodov pouzit ulozene procedury alebo triggre.
-
benzin (neregistrovaný)Nesouhlasim s Vami. Je to databaze, ktera se stara o konzistenci dat. Pokud tento problem presunete do Aplikace, muze se Vam velmi jednoduse stat, ze nekde neco malo opomeneta a data budou nekonzistentni.
Netvrdim, ze vsechno se musi delat v SP, ale operace, ktere souvisi s konzistenci dat, je nutne delat primo v SP a Triggrech.
P.S.: Casto se stane, ze si zakaznik najme mensi firmicku na sprogramovaniho nejakeho prevodoveho mustku, ten se pak muze rozhodnout pro primi pristup k datum v DB (misto pouziti nedokonalych exportu/importu), paklize nejsou SP a Trigeri udelane spravne, muze se lehce stat, ze se data rozbiji. Pak se muzete dohadovat kde udelali soudruzi z Polske Demokraticke Republiky chybu (kdyz ani nevite, ze vam tam nekdo hrabe primo). -
rezna (neregistrovaný)pozor ale mluvime jeden o A a jeden o B - jednak se tu resila byznys vrstva - tedy aplikacni logika a ta do DB urcite nepatri, druha vec je databazova vrstva zajistujici konzistenci dat jako jsou spravne FK klice, ukladani kopii radku pri zmenach apod. - tohle do DB urcite patri - do toho by zase byznys logika nemela co sahat...
-
rezna (neregistrovaný)> a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS
> a verziu MySQL.
mno jasne ISAM jsou super hlavne kdyz se vam snazi dva uzivatele z 6000 snazi pristoupit k jednomu radku tabulku v tom stejnem momentne nebo nedej boze potrebuju rollbacknout transakci ktera tam neexistuje ze ;) -
Predem dekuji autorovi za odvahu publikovat takovy flame-nachylny clanek. Vysledky me take vyrazily dech, ps Pgsql nemam zkusenost, ale rikalo se, ze v7 je pomala, v8 je rychlejsi a mysql je nejrychlejsi (aspon v <4.1). Vse ale zalezi na navrhu, indexovani a podobne. Mrzi me jen, ze autor pouzil proprietarni platformu Windows, ktera v mem pripade neni vyuzivana na serverech vubec (ani desktopu :). Na mysql jsem postavil par desitek webu, nejvetsi asi www.depo9.cz . Problemy nastavaji ve spojovani, absenci triggeru a subselectu (v<4.1). Nektere selecty do vice vetsich tabulek jsou i pres indexovani dost pomale. Na FB jsem postavil www.supplypro.de a prace s nim me prijemne prekvapila. Podpora ansisql, vetsina funkci znamych z enterpise databazi, slusna rychlost, podpora charsetu na urovni db atd. Dokumentace je vskutku dost spartanska, nebyt knihy P.Cisare, asi bych do toho nesel. Rozhodne doporucuji FB minimalne vyzkouset.
-
honza (neregistrovaný)my mame zkusenosti se zakazniky taky takove, ze jim je jedno vlastne jak funguje ta aplikace (treba jak se zaskladovava) ale rozhodujici jsou ty vlastnosti databaze. Napr.si nedovedu predstavit, kde bychom vzali tu odvahu zakaznikovi rici, ze se pouziva databaze bez ansisql podpory.
Takze tedy souhlas. -
anonymnía ako je to so sekvenciami v mysql? viem ze ma nejaky zvlastne fungujuci autoincrement, ale ten nemozem dat na stlpec iny ako primary key a ani nemozem pouzit jednu sekvenciu napr pre vsetky tabulky dohromady (jeden z prikladov pouzitia, poziadavka bola, aby id bolo unikatne v celej db, nielen v tabulke)
-
geneticy (neregistrovaný)Srovnáváte jabka s hruškami a sypete do toho hřebíky ! Ten test na této konfiguraci je naprostý nesmysl a při téhle konfiguraci a nastavení by asi byla absolutně nejrychlejší VFP databáze i nad SQL (a přitom nejde o Db server) s nativním přístupem díky Rushmore indexaci...a možná i ten hloupoučký Access z MS Office.
Tyto testy by se měly provádět zásadně na strojích (HW konfigurace samozřejmě souhlasná) s vhodným OS pro daný DB server, s vyladěným, nikoliv defaultním nastavením a s naindexováním tabulek tím doporučovaným způsobem, jakým pro danou DB je doporučen zkušenostmi/výrobcem. Také syntaxe SQL příkazů musí odpovídat databázovému stroji (ano, máme ANSI SQL, ale žádná databáze na něm ten nejlepší výkon nepodává, každá má své advanced rozšíření). A ani pak se ničeho nedoberete, protože některý systém pro svou perfektní práci prostě potřebuje víceprocesorový systém, HT či jinou věc, nebo jisté minimální množství paměti, protože část DB serverů objekty cachuje (Oracle, MSSQL Ent. třeba views) a to pak teprve sviští, jinak se plouží. Taky jedna věc je nativní přístup k datům z konsoly a jiná věc je aplikační přístup přes prostřednické vrstvy (např. ODBC, OleDB, JDBC atd.). Mizerný ODBC driver vám nezachrání skvělý DB stroj.
Pro rozhodování jakou databázi by neměl být surový výkon hlavním činitelem, ale její vybavení pro daný úkol. Pro bankovní aplikaci těžko zvolíte MySQL, když nutně potřebujete Stored Procedures, stoprocentní referenční integritu, indexovatelné views a transakce. Pak asi sáhnete hluboko do kapsy a vezmete Oracle, DB2, Informix nebo Enterprise MSSQL (podle ostatního vybavení svého systému). Pro webovou aplikaci určenou ke sběru dat a běžící na Linuxu nezaváháte nad MySQL, pokud má umět o něco více, tak PSQL. Pokud potřebujete v MS síti databázi s kombinovaným přístupem web/lokální aplikace/.NET tak asi nebudete váhat na MSSQL, když na to budete mít. Někdy je důležitá rychlost, ale při výkonech dnešních serverů až tak extrémně důležitá není. Mnohdy hraje větší roli její vybavenost a spolehlivost, případně accesibilita z více aplikací/klientů (tzn. vybavenost drivery pro externí přístup) nebo možnost linkovat cizí DB zdroje/servery (nejde o import) do heterogenních datových skladů či schopnosti provozovat OLAP services, při vysokých zátěžích pak třeba pooling a recyklace zdrojů atd.
Myslíte, že monopost F1 by jel na polní cestě rychleji a spolehlivěji než traktor ? Nebo obráceně ? Nebo by jste k odvozu obrovského množství hnoje použili trabant ? A pro nákup do Tesca by jste si zajeli míchačkou na beton ? A na dovolenou na Bahamy by jste letěli na rogallu ? A Lužnici sjížděli na raketovém křižníku ?
Každý DB systém má své místo a porovnávat má smysl JEN v konkurečním nasazení, kdy rozvažujete - stačí mi na ten webový obchod MySQL, nebo to časem rozšířím o on-line platby kartami a prostě se bez spolehlivých transakcí a zabezpeční na úrovni dat již neobejdu ? Těžko budete vnucovat nějakému RM systému řešení na MySQL, stejně jako těžko budete přesvědčovat majitele info portálu s počasím o nutnosti nákupu Oracle, případně těžko budete přesvědčovat firmu vlastnící .NET vývojářský tým, aby přešla na Firebird.
Prostě mi některé nápady připadaly v této diskusi otřesné, promiňte... -
Franta Flinta (neregistrovaný)Obavam se, ze tento test neni moc dobre zvladnuty. Jak nekdo prede mnou psal, tak je lepsi mit vice tabulek(naplnenych a spravne oindexovanych) a potom se zacit poustet do nejakych testu a provadet vyber pres vicero tabulek.
Navic konkretne u FB, se kterym mam nejvetsi zkusenosti je zname, ze dotaz volany skrze proceduru je hotov mnohem rychleji nez bezny SELECT na DB.
Svinsva v cteni typu FIRST x SKIP y normalni programator nepouzije! To je zhovadilost na n-tou!
Zatim co nekteri pisou, ze jdou radeji do mySQL pro "mensi" projekty, u nas je to presne naopak. Od mySQL se ustupuje smerem k Firebirdu. Ulozene procedury a triggery jsou veci, ktere posouvaji mySQL(se kterym jsem zacinal) uplne nekam dozadu.
ČLÁNKY DO MAILU