Vlákno názorů k článku evitaDB: spuštění, definice schématu a naplnění daty od Josef Marianek - Proc nepouzit klasicke SQL pribalene treba jako SQLite?...

Proc nepouzit klasicke SQL pribalene treba jako SQLite? Je k tomu urcite i nejake ORM, pokud se nekomu zda byt lepsi pracovat s java tridama. V cem je ta evitaDB lepsi?

Postupně se k tomu dostaneme v dalších dílech seriálu, ale můžu pár bodů vyjmenovat i zde:

- webová API ihned k použití (GraphQL, REST, gRPC)
- výrazně rychlejší odezvy oproti relačním DB pro "katalogové scénáře"
- podpora facet kalkulací, práce s cenami a hierarchicky organizovanými daty
- sjednocený způsob práce a dotazování skrz různé technologie - tj. jak pro frontendové, tak i backendové týmy
- CDC a streaming změn na klienty a další ...

Zopar veci ktore ma zarazili:
- Webove API fajn viem si urobit CRUD aplikaciu. Ale nepoznam aplikaciu ktora by nemala aspon nejaku minimalnu logiku. Existuje moznost upravit 'standardne' spravanie operacie? Ak nie nakoniec aj tak skoncim tak ze musim pred tu DB predradit aplikacny server a potom je to REST rozhranie skor nevyhodou.
- evitaDb je inmemory DB? Porovnavate vykonnost DB na cloude v kubernetoch? To by asi chcelo ferovejsie porovnanie. Ako si stojite voci inym inmemory databazam alebo noSql databazam?
- Price typ sa mi zda nezmysel, urcit strukturu ktorou definujem ceny ... neviem aky to ma zmysel, hierarchicke udaje sa daju asi nahradit rekurzivnymi query
- Ako je to so zabezpecenim (autorizacia/au­thentikacia) ked uz teda vystavujem REST sluzbu?

V aktuální verzi nemá databáze autorizaci / autentikaci - máme to v backlogu. Souvisí to s tím, jak databázi používáme a tím, že nás to zatím ještě tolik netlačí. Databázi nemáme otevřenou koncovým klientům, ale dalším vnitřním aplikacím, které nad tím staví další logiku.

Konkrétně je tam administrační část také psaná v Javě, která používá gRPC protokol a do databáze migruje data z primární relační databáze, zároveň používá evitaDB ke generování feedů, rozesílání e-mailů a dalších podobných úloh.

Vedle toho existuje Next.JS frontend, který má dvě části - serverovou, které říkáme middleware, a klientskou a ta už běží v klientově prohlížeči. Middleware obaluje GraphQL rozhraní evitaDB a přidává si tam věci navíc, zároveň federuje do jednoho GraphQL i další interní a externí REST služby, takže se to vůči koncovému klientovi tváří jako jedno velké GraphQL schéma.

Takže je to tak, jak píšete, máme tam předřazený aplikační server. Výhoda je, že ten si může sám vybrat protokol, se kterým se mu pracuje dobře. U Next.JS je to GraphQL, v Javě a C# to bude pravděpodobně spíše gRPC.

Díky tomu, že máme databázi "zavřenou" vůči vnějšímu světu, řešení autentizační issue posouváme a soustředíme se jiné funkce. Nicméně na to nezapomínáme a chceme to řešit.

Na význam ceny, která se na první pohled do struktury nehodí, odpoví příští článek. Prosím o trpělivost. Co se týká rekurzivních query, tak u nich jsme si prakticky ověřili, že na větších datech nejsou dostatečně rychlé.

Porovnání vůči in-memory databázím nedává smysl, pokud bychom neimplementovali klíčovou část katalogového API a testovali na shodných dotazech / datasetech. Toto jsme udělali pro PostgreSQL a Elasticsearch a zabralo to několik měsíců práce. Bohužel na víc testů už není prostor. Obecně nedává smysl ukazovat výkonnost řešení na jednom izolovaném dotazu, ale aby dávalo smysl, je nutné řešit na vzorku reálného provozu z nějakého řešení. Jinak se bude pořád jednat jen o "akademické diskuse".

Na vyse odpovede vam odpovie prvy clanok serie.

Jo, dekuju, mate pravdu. Ten prvni clanek serialu mne unikl. Presto - ja jsem konzervativni, kdyz to neni vylozene extra vyhodne pouzivam zabehane vzorce/standardy.

Běžíte stále LAMP? Jinak i od flat-files jsme se k RDBMS také museli nějak dopracovat.

To je určitě zdravý pohled na věc. Pokud vám dobře funguje to, co používáte, není důvod to měnit.

Nové komponenty musí přinést kvalitativní skok v nějaké oblasti, kterou řešíte - ať už výkon / snížení nákladů na provoz, nebo náklady na vývoj (můžu smazat spoustu řádků kódu, o které bych se musel starat sám), nebo jednodušší zapracování / shánění nových lidí (tj. levnější mzdové náklady).