Dotaz: Cache dat pomocí MySQL - indexovat?

[mykš]

ahoj, potřebuju pro svou aplikaci vyrobit cache a neboť budou data velice často vybírána pomocí podmínek a bude použito stránkováním rozhodl jsem se použít místo čistokrevného cachování cache pomocí MySQL. Jako úložiště bych chtěl použít InnoDB a data aktualizovat pomocí transakcí - načtu data ze zdroje, vyrobím updaty a v jedné transakci to pošlu lokální MySQL cache tabulce, protože to bude asi nejrychlejší. Dále budu používat v těchto cachovacích tabulkách cizí klíče. Zajímá mě ale váš názor na použití indexů pro takovou tabulku. Předpodládám max. 50 000 záznamů s tím, že různé sloupce se budou aktualizovat v různých intervalech oproti zdroji dat.

Odpovědi

[okbob]

memcached nebo SQLite bude určitě rychlejší

[mykš]

No hlavní tabulku databází mám v mysql a ty pomocné cachovací tabulky s tou hlavní budu spojovat pomocí určitého klíče (PRIMARY - to je jediný klíč u kterého jsem si jistý že tam být musí, ostatní nevím jestli to spíš nezpomalí kvůli updatům innodb), tak je pro mě velice výhodná volba mysql. S použitím memcached bych aplikaci nejspíš hodně zpomalil. Po memcached jsem koukal a nezdá se mi že umožňuje data třeba jen řadit. Určitě bude rychlejší provést "select * from tabulka where sloupec like "_da?" AND id < 500 order by sloupecX, sloupecXy, sloupec Xz limit 300" v SQL než načíst data z memcached a filtraci, řazení, limitování či stránkování provést až v programu.

[okbob]

Záleží, co chcete s tabulkou (objektem) dělat - pokud ji používat jako tabulku, tak pak bude výhodnější MySQL nebo SQLite - což je asi Váš případ - pak mi nesedí použítí slůvka cache, i když cache může být jakákoliv. Proč rovnou nepoužijete replikaci?

[Filip Jirsák]

K čemu tedy ta cache bude sloužit? Děláte nad daty z databáze nějaké složité výpočty a jejich výsledky chcete v té cache ukládat? „Normálně“ se cache nad databází používá pro to, abyste přístupy k databázi omezil, k tomu ta vaše cache určitě nepomůže.

Pokud skutečně nad daty děláte nějaké složité výpočty, vyřešil bych to tak, že bych si udělal pro ta výstupní data pohled nebo uloženou proceduru („implementaci“ pak následně můžu měnit beze změny „rozhraní“). Jednoduchá implementace by byla taková, že jenom v okamžiku požadavku spočítá výsledek a vrátí jej, nebude nic kešovat. Pak případně můžete přidat kešování tím způsobem, že si vytvoříte pomocnou tabulku nebo tabulky, které budete plnit pomocí triggerů z primárních dat a onen pohled nebo uloženou proceduru předěláte na použití těchhle pomocných tabulek.

[mykš]

No struktura je následující:

MySQL cache
------------------
centralni_tabulka




MySQL hodně vzdálená
--------------------
nějaká_tabulka




MySQL hodně vzdálená 2
--------------------
nějaká_tabulka2

Původně se jednalo o 1 databázi se 2 tabulkami a pohledem nad jejich joinem, jenže se ukázalo, že komunikace klientů s touto centrální databází je docela pomalá. Proto to bylo rozděleno na 2 databáze. Ta 3. cachovací má sloužit jen pro "pozorovatele" a má mít obsah těch následujících dvou (které nejsou v lokální síti s tou cachovací). Mým cílem je mít rychlý přístup k datům i když jsou zbylé 2 databáze těžko dostupné nebo i když vypadne spojení úplně.

[cronin]

To nie je struktura.

Idealne by bolo dat sem CREATE TABLE prikazy ... a samozrejme SELECT-y, ktore treba optimalizovat. Len tak sa da radit o potrebe ci zbytocnosti indexov a ich spravnom tvare.

Ono, ak je fakt otazka iba "index - ano alebo nie" tak vyskusat to je najjednoduchsie, nie?

[dustin]

Minimální potřebnou množinu indexů si můžeš zjistit pomocí explain.

[mykš]

Tím bych asi zjistil, že indexy budu potřebovat všude protože můžu řadit pomocí jakéhokoliv sloupce.

[AraxoN]

Na zoradzovanie index má vplyv len vo veľmi málo prípadoch. Skôr sa uplatní na stĺpce, ktoré sa vyskytujú vo WHERE, či v podmienkach JOIN.

[cronin]

Prave naopak. Index ma na zoradovanie vplyv, pretoze polozky su v indexe zoradene "by definition". Takze ak je potreba radit vysledok podla indexovaneho stlpca, staci sekvencne citat index a nic sa radit nemusi. Klauzula ORDER BY je snad najvacsim vykonovym zabijakom selektov a index tento problem vo vacsine pripadov elegantne riesi.

[okbob]

Pro jednoduché dotazy to možná platí, pro trochu složitější většinou nikoliv.

[AraxoN]

To platí za predpokladu, že sa podľa indexovaného stĺpca robí LIMIT-OFFSET a vo WHERE sa žiadny iný index nedá použiť. Vtedy má význam čítať index sekvenčne.