Cache - jak, czym, kiedy Opcje

[nospor]

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

[ano]

- 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

Czyli każdy select do bazy danych opakowujesz w swoją kolejkę *MQ? Jaki w tym sens?
Serwery same posiadają mechanizmy kolejkowania żądań - po co robić na to kolejną/możliwie awaryjną warstwę abstrakcji?!

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

Jak z kolejki zdjąć inne operacje dla tego samego rekordu? ...

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:

Architektura która opisałeś to przecież nic innego jak zwykłe cacheowanie wynikow zapytań do bazy danych, z dodanymi "protezami" w postaci własnych kolejek.

Nie ma sensu ich wprowadzać tylko żeby zastosować throttling w bazie danych. Przy połączeniach z zewnętrznymi systemami/webservices - ok, ale do własnej bazy danych?! Jaki w tym cel?

Ten post edytował ano 25.01.2014, 16:21:56

[cepa]

Architektura która opisałeś to przecież nic innego jak zwykłe cacheowanie wynikow zapytań do bazy danych, z dodanymi "protezami" w postaci własnych kolejek.

Zupełnie źle mnie zrozumiałeś (IMG:style_emoticons/default/smile.gif) Ja nie kolejkuje "zapisów do bazy" czyli gołych upsertów, tylko kolejkuje transakcje biznesowe. Przykładowo, aktor uruchamia serwis np: generujący dane do wyświetlenia aktualnego stanu konta użytkownika wraz z np: billingiem i statami, korzysta z najróżniejszych warstw persistence i innych serwisów, tak długo jak użytkownik nie będzie zmieniał stanu swojego konta, tak długo nie ma potrzeby odswieżania tych informacji, a jeżeli wygenerowanie ich zajmuje relatywnie dużo czasu, bądz obciąża zasoby, a użytkownik ma interakcje z systemem w między czasie, jest możliwośc zdjęcia tych transakcji, których wynik będzie już nieaktualny zanim aktor wykona daną transakcje. Inna sprawa, wiele serwisów szybciej oblicza wynik, niż jest go w stanie zapisać, architektura tego typu, pozwala na uzyskanie wyniku zanim "spłynie" on do warstwy persistence. Po prostu działa to asynchronicznie względem wejścia czyli np: interfejsu webowego.

U nas, podobna architektura sprawdza się doskonale w usługach restowych, umożliwiając niemal liniowe skalowanie i kontrolowanie przepływu informacji przez legacy sql, a mówie wielu milionach użytkowników.

PHP to dość debilna technologia i ze współbierznością ma niewiele wspólnego, ale tego typu rozwiązania są jak najbardziej w użyciu np: Akka.io w Scali.