Jak a na čem testujeme

Tři nezávislé týmy implementují shodnou funkční specifikaci API a dotazovacího jazyka, která byla vydefinována na základě mnohaletých provozních zkušeností z FG Forrest, a.s..

1. tým staví svou implementaci nad relační databází PostgreSQL
2. tým staví svou implementaci nad no-sql databází Elasticsearch
3. tým staví implementaci na zelené louce jako in-memory no-sql databázi

Proces testování

Je vytvořena společná sada testů, která je k dispozici vývojářům všech tří týmů:

• funkční testy
• výkonnostní testy

Separátně si každý tým vytváří vlastní sadu jednotkových testů, které nejsou součástí výsledného hodnocení a slouží jen pro vývojové účely daného týmu.

Výkonnostní testy využívají nástroj JMH a mají dvojí charakter:

1. testy ověřující rychlost konkrétních jednotlivých funkcí databáze (např. pouze filtrace dle atributů nebo dle cen, či facetového filtru separátně)
2. syntetické testy ověřující celkovou rychlost databázi na vzorku reálných dotazů z produkčního prostředí

Reálné dotazy byly zaznamenávány po dobu několika dní na stávajícím řešení daného e-shopu (viz. další odstavce) do žurnálu. Následně byly konvertovány do struktury dotazů nad evitaDB a opětovně uloženy do žurnálového souboru. Tento žurnálový soubor je následně výkonnostním testem načítán a dotazy rozdělovány do paralelních vláken a postupně přehrávány nad snímkem (snapshotem) anonymizovaných produkčních dat, který byl vytvořen ve stejném období, v jakém byl snímán provoz na daném e-shopu. Dotazy i data tedy přibližně vzájemně odpovídají.

Výkonnostní testy používají tyto datové sady:

1. produkční anonymizovaná databáze e-shopu Senesi: 115 tis. produktů, 3.3 mil. cen, 3.8 mil. atributů, 965 tis. relací, 695 tis. JSON fragmentů dat
2. produkční anonymizovaná databáze e-shopu Signál nábytek: 15 tis. produktů, 120 tis. cen, 525 tis. atributů, 115 tis. relací, 90 tis. JSON fragmentů dat
3. produkční anonymizovaná databáze e-shopu Keramika Soukup: 13 tis. produktů, 10 tis. cen, 265 tis. atributů, 55 tis. relací, 43 tis. JSON fragmentů dat
4. umělá sada dat: náhodně vygenerovaná sada 100 tis. produktů, 1.3 mil. cen, 800 tisíc atributů, 680 tis. relací, 200 tisíc JSON fragmentů dat

Každá implementace vytváří samostatný JAR spouštěný z příkazového řádku a nad ním staví vlastní Docker image. Spolu s prototypem databáze se do image přibalují i testovací datové sady a spouští se JMH, které provádí zmíněné výkonnostní testy. Výsledky jsou následně ukládány na GitHub, kde jsou i zpětně dostupné. Díky technologii Docker je možné testy jednoduše spouštět i na lokálním stroji na všech hlavních operačních systémech. Pracujeme na tom, abyste si výše uvedené testy mohli spustit a ověřit i na svém stroji.

Běh testů je monitorován pomocí Prometheus / Grafana technologií a výstupem jsou i vizuální grafy zatížení CPU a využití paměti.

Specifikace testovacího prostředí

• 4x CPU (procesory Intel Xeon Skylake nebo Cascade Lake se základním taktem 2,7 GHz)
• 16GB RAM
• 25GB SSD (nikoliv NVMe)
• OS: Linux (Ubuntu 20.04)
• JDK 11

Výzkumná fáze končí závěrečným funkčním a výkonnostním testováním, které porovná všechny prototypy evitaDB. evitaDB cílí na střední nízkou až střední úroveň hostingových programů doporučených pro e-commerce řešení a pro závěrečný test tedy vybereme odpovídající Digital Ocean General Purpose Droplet. Aby bylo možné získat opakovatelné a srovnatelné výsledky, testovací prostředí, bude využito dropletu s vyhrazeným CPU. Všechny tři implementace se postupně spouští na stejném dropletu, takže by měly být jejich výstupy vzájemně porovnatelné.

Priority závěrečného hodnocení

1. prototyp splňuje všechny nezbytné funkce ze specifikace
2. prototyp maximalizuje výkonnost pro operace čtení
   • dotazy za sekundu (propustnost)
   • latence dotazu
3. prototyp splňuje nepovinné funkce ze specifikace
4. prototyp maximalizuje rychlost indexování
   • mutace za sekundu (propustnost)

HW požadavky

Spolu s naměřenou výkonností se berou v potaz i telemetrické údaje ze systému, na kterém testy běží. Sledujeme:

1. nevyužitou kapacitu RAM (vážený průměr)
2. nevyužitou kapacitu CPU (vážený průměr)

Implementace s nižšími nároky získává oproti ostatním lepší hodnocení.