Hlavní navigace

Názor k článku Na co si dát pozor při návrhu databáze? od Zdeněk Merta - To, co popisujete je technika, která se jmenuje...

  • Článek je starý, nové názory již nelze přidávat.
  • 18. 11. 2016 11:46

    Zdeněk Merta (neregistrovaný)

    To, co popisujete je technika, která se jmenuje Event Sourcing. S CQRS nemá nic společného, kromě toho, že se často pro implementaci CQRS používá.

    CQRS je obecně velmi jednoduché. V podstatě pouze rozděluje systém na 2 části:

    1. Write (Command) část sloužící pro zpracování operací, které mění stav systému.
    2. Read (Query) část sloužící pro operace, které nemění stav systému - čtení a dotazování.

    Na obě části jsou často kladeny jiné požadavky co se týče výkonnosti a škálování. Rozdělením je možné je optimalizovat nezávisle na sobě.
    Např. U spousty aplikací je výrazně méně Write operací než Read operací.

    Je nutné zdůraznit, že CQRS není top level architektura, ale je často vhodná pouze na malou část aplikace.

    Event Sourcing se velmi často používá pro implementaci Write (Command) části, ale není to pravidlo.

    Co se týče použití PostgreSQL nebo jiné relační databáze, tak jediná odpověď je: "It depends..."

    Vždy je potřeba si klást otázky.

    Na jakou část chcete relační db použít? Write? Read? Obě?
    Jaké množství dat budete zpracovávat?
    Jaký výkon požadujete?
    Jak budete jednotlivé části škálovat?
    Jaké typy dotazů budete klást na Read část?

    Relační db pro Write část:
    Jedno z doporučení implementace Event Sourcingu zní: "Nepište vlastní Event Store"
    Existuje spoustu řešení nad relačními (i jinými) databázemi a fungují dobře až do doby než se dostanete přes určitou hranici počtu událostí.
    Lepší je použít specializované řešení, přece jen je to specifický způsob ukládání dat a specializovaný systém toho umí využít. Často také má implementovánu spoustu šikovných funkcí.
    Tím nechci říct, že by se nedal napsat dobrý Event Store nad relační db. Jen je potřeba být připravený na možné problémy.
    Na malém systému se s nimi často nesetkáte.

    Relační db pro read část:
    Tady myslím na problémy nenarazíte. Záleží spíše na typech dotazů. Někdy může být výhodnější použít NoSQL databáze, paměť nebo i něco úplně jiného.

    Jinak příklad faktur je pouze vymyšlený příklad nebo něco reálného? Nenapadá mě důvod, proč by v běžné aplikaci měly být faktury implementovány pomocí Event Sourcingu.