Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

> Cache - jak, czym, kiedy
nospor
post
Post #1





Grupa: Moderatorzy
Postów: 36 559
Pomógł: 6315
Dołączył: 27.12.2004




Tematów o cache było sporo, jednak nie było jednego ogólnego, gdzie by były zawarte ogólne wskazówki.

Zapraszam do dyskusji
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
babejsza
post
Post #2





Grupa: Zarejestrowani
Postów: 407
Pomógł: 1
Dołączył: 4.03.2003
Skąd: warszawa

Ostrzeżenie: (0%)
-----


Hej,

pytanie do osób, które mają do czynienia na co dzień z cachowaniem, w szczególności z cachowaniem wyników zapytań. Wiem, że ten temat nie jest jednoznaczny więc i sama odpowiedź może być trudna, ale może ktoś pracuje w podobnej specyfice baz i jego doświadczenia będą bardzo pomocne.

Mianowicie w obecnej strukturze aplikacji posiadamy w bazie około 180 tabel o całkowitym rozmiarze ~20GB i objętości około 50 mln rekordów. Aplikacja jest narzędziem "ERP'owym" chodź ma szersze zastosowania niż te wynikające z definicji ERP, bo posiada modułu komunikacyjne, księgowe, kadrowe, zarządcze itp. Do tej pory jedyne cachowanie jakie było stosowane to cache dotyczący opcode, ale w związku z coraz bardziej rozszerzającą się bazą danych staje przed nami zadanie rozważenia i ew. wprowadzenia cachowania wyników zapytań do bazy.

Dla mnie największym problemem czy raczej pytaniem jest kwestia rozsądnego zarządzania cache. W tej chwili korzystamy z AWS aplikacja stoi wraz z bazą i storage na jednej instancji medium. Na razie nie chcę tego za bardzo zmieniać bo chciałbym zobaczyć co pod względem wydajności można wyciągnąć z takiej konfiguracji. Oczywiście można postawić odrębne instancje tylko pod bazę i odrębnie kolejne pod cache, ale nie o to mi chodzi.

To co od samego początku projektowania aplikacji było bardzo istotne to dostęp do najświeższych danych. Czyli ktoś wprowadza np. dokument do bazy a ktoś inny ma do niego od razu dostęp - to samo tyczy się wynikających z tego danych zarządczych. Takich dokumentów pojawi się w bazie około 5 tys. dziennie. Piszę o tym bo to dobrze zobrazuje jedne z moich problemów czyli to, że jeżeli nawet (upraszczam proces na potrzeby tego przykładu) będę zapisywał do cache wynik zapytania dotyczących dokumentów klienta to co kilka sekund przy dodawaniu nowego rekordu musiałbym ten wpis nadpisywać.

Drugą kwestią jest to, że ze względu na duże skomplikowanie systemu uprawnień i flag w samej bazie, każdy user odpytując bazę z tymi dokumentem wysyła inne zapytanie (różnią się niewiele, ale wystarczająco, żeby była potrzeba tworzenia nowych kluczy dla cache).

Czyli łącząc dwa powyższe problemy robi nam się sytuacja gdzie stosując cache dla zapytań INSERT, UPDATE, SELECT, DELETE dotyczących tej konkretnej tabeli co kilka sekund nadpisują się setki zapisanych w cache pozycji, a każda z nich niesie tak na prawdę tysiące rekordów.

No i tu to pytanie do Was, jak z Waszej praktyki powinno to wyglądać? Czy nie powinienem się przejmować i takie cachowanie pozostaje w granicach dozwolonych praktyk i mimo wszystko będzie wpływało pozytywnie na zasoby systemowe (tj. dzięki cache spadnie zapotrzebowanie na nie względem tego samego, ale pracującego na samej bazie). Albo może jednak to nie jest dobr praktyka i powinienem się w przypadku cache ograniczyć tylko do tych zasobów bazy danych które są w miarę statyczne (np. dane useów, klientów, kontrahentów) tj. dane które rzadko kiedy się aktualizuje, kasuje czy dodaje nowe.

Jeżeli chodzi o sam mechanizm do cachowania najprawdopodobniej będziemy się skupiać na APC. Wygląda na to, że w kwestii cachowania danych jest on porównywalny z memcached natomiast dużo lepiej sprawuje się w przypadku opcode, a dodatkowo ma się stać częścią php więc jako rozwiązanie natywne będzie łatwiejsze z zarządzaniu i ew. elastyczniejsze przy migracjach.

Z góry dzięki za podjęcie tematu i ew. dyskusję (IMG:style_emoticons/default/wink.gif) . Mam nadzieję, że dobrze zobrazowałem problemy (IMG:style_emoticons/default/smile.gif) .

Ten post edytował babejsza 2.12.2013, 00:32:27
Go to the top of the page
+Quote Post
cepa
post
Post #3





Grupa: Zarejestrowani
Postów: 125
Pomógł: 7
Dołączył: 27.01.2010

Ostrzeżenie: (0%)
-----


Cytat(babejsza @ 1.12.2013, 18:10:52 ) *
...


Pierwsze co weź pod rozwagę to czy potrzebujesz SQL? Czy korzystasz z transakcji? Czy potrzebujesz izolacji? Czy robisz locki na zasobach, itd itp? Jeżeli NIE, to zmień storage na NoSQL i przy takiej bazie nie idz w Mongo tylko Apache Cassandra. Z drugiej strony jak często potrzebujesz odczytywać dane i grzebac w warstwie persistence? Oraz jakie operacje wykonujesz? Czy robisz dużo sortowań? Czy masz tabele z milionami rekordów i potrzebujesz wyciągać spore porcje danych? Czy raczej operujesz w obrębie rekordu. Jezeli dużo operacji na zbiorach to SQL jest jednak prostszy w użyciu.

