Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Nejlepší cache je žádná cache

209 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Nejlepší cache je žádná cache

  1. 1. Nejlepší cache je žádná cache @ProchazkaFilip
  2. 2. 1+N M*N
  3. 3. Relační schéma a normální formy relací
  4. 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. 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. 6. Cachováním pomalých dotazů řešíte důsledek, nikoliv příčinu
  7. 7. Denormalizace máme normalizované relace a vědomě z nich vytváříme nenormalizované
  8. 8. Proč denormalizace? čtení a filtrování nenormalizovaných relací je rychlejší
  9. 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. 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. 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. 12. Díky za pozornost! Dotazy? @ProchazkaFilip

×