Vlákno názorů k článku Na co si dát pozor při návrhu databáze? od freoinewrlnvfwl - Pekny clanok prinasajuci imho informacie z rannej praxe...

Pekny clanok prinasajuci imho informacie z rannej praxe vacsiny developrov (teda koderov, nie DB specialistov). Kedze i ja som koder, mam otazku k DB ludom.

Ma zmysel pouzivat postgresql pri CQRS (Command Query Responsibility Segregation) pristupe?

CQRS=> Vsetky zapisujuce operacie tlacia data do "zurnalovej"/event tabulky. Stlpce su ID, idAgregatu (napriklad faktury) a event (udalost, napriklad json stlpec). Teda operacie nad fakturami su rychle, lebo je to append only. Ked niekto ide citat nieco, co sa tyka faktur, tak CQRS vravi, ze pre casto pouzivane operacie je dobre mat query model.

Teda napriklad pre operaciu ziskania faktur spolu so sumou, adresou dorucenia a cenou by bola tabulka s idAgregatu (faktury) a jsonom (alebo jednotlivymi stlpcami). Dopyt na read operaciu sa vybavy rychlo. Vpodstate je to len podanie jedneho riadku tabulky ziadatelovi. Toto pekne funguje, len pri castych updatoch velkych dokumentov, sa moze stat, ze sa updatuje json dokument o velkosti niekolko kb. Je to pre postgresql OK, alebo treba v tomto stave uvazovat nad nejakou nosql DB, alebo zmenit pristup k perzistovaniu QM, alebo to riesit inym sposobom? (niektore QM=predpripravene odpovede k agregatom; sa zvyknu drzat v pamati iba a predvypocitavat pri starte app)

PS: Prepojenie eventov a update query modelu je asynchronne a QM je teda "eventualy consistent". Prosim nerieste tento aspekt cqrs pristupu (vpodstate strata transakcnosti na prvy pohlad), ale len otazku. Teda vhodnost/nevhodnost postgresql na ukladanie/upda­tovanie/citanie "dokumentov" (velkost zvacsa okolo kilobajtu, par vynimiek okolo 100kB).

„...NoSQL databáze oproti relačním databázím umí mnohem hůře hromadné operace - přístup k položkám v JSONu je mnohem pomalejší než sekvenční čtení flat záznamů v relační databázi.“
Samozřejmě, ale jen do okamžiku, než budete muset udělat JOIN nebo čtení z další tabulky tam, kde byste v JSONu sáhnul do podseznamu, což je u netriviálních objektů běžné.
Mimoto v RDB probíná vyhledávání v celých indexech tabulky všech entit jednoho typu (často statisíce záznamů), protože RDB (jak jsem zmiňoval) neumí ukládat seznamy, kdežto dokumentová či objektová DB může využít vyhledávání jen v příslušných seznamech omezených množin entit, což může činit rozdíl množství řádů.

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.

Priklad faktur bol vymysleny. Dany pristup (teda event sourcing po spravnosti) pouzivame na viacere (ale nie na vsetky) veci v jednej casti systemu na spracovanie dat. Funguje vyborne a vcelku aj skaluje (dajme tomu nad jednym agregatom ~100k eventov mesacne). Na event store zvazujeme pouzitie kafka serveru, ale zatial vykonnostne postacuje aj postgresql tabulka.

Co sa tyka read casti, tak tam dost dodrzujeme to, ze data su ulozene vo formate/forme, v akom sa poskytuju dalej. Ziadne dohladavania/joiny. Nacitanie z postgresql je vzdy nacitanie jedneho riadku (json/text bunky vpodstate) a nasledne bud priamo preposlanie klientovi (dalsia interna aplikacia), alebo jemne upravenie/pre­formatovanie/o­sekanie v servise. Tu je samozrejme nutne ten json sparsovat a nasledne opat poskladat, ale povaha problemu dovoluje taketo zdrzanie. Ide skor o prietok a ten je mozne pekne skalovat pri dostatocnom pocte procesorov.

Zaujimalo by ma, ci je nejaka prakticka skusenost porovnavajuca napriklad updatovanie casu posledneho pristupu ku kontu poouzivatela (pouzivatel ako agregat) v QM perzistovanom v DB, kde by bol zvoleny json pristup verzus pristup relacnej databazy (napriklad 25 stlpcov, kde jeden je cas posledneho pristupu). Teda rozdiel vykonu pri updatovani jsonb hodnoty s 25 atributmi, verzus updatovanie jednej bunky v tabulke s 25 stlpcami. Je to horsie ako o jeden rad napriklad?

Dakujem za dodatocne informacie.

Na event store zvazujeme pouzitie kafka serveru, ale zatial vykonnostne postacuje aj postgresql tabulka.

Kafku sice moc neznám, ale nepřijde mi jako vhodné řešení pro Event Store
(ale vím, že ji někteří používají a v dokumentaci byla o Event Sourcingu zmínka)

Problémy, které vidím:

1. Pro uložení každého Aggregate (když se budeme bavit v terminologii DDD) potřebujete vlastní Event Stream. Kafka tento koncept nemá a Event Stream by musel být řešen pomocí Topic. V aplikaci můžete mít miliony Aggregate, zvládne to Kafka?
2. Kafka není zamýšlena na dlouhodobé ukládání zpráv, definuje se po jak dlouhé době jsou odmazány. Sice lze nastavit, aby se nemazaly, ale nebylo to takto zamýšleno.

Zkuste se podívat na Event Store

Pro toto existují zvláštní databáze, ale zkušenost s tím nemám. Každopádně hledání dle klíče je základním požadavkem pro dokumentové, key-value i relační DB, se samotným typem DB to tedy příliš nesouvisí, podstatné je, že nejvýhodnější uložení dat je dáno požadovaným použitím.

Jediná použitelná specializovaná databáze pro Event Sourcing (nejen pro něj) je Event Store (o dalších alespoň nevím). Používám ji bez problémů.
Na Lambda meetupu jsem měl na toto téma prezentaci (je tam i odkaz na video)
https://www.meetup.com/Lambda-Meetup-Group/events/220671173/

NEventStore databáze není, je to jen implementace Event Sourcingu nad běžně dostupnými databázemi.

Skvělé, konečně příspěvek k rozšíření obzoru.