MySQL 5.0 se dočkala svojí beta

MySQL 5.0 se dočkala svojí beta verze. "Je to nejdůležitější verze za posledních deset let," cituje článek na ZDNetu spoluzakladatele MySQL, Davida Axmarka.

29.3.2005 21:40 | Pavel 'lingeek' Szalbot | Nová verze

Komentáře

[Michal Kubeček]

Ten citovaný průzkum mi vyrazil dech, ani ve snu by mne nenapadlo, že je odstup mezi MySQL a Firebirdem tak malý. Zvlášť při porovnání mediální pozornosti, věnované oběma projektům, je to obdivuhodné…

[VícNežNic]

Článek na mně vyplivl velký čtvereček s nápisem chci plugin, takže na něj kašlu.

Každopádně, od hlubšího zájmu mě Firebird odrazuje spojením se jménem Borland.

[Michal Kubeček]

To je divné, já mám 64-bitový Firefox bez jakýchkoli pluginů a článek se mi v pohodě zobrazil.

Každopádně, od hlubšího zájmu mě Firebird odrazuje spojením se jménem Borland.

Tak to se klidně můžete začít zajímat, málokde panuje tak jednotný názor, že Borland je neslušné slovo, jako mezi vývojáři Firebirdu. :-) Už název má naznačovat, že smyslem projektu je znovuzrození InterBase z popela (obrazně řečeno), do kteréhož stavu ji přivedl právě Borland.

[VícNežNic]

Fakt? Tak to asi půjdu ten názor ujednotit ještě víc

Aha, byl to asi nějaký pitomý super-banner ve flashi, teď už se nezobrazil.

[Marek 'marx' Grác]

Po tom, čo som robil s firebirdom v poslednej dobe, tak by som do toho určite nešiel. Mailing listy nečíta nikto, kto tomu skutočne rozumie. Pamäť uvoľnuje až po ukončení spojenia (a nie po commitnutí transakcie), takže správu pamäti si robíte sami cez connect/disconnect, fasa. A pár ďalších drobností, typu vkladanie BLOB rýchlosťou cca 200kB/s aj keď treba uznať, že proces nezaťaží :)

[Michal Kubeček]

S mailing listy tolik zkušeností nemám, sleduji pouze firebird-devel a tam rozhodně nemám pocit, že by ho nečetl nikdo, kdo tomu rozumí… :-) Paměť (dočasná data transakce) se uvolňuje při commitu, ale určitá část je použita na cache daného spojení. Ta samozřejmě zůstane alokovaná, ale nemyslím, že by to bylo na škodu věci. Rychlost vkládání BLOBu jsem neměřil, ale věřím, že kdyby se mi 16 MB soubor vkládal 80 sekund, všiml bych si toho…

[Marek 'marx' Grác]

firebird-devel je jedna z tých konferencií :) To, že sa dočasné dáta transakcie uvolňujňujú pri commite je síce možné, ale nemalá časť z nich tam zostáva. Podotýkam, že robím disconnect po cca 10 transakciách (max. krát 10 selectov), aby som neprekračoval cca 50 MB na spojenie. Bez disconnectu mi zahltí pamať, tak do 15 minút (cca 2GB). Čo sa týka vkladania BLOBu je možné, že sa čosi udialo od 1.5.1 (zase neupgradujem každú chvíľu), ale skôr by som to videl na asynchróny zápis, ktorý robí medzivrstva (ja používam rovno C api, ktoré naposledy dokumentoval Borland). Mne sa podarilo vytiahnuť raz cca 3MB/s, ale aj to na raidovanom disku. Preto by som sa na väčšie veci Firebirdu vyhol, toť osobná skúsenosť. [Samozrejme, že Oracle to istí, ale postačí aj postgres :)]

[Michal Kubeček]

1. Pokud vám lidé jako Jim Starkey, Nick Samofatov, Claudio Valderama, Dmitri Yemanov nebo Ann Harrison nepřipadají dostatečně fundovaní, pak vás asi těžko někdo uspokojí.

2. Mé zkušenosti jsou trochu jiné. Používám Firebird v praxi na serveru ČBF (Duron 1200 MHz). Dokud se nezačaly ve větším používat online přenosy, měl 256 MB paměti, teď má 768 MB. Spojení neukončuji, pokud to není nutné, takže běží i desítky dnů. K vyčerpání paměti ještě nedošlo, Tedy vlastně došlo, ale to bylo v době, kdy počet současně otevřených spojení na databázi dosáhl hodnoty 2048 (a i pak ji vyčerpal spíše Apache než Firebird), od omezení MaxClients u Apache na 768 k tomu nedošlo (ale limitujícím faktorem je tu spíše procesor).

