MySQL-3.23.21-beta a BerkeleyDB tables

[Pavel Janík ml.]

Ahoj,

nějak jsem se včera nedostal k poště a newsům, takže tady je jedna velká
odpověď ;-)

   From: zakkr na zf.jcu.cz (Karel Zak)
   Date: 14 Jul 2000 08:51:54 +0200

   >  To mne napada otazka --- pokud jsi se dival na zdrojaky PG a MySQL, mas
   > nejaky "porovnavajici pocit" z teto oblasti?

V PostgreSQL jsem se díval hlouběji pouze na pg_dump a na nový pgdump s
podporou BLOBs (ale ne ten Tvůj, i když ten jsem taky viděl :-) a trošku na
query optimizer a v MySQL jsem si prolezl velmi důkladně podporu
BerkeleyDB, a proto bude mé "mini hodnocení" založeno na tom, že u MySQL je
to velmi raná verze, která se do další bety velmi změní...  Přijde mi, že
do MySQL byla tato část jaksi vlepena bez velkého rozmýšlení. Ostatně to
potvrzují maily do jejich vývojářského listu: Dana Powers, já i kdosi další
jenom reportujeme chyby a Monty už poslal nejméně tři patche týkající se
podpory BDB. Vůbec si nemyslím, že by platilo jinak správné Adeltonovo
tvrzení o tom, že jim někdo ukáže kód a oni jej zařadí. Tady je prostě
napadlo, že transakce jsou fakt potřeba a začali je implementovat. Alespoň
mi to tak připadá. Nebo se pletu?

   > IMHO Interbase bude konecne konkurence pro PostgreSQL, osobne se take moc
   > tesim na zdrojaky. Stejne by mne zajimalo proc to tak dlouho trva nez to
   > vypusti - jako odpoved by mohlo byt, ze tam pouzivaji veci, za ktere 
   > nezaplatili ... US patenty (apod.) :-)))

Myslím si, že je to tak. Ostatně totéž se týkalo SGI Linuxu apod. Closed
Souirce má prostě jiné problémy než Open Source :-)

   > udelano poradne tak stejne povede k rychlosti jakou ma
   > PostgreSQL. Osobne si myslim, ze MySQL ma sve vyrazne misto v takove
   > podobe v jake jsme ho znali doposud. Tomu novemu moc
   > nerozumim... treba mi to nekdo kdo se zabyva MySQL vysvetli.

Nevím, jestli jsem ten správný, ale myslím si to, co napsal Ondřej - nikdo
Ti neříká, že si musíš zvolit pro každou tabulku ten typ, který toho umí
nejvíc. To si myslím, je nyní velká přednost MySQL. Např. pokud chceš velmi
rychlé tabulky (např. TEMP tables), zvolíš velmi rychlý typ tabulky HEAP,
která je uložena kompletně celá v paměti, vůbec ne na disku. Pokud chceš
normální tabulku (s možností recovery), použiješ MyISAM. Pokud potřebuješ i
transakce, tak zvolíš typ BDB (doporučuji to udělat až v další verzi :-)).


   From: adelton na informatics.muni.cz (Honza Pazdziora)
   Date: 14 Jul 2000 23:05:28 +0200

   > Pokud mam slozity dotaz
   > 
   > 	select neco from joinovane tabulky where spousta podminek
   > 		a jedna z nich je ten fulltextovy test
   > 		contains(sloupec, 'vyraz') > nejake skore
   > 
   > tak typicky chci primarne hledat podle toho fulltextu a pak joinovat
   > se zbytkem. Tedy nejriv chci najit mezi milionem zaznamu ty tri, ktere
   > odpovidaji vyrazu 'karel zak and mysql' a pak s tim vysledkem neco
   > delat.

Tohle je záležitost query optimizeru a vůbec tomu tak nemusí být. Pokus
jsou např. "spousta podmínek" pouze prací s indexy, může (ale ne nutně) to
být sakra rychlejší než fulltext. Ale záleží to samozřejmě na dané
situaci. Pokud PostgreSQL má analyzovanou tabulku a ví, že např. jedna z
podmínek (za předpokladu, že podmínky jsou ANDované) je typu id=nějaké
číslo a v dotyčné tabulce je id primární klíčem, omezí hledání na pouze
tuto podmínky a pak teprve pokračuje se zbytkem.

   > Vzhledem k tomu, ze MySQL se pouziva typicky v prostredich, kde 95+ %
   > jsou opakovane dotazy typu
   > 
   > select 1 from hesla where uzivatel = 'adelton' and heslo = 'zakryptovaneheslo'

No, tak zrovna tohle kdybych měl dělat hodně rychle/často, bych nepoužil
databázi :-) A pokud bych musel, tak bych si napsal novou funkci v C a
přilinkoval.

   From: adelton na informatics.muni.cz (Honza Pazdziora)
   Date: 14 Jul 2000 12:17:54 +0200

   > Jakoze kdyz mam
   > 
   > 	select * from jedna_tabulka where podminka
   > 	union
   > 	select * from druha_tabulka where podminka
   > 
   > tak cachovat i ty podcasti? Je to zajimava myslenka, i kdyz jsem ji
   > nemel v planu.

Tohle by byl asi vedlejší produkt toho, že bys cachoval dotazy SELECT *
from tabulka WHERE něco. Pokud by to bylo pro tento typ dotazů
implementováno cachování ať již rozparsovaných dotazů nebo třeba i výsledků
(samozřejmě by musela být implementována nějaká invalidace záznamů v cache
po INSERT, UPDATE, SELECT FOR UPDATE apod.), byla by podpora
automatická. Když už jsme u toho - má nějaký Open Source DB server podporu
materialized VIEVs?
-- 
Pavel Janík ml.
Pavel.Janik na linux.cz