MySQL-3.23.21-beta a BerkeleyDB tables

[Honza Pazdziora]

On Fri, Jul 14, 2000 at 10:49:36AM +0200, Karel Zak wrote:
> 
>  Todle je perfektni pro usery a i vyvoj, ale neni v takovem pripade
> strach, ze se to po nekolika letech zhrouti pod vahou sebe sama?

To jiste ano. Ale to plati o vsem.

>  Ne ze bych chtel na necem takovem pracovat (teda ne pro MySQL:-), ale v 
> celku by mne zajimalo na jakem principu takova cache pracuje, protoze 
> napsat to neni zase takova legrace. Bylo by mozna napsat odstavecek 
> "about"? :-)

Mel jsem snahu napsat dvouurovnovou cache. Za prve by to byla cache

	select dotazy => rozparsovana struktura

a pak

	rozparsovane struktury => vysledky

To prvni je celkem primocare, pokud se nemeni databaze DDL prikazy,
zustava tento prevod stejny. Ten mezikrok potrebuji na to, abych byl
schopen ohlidat zavislosti a invalidovat ty zaznamy v cache, ktere
mohly byt jinymi DML prikazy zmeneny.

Tedy dotaz

	select sloupec from tabulka where id = 4

by se prevedl radove na zaznam

	'select sloupec from tabulka where id = 4' => {
		'tables' => [ 'tabulka' ],
		'selected_cols' => [ 'sloupec' ],
		'condition' => 'id = 4',
		}

nebo na neco podobneho. A nasledne by se tou pravou stranou indexoval
vysledek ziskany pri prvnim pouziti, tedy

	"'tables' => [ 'tabulka' ], 'selected_cols' => [ 'sloupec' ],
	'condition' => 'id = 4'," => [ [ 25 ] ]

Pri dalsim pristupu bych tedy zjistil, ze jde o stejny pripad, ziskal
tu rozparsovanou strukturu a z ni vysledek, jeden radek s jednim
sloupem s hodnotou 25.

Kazdy DDL prikaz by pak zrusil zaznamy obsahujici jmeno tabulky
v seznamu 'tables', a to v obou caches, a kazdy DML prikazy by zrusil
zaznamy obsahujici jmeno tabulky v 'tables' v te druhe, vysledkove
cache (prevod na rozparsovanou strukturu se updatem nemeni).

Do toho jeste vstupuje to, zda je mozno cachovat prikazy, ktere
obsahuji funkce, protoze treba rand nedava porad stejne vysledky. Tam
jsem mel snahu vnutit k tem funkcim priznak, zda pro stejny vstup dava
stejny vystup.

To je asi tak vse.

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'

porad a dokola, mel jsem pocit, ze to ma smysl delat. To prvni jsem
mel v podstate hotove, ale pak to nejak padalo na tom, v jakych
strukturach ma MySQL ty rozparsovane vysledky uchovane (veci, ktere
maji byt nezavisle na spojeni byly ve strukturach per connection)
a nejak jsem casove nezvladl generovat patche pro kazdou novou verzi
(tehdy to zrovna slo nejak rychle). Navic Monty nejak uplne nesdilel
muj pohled, ze se to ma delat dvouurovnove, cili cela snaha sla do
ztracena.

Hmmm. Nejak jsem ten odstavecek pretahl.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
   .project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------