Vlákno názorů k článku MySQL vs PostgreSQL vs Firebird od benzin - Par chyb a nedostatku 1) Neuvadite verze MySQL a...
-
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.
ČLÁNKY DO MAILU