3. Rychlost zápisu do BLOBu byla zcela určitě vyšší než vámi uváděných 200 KB/s, a to i u verze 1.5.1, dokonce i u 1.0.3.

Závěr: pokud se nejedná o FUD, podařilo se vám trefit do nějaké chyby, která nastává za určitých speciálních okolností. Bylo by vhodnější snažit se chybu izolovat a reportovat, než pomlouvat projekt v diskusi.

[Marek 'marx' Grác]

Nejedná sa o FUD. S firebirdom pracujem na myslím, že dosť low-level úrovni (C api) a preto netvrdím, že niektoré veci sa nedajú riešiť inak. Všetky veci o ktorých píšem sa reálne dejú (povedzme, že bohužiaľ, pretože ich musím riešiť), BTW: pracujem s DB, ktorá má zopár giga (<20) možno v tom je jeden z tých problémov, s menšou som nikdy vo FB nepracoval.

ad 1) Vychádzam z toho, že v prípade že som odpoveď dostal tak zväčša bola neverejná a tvrdila, že používať priamo C api je nevhodné a že ho používajú len ľudia, ktorí píšu API pre vyššie jazyky a tým pádom je dokumentácia a stav taký ako je. Napr. jednoduchá otázka ako spraviť dva SELECTy v jednom spojení bez toho aby vznikli nejaké chyby som odpoveď v rozumnom čase nedostal [áno, nakoniec som na to prišiel sám].

ad 2) Bolo by možné zhruba zverejniť veľkosť DB? Ja aj bez použitia BLOBov, čisto pomocou SELECTov (zhruba cez 2-4 tabuľky) generujem cca 4MB/s. Všimol som si, že používate php na ČBF, máte tam persistent spojenia, alebo nie? V prípade, že nie tak sa všetko deje v poriadku pretože sa robí pripojenie/odpojenie po každej stránke. Ak ich však máte, tak potom ak sa nemýlim celé spojenie je zabalené ešte v jednej veľkej transakcii a tak by to tú pamäť zaberať malo.

ad 3) je možné, že sa to deje len pri veľkých databázach. Ale robí to niekoľko verzií na rôznych systémoch a pri rôznych nastaveniach, takže to bude firebird.

Pravidelne zverejňujem a posielam chyby kde-kade a áno často natrafím na špeciálne okolnosti. Popisovanú chybu s pamäťou som sa snažil izolovať, ale videli ste zdrojáky FB ??

[Michal Kubeček]

Ad 1. Taky mám pocit, že standardní API bylo napsáno záměrně tak, aby ho pokud možno nikdo nepoužíval. Vyřešil jsem to (jako asi mnoho dalších) tak, že jsem si napsal mezivrstvu v C++ a používám tu.

Ad 2. Databáze je proti té vaší relativně malá, má asi 100 MB. Měl jsem i aplikace, kde měla databáze několik GB, ale tam byla většinou zase jednodušší struktura. Persistentní spojení v PHP používám, ale u online přenosů (kde je zátěž nejvyšší) v současné době nekomunikují PHP skripty s databází přímo, ale přes middleware démona (napsaného v C++). Ten démon používá pool spojení, která jsou navázána trvale po celou dobu běhu démona (obvykle od restartu do restartu). Momentálně běží teprve od 25. března (update jádra), ale i tak už to vychází přibližně 300000 transakcí na spojení.

Ad 3. Zkusím udělat nějaké testy, jestli se mi to podaří reprodukovat.

[Michal Kubeček]

Tou izolací jsem myslel spíš ořezání částí, které nemají na chybové chování vliv, za účelem nalezení co nejjednodušího ukázkového příkladu. Ale u tohoto typu chyb to může být docela problém. Už několikrát jsem například narazil na to, že jsem přidělil právo update na nějaký sloupec proceduře, ale oprávnění nebylo efektivní, dokud jsem neudělal backup/restore. Pokus o zjednodušený testcase ale zatím pokaždé selhal, tam to fungovalo hned.

[Michal Kubeček]

Jinak se tam tvrdí, že mezi open source database deployments má MySQL 40 procent, Firebird 39 procent a PostgreSQL 11 procent.