CQRS és read model

Célok

A lecke végére el tudod magyarázni, mit jelent a CQRS, miben különbözik az event sourcingtól, mi a read model, és mikor érdemes (és mikor nem) használni.

Miért kell?

Az írás és az olvasás igényei gyakran eltérnek. Az írásnál a szabályok betartása a fontos (egy rendelés érvényes-e), az olvasásnál a gyors, a képernyőhöz igazított adat (egy lista, amelyhez sok forrás adata kell). Ha ugyanaz a modell szolgál mindkettőt, az egyik fél kompromisszumra kényszerül.

Mi a CQRS?

A CQRS (azaz a parancs és a lekérdezés felelősségének szétválasztása) Fowler szerint azt jelenti, hogy az információ frissítésére más modellt használnak, mint az olvasására. A két modell általában külön objektummodell, gyakran külön folyamatban, néha külön adatbázissal. Greg Young nevéhez fűződik.

flowchart LR
  C["Módosító kliens"] --> W["Írási oldal: szabályok"]
  W --> D[("Írási állapot")]
  W -->|"változások"| P["Projektor"]
  P --> R[("Olvasási nézet")]
  Q["Olvasó kliens"] --> API["Lekérdezés"]
  API --> R

Read model

A read model (olvasási modell, materializált nézet) egy előre összeállított, a fogyasztó igényére szabott adatmásolat. Eseményekből vagy az írási oldal változásaiból egy projektor frissíti. Az olvasó egyetlen forrást kérdez, kevesebb szinkron függőséggel, mint ha kérés idején több szolgáltatásból kellene összeszednie az adatot.

Ára a késés: a nézet az írás után egy ideig elmaradhat, ezért a felületnek meg kell tudnia különböztetni a „feldolgozás alatt” és a végleges állapotot. A nézet újraépíthető, ha a forrás (események vagy az írási állapot) elég hozzá. A projektornak idempotensnek kell lennie, hiszen az események ismétlődhetnek.

Cache és a read model különbsége

A cache a lekérés költségét csökkenti, a read model pedig tervezett, tartós másolat. A cache frissítése lehet idő szerinti lejárat vagy eseményalapú érvénytelenítés. Az érvénytelenítés után egy lassú, korábban indult lekérdezés régi adatot írhat vissza, ezért verzióellenőrzés kellhet. A cache és a read model eltérő szerződést jelent: a read modelhez tartozik a forrás, a késés és az újraépítés szabálya.

Mikor érdemes, mikor nem?

Fowler szkeptikus: szerinte a legtöbb rendszernél a CQRS kockázatos komplexitást ad, sok rendszer megfelel egy egyszerű CRUD-modellnek, és a mintát az általa látott esetek többségében nem sikerült jól használni. Szerinte olyan területeken segít, ahol a modell összetett, az olvasás és az írás terhelése eltérő, és csak a rendszer egy bounded contextjére érdemes alkalmazni, nem az egészre. Ha csak a nehéz lekérdezések okoznak gondot, egy jelentési (reporting) adatbázis egyszerűbb lehet.

Szempontok szerint

Szempont	CQRS
Csatolás	Az olvasási modell függ a forrás változásainak szerződésétől
Skálázás	Az olvasási és az írási oldal külön skálázható
Adatkezelés	A nézet származtatott másolat; a gazda az írási oldal
Konzisztencia	Az olvasási oldal késhet (végső konzisztencia)
Költség	Két modell, projektor, újraépítés: jelentős

Gyakori tévhitek

Állítás	Pontosítás
„A CQRS-hez event sourcing kell.”	Nem szükségszerű.
„A read model az igazság forrása.”	Származtatott másolat; a gazda az írási oldal.
„A CQRS mindig gyorsítja a rendszert.”	Csak ott segít, ahol az olvasás és az írás igénye valóban eltér.
„A CQRS-t az egész rendszerre alkalmazni kell.”	Fowler szerint csak a megfelelő bounded contextekre.

Röviden

• A CQRS külön modellt használ az írásra és az olvasásra.
• A read model előre összeállított, késő, újraépíthető másolat, projektor frissíti.
• A CQRS nem azonos az event sourcinggal, és nem minden rendszerhez illik.
• Az olvasási modell frissessége a szerződés része.

Ellenőrző kérdések

1. Miben különbözik a CQRS az event sourcingtól?
2. Mi a read model, és mi az ára?
3. Mikor elég egy jelentési adatbázis a teljes CQRS helyett?

Források

• CQRS (Martin Fowler) — a minta, figyelmeztetések, az event sourcinghoz való viszony.
• What do you mean by “Event-Driven”? (Martin Fowler) — a CQRS mint a négy jelentés egyike.