Nejlepší cache je žádná cache

Rychlé představení dalšího způsobu jak pracovat s daty, který vám umožňuje snadněji řešit invalidaci cache, která se velice snadno stane opravdu komplexní.

Transcript

1. Nejlepší cache je žádná cache @ProchazkaFilip
2. 1+N M*N
3. Relační schéma a normální formy relací
4. Nenormalizované relace - duplikace informací - složité udržování konzistence, pokud je takové schéma “source of truth” - updatnout kategorii student znamená updatnout 2 řádky person_id person_name category_id category_name 1 Karel 1 Student 2 Milan 1 Student 3 Franta 2 Učitel
5. Normalizované relace - každá informace je v db jen jednou - snadné editace/mazání a úpravy schématu - 3NF je perfektní na ukládání relačních dat Ale... - u složitých relací s hodně JOINy mají db problém - problém se zhoršuje s narůstajícím množstvím dat - nejde vyřešit výměnou db (MySQL vs PostgreSQL) - ORM lazy loading id name 1 Karel 2 Milan 3 Franta id name 1 Student 2 Učitel person_id category_id 1 1 2 1 3 2
6. Cachováním pomalých dotazů řešíte důsledek, nikoliv příčinu
7. Denormalizace máme normalizované relace a vědomě z nich vytváříme nenormalizované
8. Proč denormalizace? čtení a filtrování nenormalizovaných relací je rychlejší
9. Jak denormalizovat - vytvoření “view” tabulky v současné db - triggery - plnění z modelu, při změně dat - cronjob / rabbitmq worker - materializovaný pohled - o synchronizaci se stará databáze - úplně jiná databáze - například ElasticSearch - plnění z modelu, při změně dat - cronjob / rabbitmq worker
10. Case-study použití ElasticSearch - na Rohlik.cz se kategorie “čerstvé” načítala ~15 vteřin - personalizace => nemožnost použít cache - přenesením logiky filtrování jsme se dostali pod ~4 vteřiny - ES data vyfiltroval a vrátil list IDček - o hydrataci z MySQL se starala Doctrine - zahozením hydratace produktů jsme se dostali na ~1 vteřinu - z ES se získávaly celé dokumenty - ty se obalily do Value Objectů bez mapování properties - stejné rozhranní - bez nutnosti měnit šablony - stále otřesně pomalé, ale už né kvůli výpisu produktů
11. Command Query Responsibility Segregation efektivní read z ElasticSearche v samostatném modelu modifikace dat přes Doctrine nad relační db v samostatném modelu http://martinfowler.com/bliki/CQRS.html
12. Díky za pozornost! Dotazy? @ProchazkaFilip