Temat: Cache trochę inaczej

Witam,

pomysła mam ,  pomysła ciekawego, na cache'owanie danych w kłejku. Być może kejk w tej chwili "umi" już tak jak ja chce, ale pewnie nie do końca. Mam zamiar napisać behaviora  + model  lub  plugin, który zapewni cacheowanie danych z bazy przy czym,  dane dostaczone do użytkownia końcowego nigdy nie bedą przeterminowane (nie będzie on musial czekac na  koniec zycia danego cache'u zeby zobaczyc odswieżone dane) - cache sam się będzie odswieżać  przy najmniejszej zmianie w spodziewanym zestawie rekordów - taki Real Time Cache - ważny np w przypadku wyników sportowych, które muszą być serwowane bez żadnych opóźnień.

Całość zakłada dodanie do tabel, z których dane będą cacheowane, pola modified int(10) - czyli będzie można powiedzieć kiedy dany rekord był zmieniony z dokładnością co do 1 ms, albo inaczej kiedy ostatnio jakikolwiek rekord ze spodziewanego zestawu rekordów był ostatnio modyfikowany -  rekord o najwyzszej wartosci modified jest ostatnim zmienionym/utworzonym  rekordem  - będzie to jedno z dwóch kryteriów świadczące o zmianie  w  zestawie spodziewanych rekordów.

Drugie kryterium to ilość rekordów, które zostaną zwrócone po uwzględnieniu warunków zapytania.

mając np takie 3  rekordy  w tabeli (id,name, modified)
3 , n3 , 1276891296
2 , n2 , 1276891200
1 , n1 , 1276891100

Keszując dane i sprawdzając tylko wartość pola modified nie zauważymy  usnięcią  rekordów z modified  niższym niż najwyższe w czasie ostatniego keszowania.

Czyli porównując ilość rekordów w cache + czas ostatnio zmodyfikowanego rekordu , z iloscią rekrdów i czasem jakie zwroci baza po wykonaniu zapytania będzie wiadomo czy cache należy odświeżyć czy nie.

Dodatkowo można sprawdzać z jakimi argumentami została odpalona metoda probujaca uzyskać dostęp do danych (func_get_args() ), w przypadkach gry rekord nalezy do danego użytkowika.

Jakieś sugestie co do powyższych założeń ?

O ile sprawa jest prosta w przypadku modeli bez asocjacji, to trochę zaczyna się komplikować w przypadku asocacji, zwłaszcza tych bardziej złożonych, ale narazie nie zabrnałem aż tak daleko w moich przemyśleniach, sugestie mile widziane i do tej części.


+ Takie tam założenia na przyszłość :
Cache powinien być plikowy  - wszystko zapisywane do pliku (File albo APC), ale tzw gorące dane powinny trafiać do bufora  memcached, okresowo cronem można dane ktore już ostygły wywalać z bufora.

Ostatnio edytowany przez rob_zombie (2010-06-18 22:44:22)

2

Odp: Cache trochę inaczej

szczerze to nie przekonuje mnie Twoja metoda - teoretycznie to dziala ale tylko dla 1 modelu. a co w sytuacji gdy np mam model Wiadomosc i pokazuje uzytkownikowi widok jego skrzynki odbiorczej - przy kazdej wiadomosci jest avatar nadawcy - jak chcesz Twoja metoda sprawdzac aktualnosc np avatara nadawcy (ktory moze byc zmieniony przez uzytkownika w kazdej chwili) ?

3

Odp: Cache trochę inaczej

rob_zombie napisał/a:

O ile sprawa jest prosta w przypadku modeli bez asocjacji, to trochę zaczyna się komplikować w przypadku asocacji, zwłaszcza tych bardziej złożonych, ale narazie nie zabrnałem aż tak daleko w moich przemyśleniach, sugestie mile widziane i do tej części.

Zakladam uzycie oryginalnych metod klasy Model, albo napisac wlasnych, ktore beda dzielic wywolanie find na osobne zapytania, wtedy logika o ktorej pisalem bedzie dzialac bez zarzutu.

