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í.

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