mysql cache

[ivanhoe]

a jeste li razmisljali o upotrebi temp tabela koje su tipa HEAP, to jest drze se u memoriji servera ?

Nisam nikad merio vreme, ali su HEAP tabele prilicno brzo, ja sam tu tehniku koristio za kesiranje hijerarhije kategorija (posto su se u bazi cuvali samo parent id za pod-kategorije, pa onda to treba prevezati u stablo..) i fino je radilo... nema pojma doduse koliko je to brzo u poredjenju sa fajlovima, meni je trebao sql join, pa mi je odgovaralo da koristim bazu za to, da ne moram rucno da ga radim...

mislim da postoji i neka fora da se nalozi mysql da za obicnu myisam tabelu cuva index u memoriji umesto u zasebnom fajlu, jel zna neko nesto o tome ???

[Petar Marić]

Hm, mislim da HEAP (aka MEMORY) tabele nisu najefikasnije rešenje za keš, osim ako ne želiš da izgubiš sav sadržaj keša pri restartovanju servera

14.3. The MEMORY (HEAP) Storage Engine
The MEMORY storage engine creates tables with contents that are stored in memory. Before MySQL 4.1, MEMORY tables are called HEAP tables. As of 4.1, MEMORY is the preferred term, and HEAP is a synonym for MEMORY.

Each MEMORY table is associated with one disk file. The filename begins with the table name and has an extension of .frm to indicate that it stores the table definition.

To specify explicitly that you want a MEMORY table, indicate that with an ENGINE or TYPE table option:

CREATE TABLE t (i INT) ENGINE = MEMORY;
CREATE TABLE t (i INT) TYPE = HEAP;

MEMORY tables are stored in memory and use hash indexes by default. This makes them very fast, and very useful for creating temporary tables. However, when the server shuts down, all data stored in MEMORY tables is lost. The tables continue to exist because their definitions are stored in the .frm files on disk, but their contents are empty when the server restarts.

...

Ako pročitate celokupnu stranicu možete zaključiti sledeće o HEAP/MEMORY tabelama:
Pros:
1. Brže su

Cons:
1. Zahtevaju dodatni RAM
2. Celokupne se moraju nalaziti u RAM-u
3. Pri restartovanju servera gube se podaci sadržani u njima (definicije same tabele ostaju)
4. Mogući sinhronizacioni problemi ako koristimo replikaciju
5. Ne podržavaju BLOB i TEXT polja (kao i njihove varijante, duh)
6. Polja tabele su fiksne dužine

Eto, sad je samo ostalo da se dodaju korektivni faktori za svaku stavku i da donesemo odluku (narodski rečeno: da izvagamo rešenje)

[bluesman]

Heap tabele su (po meni) jedino dobre za privremene transakcije kada je potrebna temp tabela... iako mysql moze automatski da kreira TEMPORARY table pa da je brise po zavrsetku sesije, heap je ipak dosta brzi... Istina, igrao sam se sa tim cisto zbog testiranja i jednostavno nisam mogao da nadjem dobar razlog za neku drugu primenu.

Sto se tice tvog "Cons" br 3. to i nije tako "cons", narocito ako se koristi za kesiranje.

[Petar Marić]

Hmm, zavisi od situacije - ali se u opštem slučaju slažem s tobom Gorane.

[zextra]

A mozda za podatke koji slobodno mogu da nestanu nakon restarta servera? Mislim da se za svaki podatak moze reci da je bitan, ali isto tako (bar po meni) postoje situacije kada se podatak moze proglasiti nevaznim (npr. pre-generisani captcha kodovi koji nisu prosli validaciju, a jos uvek nisu uklonjeni iz nekog razloga, ili tabela sa aktivnim sesijama...)

Sto se tice privremenih tabela, ja sam koristio MyISAM jer sam imao potrebu da ucitam veliku kolicinu podataka, sortiram ih na nekoliko nacina, izracunam poziciju svakog clana doticnog niza prilikom svakog od sortiranja, i dobijene podatke da ucitam u stvarnu tabelu... Bez da zalazim u dalju problematiku, ne znam zasto se nisam odlucio za HEAP tabele, iako sam znao da postoje - morao bih to ponovo da uradim da bih uocio problem na koji sam tada naisao...

[bojan_bozovic]

A CREATE TABLE tabela1 TYPE=HEAP SELECT ... Da li se pogledi skladiste u memoriji? Ja cu da prenesem podatke iz moje baze na serveru u lokal (v5) da bas vidim hoce li tabela tipa HEAP uz DROP TABLE IF EXISTS da bude brze resenje od pogleda, jer poglede imam samo u lokalu. Mogu li ja nekako znati da li je DB server pao, pa ako jeste da regenerisem tabele? Mada MySQL ima svoj interni cache, za malo podataka i mnogo UPDATE upita bilo bi mozda bolje da se ide sa tabelom tipa HEAP (moj slucaj).

BEGIN ;# MySQL returned an empty result set (i.e. zero rows).
CREATE TABLE TMP(
PRIMARY KEY ( UID ) 
) TYPE = HEAP SELECT UID, USERNAME, AVERAGE
FROM USER
LEFT JOIN VOTES ON USER.UID = VOTES.USERID;# Affected rows:64
UPDATE TMP SET AVERAGE =10 WHERE UID =2;# Affected rows:1
SELECT * 
FROM TMP
ORDER BY AVERAGE DESC ;# Rows: 64
COMMIT ;# MySQL returned an empty result set (i.e. zero rows).

Pogledi na MySQL 3.23 Plus sto mozemo da udaramo upite u memoriju koliko zelimo (da li moze UPDATE ili INSERT INTO pa SELECT kod pogleda?) Naravno na kraju se udari REPLACE ili INSERT INTO ... SELECT - hmm SELECT nema smisla zbog BEGIN...COMMIT ali ovako mozemo da implementiramo AUTOCOMMIT=0 na MyISAM tabelama (ispravite me ako gresim) - jer ovo je rucno upravo ono sto InnoDB radi - pise u memoriju I pre zadnjeg REPLACE nista ne moze biti upisano u tabelu ako server padne Gledao sam prakticno na ovo kao na implementaciju pogleda u MySQL<5.0 ali ispade da moze vise da se uradi