IT rekvalifikácia. Seniorní programátori zarábajú až 6 000 €/mesiac a rekvalifikácia je prvým krokom. Zisti, ako na to!

Diskusia – DB wrapper s využitia súborové cache

Späť

Upozorňujeme, že diskusie pod našimi online kurzami sú nemoderované a primárne slúžia na získavanie spätnej väzby pre budúce vylepšenie kurzov. Pre študentov našich rekvalifikačných kurzov ponúkame možnosť priameho kontaktu s lektormi a študijným referentom pre osobné konzultácie a podporu v rámci ich štúdia. Toto je exkluzívna služba, ktorá zaisťuje kvalitnú a cielenú pomoc v prípade akýchkoľvek otázok alebo projektov.

Komentáre
Avatar
Martin Konečný (pavelco1998):26.7.2015 22:49

Nejsem si úplně jistý, jestli je dobré do cache ukládat data jako nastavení uživatele. Co když si nastavení změní? Budeš měnit data i v cache, budeš ji během úpravy mazat, aby se příště nenačetla špatná data?

Odpovedať
26.7.2015 22:49
Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ
Avatar
Pavel
Tvůrce
Avatar
Odpovedá na Martin Konečný (pavelco1998)
Pavel:26.7.2015 23:07

Ahoj,
právě si myslím že ano.
Příklad u tebe: Aura 113, Komentářů 759, článků 7 atd - jestli po krátkou dobu (30 sekund) budeš mít třeba místo článků 760 asi už nehraje velkou roli.
Pavel

 
Odpovedať
26.7.2015 23:07
Avatar
Odpovedá na Pavel
Martin Konečný (pavelco1998):26.7.2015 23:23

Jasný, takže těmto datům hodíš časovou expiraci, aby to dotaz/y ušetřilo alespoň na nějaký čas, chápu to správně?

Odpovedať
26.7.2015 23:23
Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ
Avatar
Pavel
Tvůrce
Avatar
Odpovedá na Martin Konečný (pavelco1998)
Pavel:26.7.2015 23:36

jj přesně tak.. a tím zabiješ 2 mouchy jednou ranou..
1/ šetříš dotazy do DB
2/ je to rychlejší

Pavel

 
Odpovedať
26.7.2015 23:36
Avatar
Richard
Člen
Avatar
Richard:27.7.2015 5:00

Jsem z toho poměrně nesvůj, metodika testování není úplně ok.
Nedokážu si představit na jakou aplikaci bych to chtěl nasadit a proč vůbec zbytečně zatěžovat disk, kterej toho už má stejně na práci hodně, když ta data jsou uložená v cache databáze - tzn v oproti disku superrychlé paměti.

Disk je často úzký hrdlo aplikace a pokud není, může se jím kdykoliv stát, nemohl bych mít čistý svědomí kdybych věděl, že byť jeden dotaz mi může zabít celou aplikaci.

Když už dělat takový věci, určitě to netahat na disk, ale do tmpfs, kde získáš rychlost paměti a vyhneš se potencionálním problémům (celkem by mě zajímaly výsledky pokud cache bude v tmpfs, lze je dodat?).

Ale celkem zajímavý, mam tahle šaškárny rád a taky leccos zkouším :-), určitě budu čekat na další díl.

PS. Oprav tu v tabulce hodnotu 1 na 10.

Odpovedať
27.7.2015 5:00
$action = $_GET['Life']; | Když dáš mínus, napiš proč!
Avatar
Pavel
Tvůrce
Avatar
Odpovedá na Richard
Pavel:27.7.2015 8:24

Ahoj,
No, co se tyce disku - pokud mas koupeny hosting, tak uloziste DB sdilis s nekolika - a to hodne - uzivateli. Pak diskove pole s diskama 15000 otacek za minutu nebude mit problem. A pokud mas vlastni VPS server, pochybuji ze bude optimalizovan na DB ( 20gb pameti apod.), pak prave ulozeni na disk muze byt reseni. Vlastni DB na VPS je taky ulozena v souborech na disku a pokud nacitaz najednou z vice tabulek do 1 dotazu, tim hur. Jednotlive tabulky maji kazda svuj soubor (vlastne nekolik).

Co se tyce tmpfs - asi si necetl cely clanek, ale nedokazu si prectavit napriklad 20 000 zaznam v tmpfs. I kdyz dokaze swapovat, ale pak je to to same co pisu - ukladat do souboru jednoduchym zpusobem.

K testovaci metode - vlastni test sem prave provedl 1000 za sebou, aby prave data z DB byli nacitany z databazove cache a bylo u nich zaruceno co nejrychlejsich vysledku - ostatne i toto jsem v clanku psal.

Pavel

P.S. omlouvam se za diakritiku, pisu z mobilu

 
Odpovedať
27.7.2015 8:24
Avatar
Richard
Člen
Avatar
Odpovedá na Pavel
Richard:27.7.2015 8:42

