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

Martin Konečný (pavelco1998)

Tvůrce

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

Pavel

Tvůrce

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

Martin Konečný (pavelco1998)

Tvůrce

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

Pavel

Tvůrce

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

Richard

Člen

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č!

Pavel

Tvůrce

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

Richard

Člen

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č!

Neaktivní uživatel

Tvůrce

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

David Hartinger

Vlastník

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

Pavel

Tvůrce

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ý!

Najčastejšie vyhľadávané

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