Cześć.

Tworzę serwis na frameworku i będzie on miał charakter sklepu internetowego - więc wiadomo podstawową rzeczą będą atrybuty i wartości do nich.
Takich atrybutów może być ok. 15-20 (maks) i wartości atrybutów to ok. do 100 (zwykłe stringi nie przekraczające 25 znaków). Plus dodatkowo robię cache ORMa (w sensie pobieranie struktury kolumn). Ogólnie plików cache będę miał dużo - bo nie tylko atrybuty+wartości+orm wrzucam do cache - staram się wrzucać
do cache dane, które zmieniają się z częstotliwością raz na pół roku!

Zastanawiam się czy to jest wydajne rozwiązania - przy zapytaniach typu:

[SQL] pobierz, plaintext 
// SHOW COLUMNS FROM... [pobieramy z cache]
// SELECT * FROM table1
 
// SELECT COLUMNS FROM [j/w]
// SELECT * FROM table2
[SQL] pobierz, plaintext 

itd - czy to gra warta świeczki? Dodam, że atrybuty to serce serwisu więc wiadomo dużo requestów byłoby.
Obecnie pracuje na plikach (file cache) - ale jeśli serwerownia ogarnie konfiguracje to przerzucę się na APC.

/PS. Ważność cache ustawiam w zależności od ich zmiany - najcześciej jest to 7 dni.
Macie wyrobioną opinie odnośnie "pchania" wszystkiego do CACHE?

Są frameworki, Frameworki i FRAMEWORKI.

Cacheowanie jest oczywiście bardzo dobrym sposobem na odciążenie bazy danych i (czasami) samej aplikacji. Jeśli pytasz czy jest sens cache'ować - oczywiście tak. Tylko musisz zrobić to z głową, żebyś np. nie wyświetlił dwóch identycznych paneli edycji profilu dwóm różnym użytkownikom.

Jeśli masz jakieś dane zmieniające się raz na pół roku, to jak najbardziej jest sens ich cache'owania. Tylko musisz pamiętać o refreshu/usunięciu cache po każdej zmianie, żeby administrator nie musiał czekać 2 miesiące na zobaczenie zmian na liście atrybutów.

Tak czy siak - temat rzeka. Na pewno znajdziesz sporo ciekawych artykułów. Na forum na pewno dostaniesz lepsze odpowiedzi na konkretne pytania niż ogólne.

Jako ciekawostkę polecam lekturę o ciekawym rozwiązaniu - Cache Dependency z Yii

Wiadomo odświeżanie cache - podstawa. Nurtuje mnie jeszcze jedna kwestia - produktów będzie maksymalnie 20 i zastanawiam się czy wszystkie 20 upchać do cache (product_id, title, cover_image, description, seo_title, seo_description, itd) czy jednak darować sobie już to? Takie cache będzie już sporo ważyć (dzięki kolumnie "description")

Ja bym przestrzegł przed nadmiernym cachowaniem/buforowaniem danych szczególnie, tych które są newralgiczne i mają duże znaczenie przy użytkowaniu portalu/serwisu. Pomyślałeś co będzie np. przy restarcie systemu bo przykładowo prądu braknie?
Dane zalokowane w bazie danych są dużo bezpieczniejsze.

W moim frameworku są cztery metody cachowania.

- output cache - czyli cała strona (localne pliki)
- database cache - czyli wynik zapytania SELECT połączony ze ścieżką URI (lokalne pliki)
- variable cache - czyli standardowo klucz:wartość (lokalne pliki, memcache, apc)
- pyro cache - cachowanie wyniku wywołania metody dowolnego objektu (lokalne pliki)

Pamiętaj że MySQL też ma wbudowany cache, więc można spokojnie trzaskać prostymi zapytaniami, każde wykona się w 0,00008 sek.

Nie rozumiem do końca Twojej wypowiedzi Niktoś. Tylko, że system cache będzie opierał się na takim algorytmie:





i jestem kryty - w przypadku edycji/usuwania produktu - robie delete cache i ponownie wywołuje funkcje pobierzProdukty i spełni się pierwszy warunek

W sumie to po co cachować, skoro robi to MySQL?

@wNogachSpisz możnaby, także dodać cache serwera który przy odpowiedniej konfiguracji cachowałby natywne pliki jak obrazy(jpg,png itp), css'y.

Chodziło mi, że dane należałoby najpierw gdzieś umieścić na stałe(np.baza danych) i potem cachować(np. z bazy danych).
Bezpośrednie wrzucanie wszystkiego do cache jest bezsensowne.


Przy ewentualnym restarcie systemu , jeśli będziesz używał cache to utracisz bezzwrotnie wszystkie dane , gdyż pamięć jest niejako czyszczona. Po za tym cachować należy dane , które nie ulegałyby zmianie.

Wyciągać dane z bazy tylko po to, żeby za chwile te same dane w niej umieścić ( w nieco ptrzetworzonej formie ).
Efekt - program działa wolniej

Miałoby to sens, jeśli dane nie ulegałyby zbyt często zmianie(jak już wyżej pisałem).

Jeśli dane nie ulegają zmianie, to MySQL cachuje zapytania.
Nie jest aż taki głupi.

MySQL też jest dobrym storage'm dla cache'owanych danych. Robisz zapytanie z 10 JOIN'ami a jego wynik zapisujesz do bazy. Dzięki temu kolejne zapytanie o to samo (cache) będzie wykonane na podstawie PRIMARY_KEY, więc będzie o niebo szybsze.

Ależ ja nie twierdzę, że piszesz bzdury, wręcz masz rację. Cache MySQL+ natywny cache serwera w zupełności wystarczą. No, ale kto jak woli