Co znamená optimalizace vps pro databázi? To mi úplně není jasný.
Článek jsem četl 2,5 krát, se snahou pochopit proč vlastně tohle používáš. Proč by měl být problém mít 20 000 záznam v tmpfs? My v tmpfs máme celé databáze co mají 40GB a nemáme problém.
Logicky pokud nemáš paměť tak tmpfs nebo ekvivalenty nepoužíváš, o swapování nemůže být řeč.

Už z principu bych nenahrazoval systémovej proces vlastním řešením, protože i když se to možná nezdá, tak dopad na výkon je značný. Pokud budeš používat čistě mysql cache, tak připojenej k databázi už jsi, odešleš dotaz, tam je jen takový mikro režie, a cache vrstva okamžitě vrátí z paměti výsledek, když k tomu použiješ vlastní cache a ještě k tomu na pomalym disku, tak režie je mnohem větší.

Udělej pořádný testy a uvidíš. Na pokusy super, zajímavá věc, ale do produkce bych to nedal.

Odpovedať
27.7.2015 8:42
$action = $_GET['Life']; | Když dáš mínus, napiš proč!
Avatar
Odpovedá na Pavel
Neaktivní uživatel:27.7.2015 10:49

Nevím, zda to tu někde nebylo zmíněno, ale dalo by se kontrolovat, zda přes ten DB wrapper neupravuješ tabulku, jenž je uložená v paměti, pokud ano, tak by se smazala. Nemusel bys nic řešit s expirací, neboť bys věděl, že tabulky ve tvém cache souboru budou určitě aktuální.

Co se týče ukládání na disk, nemyslím si, že by to bylo nějak optimální. Spíš bych udělal ukládání do proměnné v rámci jednoho skriptu. Někdy prostě potřebuješ zavolat dvakrát stejný dotaz, tak by se o to ten wrapper postaral a vytáhl ho z proměnné. ;)

Odpovedať
27.7.2015 10:49
Neaktivní uživatelský účet
Avatar
David Hartinger
Vlastník
Avatar
David Hartinger:27.7.2015 12:07

Zaznělo zde spoustu zvláštních tvrzení, které bych rád uvedl na pravou míru. Cachování na disk je naprosto běžné, servery mají rychlé disky (někdy i SSD), takže úspora času je obrovská. Uvědomte si, že cachujeme výsledky, to znamená, že šetříme čas, kdy databázový stroj vyhledává, třídí a podobně. Samotný čas nahrání již nalezených a setříděných dat je zanedbatelný. Cachovat můžeme samozřejmě i do paměti RAM, což je ještě rychlejší, ale někdy je problém zajistit, aby se cache sdílelo mezi PHP procesy (se souborem tento problém není). Každá databáze sama cachuje výsledky stejných dotazů, proto je nesmysl něco takového dělat, když už to tak funguje. Tento cache se odlišuje tím, že vrací staré výsledky v případě, že existují nové, zatím co vestavěný MySQL cache vrací staré výsledky jen tehdy, když se tabulka od té doby nezměnila. S rozumným časovým intervalem toto zastarání nevadí a je přínosné pro výkon aplikace. K tomuto článku jsem měl původně ještě nějaké připomínky na doplnění, autor je tam bohužel nepřidal a kolega to již publikoval. Myslím, že to co jsem napsal by tam mělo být někde výrazně uvedeno a to včetně faktu, že MD5 není unikátní a musí se řešit kolize.

Odpovedať
27.7.2015 12:07
New kid back on the block with a R.I.P
Avatar
Pavel
Tvůrce
Avatar
Odpovedá na Richard
Pavel:27.7.2015 12:47

No pokud mate k dispozici vlastni server s 64gb pameti tak je to mozne mit jen 40 gb dat v tmpfs. Ale to nema rozhodne kazdy jako ty. 90 procent pouziva normalni webhosting, tak tvoje reseni je hodne specificke.

S tim VPS myslim ze zakladni nabidky jsou hodne skoupe zrovna na pamet kterou DB potrebuje (u Wedosu zakladni balicek 1gb, ostatni jeste mit). Jak jsem psal vys, nesmis to brat na tvoje specificke podminky.

A i tento test prokazal rychlejsi pristup mensich soubotru nez nacitani microrezie DB.

Jinak souborove cache jsou v php jiz pouzivany treba v redakcnich systemech (napr. Fusion a myslim ze i Nette), i kdyz bloku html a nemyslim si, ze by to byl nejaky zasadni problem, kdyz se na tom shodl vyvojovy team. Ale na tom se asi neshodnem :-)

Pavel

 
Odpovedať
27.7.2015 12:47
Robíme čo je v našich silách, aby bola tunajšia diskusia čo najkvalitnejšia. Preto do nej tiež môžu prispievať len registrovaní členovia. Pre zapojenie sa do diskusie sa zaloguj. Ak ešte nemáš účet, zaregistruj sa, je to zadarmo.

Zatiaľ nikto nevložil komentár - buď prvý!