Dva nástroje na dva různé úkoly
E-shop má vlastní produkční databázi, do které se ukládá objednávka, aktualizuje sklad nebo dohledá jeden konkrétní zákazník. Je navržená na rychlé zpracování velkého množství malých operací, jedné najednou, a na to, aby nikdy nespadla. Tomu se říká transakční databáze, OLTP (Online Transaction Processing).
Analytická databáze řeší opačný problém
Report typu tržby podle kategorie za poslední dva roky neznamená jednu operaci, ale průchod milionů řádků historie najednou. Na tohle jsou navržené analytické databáze, OLAP (Online Analytical Processing), například BigQuery. Umí rychle proskenovat a agregovat obrovský objem dat, ale nejsou stavěné na to, aby ukládaly jednu objednávku za druhou v reálném čase.
Proč nejde použít jedna databáze na obojí
Návrh, který zrychluje jednu operaci najednou, zpomaluje průchod miliony řádků, a naopak. Transakční a analytická databáze nejsou dvě úrovně stejného nástroje, jsou to dva nástroje postavené na opačných kompromisech.
Kde firmy pálí peníze
Nejčastější chyba nevzniká z neznalosti rozdílu mezi OLTP a OLAP, ale z toho, že produkční databáze je po ruce a data v ní jsou, takže se report pustí přímo na ni.
Report ohrožuje běžící e-shop
Těžký analytický dotaz pouštěný přímo proti produkční databázi zatíží stejný výkon, na kterém běží checkout a příjem objednávek. Při větším reportu nebo špatně napsaném dotazu hrozí zpomalení, nebo i výpadek části e-shopu, který právě v tu chvíli obsluhuje zákazníky. Je to reálné provozní riziko, ne teoretická možnost.
Data z různých zdrojů nejde snadno spojit
Produkční databáze e-shopu obsahuje jen data e-shopu. Bez odděleného analytického skladu není kam přivést data z účetnictví nebo z reklamních účtů, aby šla spojit do jednoho pohledu, každý zdroj tak zůstává izolovaný sám pro sebe.
Historie mizí kvůli výkonu produkční databáze
Kvůli výkonu se stará data v produkční databázi často mažou nebo archivují mimo dosah běžných dotazů. Meziroční srovnání nebo delší trendy pak nejdou spočítat, protože data, ze kterých by report vycházel, už v databázi nejsou.
Proč Datimo odděluje analytickou vrstvu od provozu
Datimo staví analytickou vrstvu (BigQuery) mimo produkční systémy. Data z e-shopu, účetnictví a reklamy se pravidelně kopírují do samostatného datového skladu, produkční databáze e-shopu se tím nezatěžuje a zůstává určená jen k tomu, k čemu je stavěná, k běžnému provozu.
Těžké dotazy neohrožují běžící e-shop
Report nebo segmentace se počítají nad kopií dat v odděleném skladu, ne nad databází, která právě zpracovává objednávky. Ani náročný dotaz tak neriskuje výpadek checkoutu.
Historie zůstává k dispozici bez časového omezení
Protože sklad neřeší výkon jednotlivé transakce, ale ukládání a agregaci dat, historie se v něm neztrácí kvůli optimalizaci provozu. Meziroční a delší srovnání tak jde spočítat i za data, která by v produkční databázi dávno neexistovala.
Detail k samotnému skladu
Jak konkrétně BigQuery jako analytický sklad funguje a jak se účtuje, popisujeme v pojmu BigQuery.