Do tej pory klepnalem juz behaviora + model, jak narazie, podmaska, automatycznie zbyt wiele sie nie dzieje,  ale pobieranie  + odswiezanie danych dziala (po recznym rozbiciu asocji kilku modeli uzywanych w 1 wywoalniu - w tym konkretnym przypadku zmiana danych jednej tabeli powoduje odswiezenie cache'u danych pochodzacych tylko i wylacznie z tej tabeli).

Ostatnio edytowany przez rob_zombie (2010-06-20 23:32:50)

4

Odp: Cache trochę inaczej

Mnie się nie podoba sprawdzanie ilości rekordów i decydowanie czy cache jest aktualny.

Dobry cache to taki, że
- przed wywołaniem find'a wiesz jak się nazywa plik, w którym wyniki wykonania find'a z danymi parametrami mogą się znajdować
- jeśli pliku nie ma - wywołuję find'a i zapisuję cache

Pliki cache mogą się nazyważ ModelName_jakiś_unikalny_string_wyliczalny_z_argumentów_find
Wtedy w afterSave (Delete itd.) możesz usuną pliki cache ModelName_*

Gdyby to zrobić ze sprawdzaniem ilości to w pesymistycznym wypadku wykonujesz
Select count(*) from news;
unserialize($dane_z_pliku_cache);
// ilość się nie zgadza
Select * from news;

To już lepiej od razu wykonać Select * from news; i włączyć memchache.

5

Odp: Cache trochę inaczej

id02009 napisał/a:

Mnie się nie podoba sprawdzanie ilości rekordów i decydowanie czy cache jest aktualny.
.
.
.

Pliki cache mogą się nazyważ ModelName_jakiś_unikalny_string_wyliczalny_z_argumentów_find
Wtedy w afterSave (Delete itd.) możesz usuną pliki cache ModelName_*

Problem w tym ze w moim p[rzypadku, nie cala aplikacja dziala pod kontrola kejka, i nie zmieni sie to dosyc szybko.  O ile w ogole.


id02009 napisał/a:

To już lepiej od razu wykonać Select * from news; i włączyć memchache.

Wszystko zalezy od wielkosci bazy. Tutaj baza jest ogromna. Pozatym moge wykorzystac triggery do uaktualniania counterow, i procedury do ich pobierania / tworzenia gdy counter ma wartosc 0. Wtedy cala operacja ogranicza sie do prostego selecta.

Ostatnio edytowany przez rob_zombie (2010-06-22 12:00:55)

6

Odp: Cache trochę inaczej

po co kombinowac... piszesz druga nasza klase zeby myslec o tym?
teraz serwery sa tanie, silne, wiec nie trzeba kombinowac az tak..

pozatym, kesz ktory jest w kejku w zupelnosci wystarczy (np. memcache), dorzucic do tego apc i serwer wytrzymuje 3x wieksze obciazenie...

7

Odp: Cache trochę inaczej

m1chal napisał/a:

po co kombinowac... piszesz druga nasza klase zeby myslec o tym?
teraz serwery sa tanie, silne, wiec nie trzeba kombinowac az tak..

ech ...

Nie kazdy wykorzystuje kejka do napisania bloga z 10 postamia i 100 odwiedzinami w roku.

Aplikacja dziala na mniej wiecej takiej infrstrukturze :

- load balancer
- server 1
- server 2
- server amazon do skladowania obrazkow
- "kluster" baz danych ( db server 1 , db  server 2)
- backup db server.

Tygodniowy przyrost bazy to 200 - 300 mb do 1 gb porywach.

Gdybyl chcial w taki prymitywny pssob uzywac memcached, to zainstalowalbym go jako modul bazy danych bo jest i taka mozliwosc, i dopadala by mi grzebanina w php.

m1chal napisał/a:

pozatym, kesz ktory jest w kejku w zupelnosci wystarczy (np. memcache), dorzucic do tego apc i serwer wytrzymuje 3x wieksze obciazenie...

Cache ktory masz w keju serwuje nieaktualne dane, co w moim przypadku jest niedopuszczalne.

Ostatnio edytowany przez rob_zombie (2010-06-24 22:54:15)

8

Odp: Cache trochę inaczej

wow - szacunek, z ciekawa aplikacja walczysz smile natomiast to co napisal id02009 ma sens i ludzie to juz implementuja - czyli przeciazenie metody find, a kluczem cache jest zserializowana tablica parametrow. polecam lekture kodu zrodlowego croogo (taki cmsik w cake):

http://github.com/croogo/croogo/blob/ma … _model.php

9

Odp: Cache trochę inaczej

Aplikacja jak aplikacja, powstala 2 lata temu i poczatkowo dziala na 1 serwerze ( http, db , storage, wisio), nie przewidywalismy takiego zainteresowania - stad kejk , potem zainteresowanie wzroslo , wymagania klientow tez, wiec trzeba bylo skupic sie na rozbudowie. Rozwiazanie ktore mi chodzi po glowie, to rozwiazaie dorazne, docelowo v2 bedzie przeprojektowane i napisane w pythonie/ django.

Tak jak pisalem, czesc aplikacji dziala w ramach radosej tworczosci kilku klepaczy kodu, i grzebanie w kodzie przypomina poruszanie sie po polu minowym - wiec dopisanie callbackow w tym czyms odapada - z ciekawostek to widzialem klase o dlugosci kodu  na kilka kilo linijek, oczywiscie bez komentarzy, ktorza robi wszytsko lacznie z parzeniem kawy.

10

Odp: Cache trochę inaczej

rob_zombie napisał/a:

Nie kazdy wykorzystuje kejka do napisania bloga z 10 postamia i 100 odwiedzinami w roku.

Aplikacja dziala na mniej wiecej takiej infrstrukturze :

- load balancer
- server 1
- server 2
- server amazon do skladowania obrazkow
- "kluster" baz danych ( db server 1 , db  server 2)
- backup db server.

Tygodniowy przyrost bazy to 200 - 300 mb do 1 gb porywach.

heh, i tu ciebie zdziwie, bo pracuje przy projekcie ktory jest w top20 megapanelu i jakos moje rozwiazanie w 100% sie sprawdza i nie potrzebuje "kombinowania".. a jedyne co moge dodac to projekt nie ma 10 postow i 100u na rok wink

11

Odp: Cache trochę inaczej

ok dzieki za wszytskie sugestie.


m1chal jedno pytanie, czy wyswietlasz dane na stronach  z opoznieniem czy w czasie rzeczywistym ?