Dobrý večer, jsem autor jádra databáze a přednášky, ze které tento článek pravděpodobně čerpá.
Jedná se o NoSQL databázi. Na začátku projektu byla sestavena tato základní specifikace, především ale vznikla sada funkcionálních testů, která ověřovala všechny tři prototypové implementace (PostgreSQL, Elasticsearch, in-memory implementace). Zároveň vznikla i sada výkonnostních testů, aby týmy měly k dispozici co nejreálější zpětnou vazbu, jaké bylo možno dosáhnout.
Testovací procedura včetně konstrukce všech testovacích scénářů je jednak zdokumentována a jednak je i stále dostupná na GitHubu.
Elasticsearch a PostgreSQL jsme pro porovnávací implementaci zvolili proto, že se v reálné praxi pro e-commerce projekty používají. Nebylo v našich silách implementovat více variant, úvodní zvolené API bylo celkem komplexní a jeho implementace a odladění vyžadovala několik měsíců intenzivní práce.
Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.
Dobrý večer, jsem autor jádra databáze a přednášky, ze které tento článek pravděpodobně čerpá.
Máte pravdu, ale tento fakt jsme brali v potaz. Nechtěli jsme platit náklady na dedikovanou infrastrukturu a proto jsme pro každý běh výkonnostních testů nakoupili infrastrukturu a po jejich skončení ji zase uvolnili. Nicméně všechny tři implementace běžely sekvenčně za sebou na stejném dropletu. Ačkoliv se tedy absolutní čísla mezi dvěma běhy výkonnostních testů mohly lišit kvůli různé HW specifikaci, relativní srovnání všech tří implementací v rámci jednoho běhu srovnatelné bylo, protože ty běžely v rámci stejného dropletu na stejném HW. Zároveň jsme na závěr projektu provedli testy i na fyzickém HW na straně Univerzity Hradec Králové, které nám potvrdilo, že relativní srovnání implementací naměřené na DO odpovídá realitě. On-demand alokovaná infrastruktura na DO nám také umožnila také celkem jednoduše provést testy vertikálního škálování, kdy jsme testovali výkon na různě vertikálně nasizovaném HW.
Testovací procedura včetně konstrukce všech testovacích scénářů je jednak zdokumentována a jednak je i stále dostupná na GitHubu.
Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.
Dobrý večer, jsem autor jádra databáze a přednášky, ze které tento článek pravděpodobně čerpá.
Ano - e-shopy děláme již řadu let. evitaDB zatím žádný náš produkční projekt nepohání, ale všechny funkční testy čerpaly z našich zkušeností a výkonnostní testy běžely na produkčních datech a prováděly transformované dotazy nasnímané z provozu našich stávajících e-shopů. Zkrátka dělali jsme vše pro to, aby čísla, která naměříme, nebyla mimo realitu. První projekt nad evitaDB připravujeme na spuštění letos na přelomu roku. Příští rok chceme i naše stávající zákazníky postupně na evitaDB migrovat. Proto také současnou verzi databáze označujeme zatím jako "alfa" verzi. První stabilní verzi vydáme až nasbíráme zkušenosti s jejím provozem na vlastní kůži.
Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.
Dobrý večer, jsem autor jádra databáze a přednášky, ze které tento článek pravděpodobně čerpá.
Publikování textů vůbec nebylo součástí výzvy. Dokonce nebylo součástí výzvy ani uvolnění výsledku pod volnou licencí. Texty, náš blog, přednášky a všechno okolo děláme jen proto, že si myslíme, že to má smysl.
Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.
Dobrý večer, jsem autor jádra databáze a přednášky, ze které tento článek pravděpodobně čerpá.
Máte pravdu, že PostgreSQL je opravdu velmi bohatá na své funkce a za ty roky používání je velmi stabilní a vyladěnou databází. Náš tým, který vytvářel implementaci API nad PostgreSQL databází také zkusil řadu těchto funkcí využít, ale nakonec z výkonnostních důvodů musel na některé z nich úplně rezignovat. Zkušenosti z implementace popsali autoři zde. Nesnažíme se s PostgreSQL soutěžit - koneckonců i my pro správu primárních dat používáme relační databázi. Snažíme se ale v praxi ověřit, že pro e-commerce katalogy dává smysl specializované řešení, které je stavěné od základu jinak. Na počty funkcí PostgreSQL vždy vyhraje.
Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.
Nulová specifikace databáze. Je to SQL nebo No SQL? Distribuovaná?
Srovnání s PostgreSQL je směšné, ta je zrovna na e-shop nevhodná (klasická read-write), tohle je v podstatě read-only bez zámků.
Jaké je srovnání s RAM databázemi?
Jaké dotazy jsou testovány (konkétní produky, hledání pomocí slov, ...)
Trošku mě překvapilo to testovaní.
"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"
Při tomto výběru vůbec nevíte, jaké CPU vám DO přidělí. Není to opakovatelné.
Dost to sráží důvěryhodnost celého projektu.
Vetsina eshopu si vystaci se zcela libovolnou databazi, a mnohem zasadnejsi parametr nez zcela nezajimavy vykon, je treba administrovatelnost, a standardizace.
Ukazte mi hosting, ktery vam nasadi nejakou uchylnou (ne)databazi ...
Uz jen to, ze je to vyrabeno nikoli na zaklade nejakych komercnich pozadavku, ale za dotace to v mych ocich zcela diskvalifikuje.
Dobrý den, díky za názor. U malých e-shopů na volbě databáze skutečně tolik nezáleží (při současném výkonu HW). Výhodou evitaDB API však může být hotové webové API (GraphQL, REST, gRPC), které zjednoduší kód cílové aplikace.
Víme, že dotace jsou v mnoha očích problematická veličina - databázi jsme nevyvíjeli kvůli dotacím, ale kvůli naší vlastní potřebě minimalizovat HW požadavky pro e-commercové projekty středního a většího rozsahu na našich vlastních projektech. Viz. ukázkové datové sady ve výkonnostních testech. Nedá se tedy tvrdit, že za vývojem nestojí komerční požadavky.