Zakładając, że trzymasz się SQL, to sorry ale "cachowanie" to proteza, która działa może przy blogu lub forum ale nie w systemie ERP. Polecam zainteresować się modelem CQRS (Command Query Responsibility Segregation), dodatkowo tematyka MOM (Message Oriented Middleware). Twój problem jest prosty do rozwiązania przykładowo za pomocą takiej architektury:

- operacje odczytu (Query / SELECT / HTTP GET) serwujesz z przygotowanego (cache) kontentu
- jezeli nie masz tego kontentu w cache to dany call jest zamieniany w Command i leci dalej czekając na wynik
- operacje zapisu (Command / INSERT, UPDATE, DELETE / HTTP POST, PUT, DELETE) odkladasz na kolejke (MQ) - pozwoli to kontrolowac przepływ i ilośc transakcji względem warstwy persistence
- komendy są zdejmowane z kolejki przez aktorów, którzy wykonują logike biznesową i generują wynik, zapisując go także w warstwie o niskim czasie dostępu (cache, np: memcache, redis, cassandra)

Mniej więcej taki proces powoduje, że dopoki aplikacja nie potrzebuje zmienić swojego stanu, nie ma potrzeby dotykać powolnej bazy danych, z drugiej strony eliminuje problemy z zapychaniem dostępu do bazy. Jest jeszcze jeden mega plus: zauważ, że jeżeli w kolejce masz więcej niż jedną operacje zapisu TEGO SAMEGO REKORDU, to możesz zdjąc z kolejki WSZYSTKIE starsze operacje i zapisać tylko najnowszy stan. W ten sposób mozna zmniejszyć ilośc transakcji w aplikacji, bez wpływu na generowane wyniki.

Go to the top of the page
+Quote Post

Posty w temacie
- nospor   Cache - jak, czym, kiedy   22.08.2012, 10:48:33
- - mrWodoo   Ok to pierwsze pytanie, własne czy gotowe rozwiąza...   22.08.2012, 17:39:30
- - erix   CytatOk to pierwsze pytanie, własne czy gotowe roz...   23.08.2012, 10:00:49
- - mrWodoo   a o MemCache pierwsze słyszę, z tym że, cache jest...   23.08.2012, 10:14:19
- - erix   Cache nie jest po to, żeby coś przechowywać. Jeśli...   23.08.2012, 11:41:16
- - mrWodoo   Ok, nie ma innego sposobu na MemCache w PHP oprócz...   23.08.2012, 12:34:16
- - erix   Masz jeszcze shm dostępne w akceleratorach. Z tą ...   23.08.2012, 12:37:07
- - starach   A nie da się zrobić z pamięci wirtualnego katalogu...   24.08.2012, 22:48:40
- - lukaskolista   Memcache to nie tylko przechowywanie danych w pami...   27.08.2012, 08:07:31
- - erix   CytatA nie da się zrobić z pamięci wirtualnego kat...   27.08.2012, 10:23:34
- - mrWodoo   czy każdy serwer z linuxem ma MemCache? np taki ho...   27.08.2012, 15:01:31
- - d3ut3r   Na Windows również możesz zainstalować memcache.   28.08.2012, 04:18:59
- - erix   Cytatczy każdy serwer z linuxem ma MemCache? Może ...   28.08.2012, 12:02:44
|- - murwazy   Cytat(erix @ 28.08.2012, 13:02:44 ) M...   8.09.2012, 11:53:24
- - wizu   Tak dla uściślenia, to zamiast memcache lepiej pos...   2.09.2012, 15:22:24
- - babejsza   Hej, pytanie do osób, które mają do czynienia na ...   1.12.2013, 18:10:52
|- - cepa   Cytat(babejsza @ 1.12.2013, 18:10:52 ...   25.01.2014, 15:52:50
- - phpion   Moim zdaniem jeśli do systemu bardzo często trafia...   5.12.2013, 12:17:26
- - ano   @babejsza - Ok, ale w czym dokładnie problem? Jaka...   6.01.2014, 22:15:23
- - babejsza   @phpion - zabrakło przecina po "cache". ...   7.01.2014, 10:10:02
|- - Dejmien_85   Cytat(babejsza @ 7.01.2014, 10:10:02 ...   14.02.2014, 06:20:42
- - ano   Cytat- operacje zapisu (Command / INSERT, UPDATE, ...   25.01.2014, 16:16:17
|- - cepa   Cytat(ano @ 25.01.2014, 16:16:17 ) Ar...   25.01.2014, 16:33:24
- - cepa   W 5.5 jest APCu, opcache to cache do opcodu, APC m...   14.02.2014, 06:38:41
- - pabito   czyli cachujac: Front-end używamy Varnish, kod PHP...   24.03.2014, 16:56:24
- - szajens   kiedyś czytałem że od wersji php 5.5 jest Zend Opc...   1.06.2014, 20:54:00
- - Pyton_000   Ja zapytam z innej beczki troszkę. Jakie macie met...   25.01.2015, 12:49:48
- - Crozin   Z racji na to, że rodzajów cache'a mogą być dz...   25.01.2015, 16:25:15


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 17.10.2025 - 10:38