🥇Co je lepší – Oracle nebo Redis nebo Jak obhájit výběr platformy

– To je něco, – řekla nahlas, aniž by se na někoho obrátila. – To je něco! Tak přímo napsáno – hlavním úkolem společnosti je získávání zisku v zájmu akcionářů. Tak si to promyslete! Nic se nebojí!
Julij Dubov, „Menší zlo“

Když uvidíte takový titulek, pravděpodobně už máte za to, že článek je – buď hloupost, nebo provokace. Ale nespěchejte se závěry: zaměstnanci velkých korporací, zvláště těch, které mají státní účast, se docela často musí srovnávat různé platformy, včetně zcela odlišných – například jako ty, které jsou zmíněny v titulku.

Samozřejmě, že se SŘBD tak nikdo nesrovnává, protože jejich silné a slabé stránky jsou dobře známé. Obvykle se srovnávají platformy, které řeší nějaký praktický úkol. V článku ukážu metodiku, která se při tom používá, na příkladu databází jako předmětu, který je čtenářům Habra znám. Takže,

Motivace

Když začínáte vzdělávací projekt nebo projekt koníček, motivace pro výběr platformy může být velmi rozmanitá: „tuto platformu znám nejlépe“, „s touto mě zajímá zabývat se“, „tady je nejlepší dokumentace“… V případě komerční společnosti je kritérium výběru jediné: kolik bude třeba zaplatit a co za ty peníze dostanu.

Přirozeně, chtělo by se zaplatit méně a dostat více. Je však třeba rozhodnout, co je důležitější – zaplatit méně nebo dostat více, a přiřadit každému uzlu váhu. Předpokládejme, že nám záleží na kvalitním řešení více než na levném, a přiřadíme uzlu „Cena“ váhu 40 %, zatímco uzlu „Možnosti“ 60 %.

Ve velkých korporacích je obvykle vše naopak – váha nákladů neklesá pod 50 %, a může být i více než 60 %. V modelovém příkladu je důležité pouze to, že celková váha podřízených uzlů jakéhokoli rodičovského uzlu musí být 100 %.

Omezeni podmínkami

Webu db-engines.com je známo přibližně 500 systémů pro správu databází. Přirozeně, pokud vybíráte cílovou platformu z takového množství možností, může vzniknout přehledový článek, ale ne komerční projekt. Aby se zúžil prostor výběru, formulují se omezující kritéria, a pokud platforma těmto kritériím nevyhovuje, nebere se v úvahu.

Kritéria vyloučení mohou souviset s technickými vlastnostmi, například:

záruky ACID;
relační datový model;
podpora jazyka SQL (vezměte prosím na vědomí, že to není totéž jako „relační model“);
možnost horizontálního škálování.

Mohou existovat kritéria obecného charakteru:

přítomnost komerční podpory v Česku;
otevřený zdrojový kód;
přítomnost platformy v registru Ministerstva dopravy;
přítomnost platformy v nějakém hodnocení (například v první stovce hodnocení na db-engines.com);
přítomnost expertů na trhu (například podle výsledků hledání názvu platformy v životopisech na stránkách hh.ru).

Nakonec mohou existovat kritéria specifická pro podnik:

přítomnost specialistů v týmu;
kompatibilita se systémem monitorování X nebo se systémem zálohování Y, na kterém závisí celé poradenství…

Nejdůležitější je, aby existoval seznam vylučujících kritérií. Jinak vždy existuje nějaký expert (nebo „expert“), který má zvláštní důvěru vedení, a řekne: „Proč jste nevybrali platformu Z, vím, že je nejlepší.“

Ohodnocení nákladů

Náklady na řešení se skládají z nákladů na licence, nákladů na údržbu a nákladů na hardware.

Pokud jsou systémy zhruba stejné třídy (například Microsoft SQL Server a PostgreSQL), pak pro zjednodušení můžeme považovat, že množství hardware pro obě řešení bude zhruba stejné. To ušetří hodnocení hardwaru, čímž se ušetří hodně času a úsilí. Pokud je však nutné porovnávat zcela odlišné systémy (například Oracle vs. Redis), je zřejmé, že pro správné posouzení je třeba provést sizing (výpočet množství hardwaru). Sizing neexistujícího systému je velice vděčná činnost, a proto se s takovými porovnáními snažíme vyvarovat. Je to jednoduché: v podmínkách vyloučení jsou uvedeny nulové ztráty dat a relační model, nebo naopak - zatížení 50 tisíc transakcí za sekundu.

Pro ocenění licencí stačí požádat dodavatele nebo jeho partnery o cenu licence na pevný počet jader a podpory na pevné období. Obvykle mají společnosti již vybudované silné vztahy s dodavateli softwaru, a pokud oddělení správy databází nedokáže na otázku o ceně odpovědět samo, stačí k získání této informace jedno e-mailové zprávy.

Různí dodavatelé mohou mít různé metriky licencování: podle počtu jader, objemu dat nebo počtu uzlů. Záložní databáze může být zdarma, nebo může být licencována stejně jako hlavní. Pokud se objeví nějaké rozdíly v metrikách, bude nutné podrobně popsat modelový stojan a spočítat náklady na licence pro stojan.

Důležitý bod pro správné srovnání – stejné podmínky podpory. Řekněme, že podpora Oracle stojí 22 % z ceny licence za rok, zatímco za podporu PostgreSQL nemusíte platit. Je takové srovnání správné? Ne, protože důsledky chyby, kterou nelze vyřešit vlastními silami, jsou zcela odlišné: v prvním případě odborníci podpory rychle pomohou problém vyřešit, zatímco ve druhém případě hrozí zpoždění projektu nebo výpadek hotového systému na neurčitou dobu.

Podmínky výpočtu lze vyrovnat třemi způsoby:

Použít Oracle bez podpory (v realitě se to nestává).
Koupit podporu na PostgreSQL – například od společnosti Postgres Professional.
Zahrnout do výpočtů rizika spojená s absencí podpory.

Například výpočet rizik může vypadat takto: v případě neodstranitelného selhání databáze činí výpadek systému 1 pracovní den. Očekávaný zisk z využívání systému činí 40 miliard mongolských tugriků ročně, frekvence havárií se odhaduje na 1/400, tím pádem je riziko absence údržby odhadováno přibližně na 100 milionů mongolských tugriků ročně. Je zřejmé, že 'očekávaný zisk' a 'odhadovaná frekvence havárií' jsou virtuální hodnoty, ale je rozhodně lepší mít takový model, než žádný.

Ve skutečnosti může být systém příliš důležitý, a reputační ztráty způsobené dlouhým výpadkem se ukážou jako nepřijatelné, proto bude potřebná podpora. Pokud však výpadek je přijatelný, může být odmítnutí podpory někdy dobrým způsobem, jak ušetřit.

Předpokládejme, že po všech výpočtech se náklady na provoz platformy A za 5 let ukázaly být 800 milionů mongolských tugriků, náklady na provoz platformy B – 650 milionů tugriků a náklady na provoz platformy C – 600 milionů tugriků. Platforma C jako vítěz získává za cenu plný bod, whereas platformy A a B dostávají o něco méně bodů, proporčně k tomu, jak moc jsou dražší. V tomto případě – 0,75 a 0,92 bodů.

Hodnocení schopností

Hodnocení schopností se dělí na různé skupiny, jejichž počet je omezen pouze fantazií toho, kdo hodnocení provádí. Optimálním řešením se zdá být rozdělení schopností podle týmů, které tyto schopnosti budou využívat; v našem příkladu to jsou vývojáři, administrátoři a specialisté na informační bezpečnost. Předpokládejme, že váhy těchto funkcí jsou rozděleny jako 40:40:20.

Mezi funkce vývoje patří:

pohodlí manipulace s daty;
škálovatelnost;
existence sekundárních indexů.

Seznam kritérií, stejně jako jejich váhy, je velmi subjektivní. I při řešení stejného úkolu se tyto seznamy, váhy položek a odpovědi budou podstatně lišit v závislosti na složení vašeho týmu. Například Facebook pro ukládání dat používá MySQL, zatímco Instagram je postaven na bází Cassandra. Je nepravděpodobné, že by vývojáři těchto aplikací vyplnili takové tabulky. Můžeme se jen domnívat, že Mark Zuckerberg zvolil plně relační model, což si vyžádalo potřebnost aplikačního shardingu, zatímco Kevin Systrom vsadil na škálovatelnost prostředky platformy a obětoval pohodlí přístupu k datům.

Mezi funkce správy patří:

schopnosti systému zálohování;
pohodlí monitorování;
pohodlí správy kapacit – disků a uzlů;
schopnosti replikace dat.

Všimněte si, že formulace otázek by měla umožňovat kvantitativní hodnocení. Můžete se dokonce dohodnout, jak hodnotit určitou funkci. Zkusme například ohodnotit nástroje pro zálohování na příkladu nástrojů dodávaných s databázovým systémem Oracle:

Náklad
Komentář
Hodnocení

imp/exp
Export a import dat
0.1

begin/end backup
Kopírování souborů
0.3

RMAN
Možnost inkrementálního kopírování
0.7

ZDLRA
Pouze inkrementální kopírování, nejrychlejší obnova do bodu
1.0

Pokud chybí jasná kritéria hodnocení, má smysl požádat několik odborníků, aby poskytli hodnocení, a poté je průměrovat.

Nakonec pouze vyjmenujeme funkce informační bezpečnosti:

existence politiky správy hesel;
možnost připojení externích autentizačních prostředků (LDAP, Kerberos);
role-based access model;
možnosti auditu;
šifrování dat na disku;
šifrování při přenosu po síti (TLS);
ochrana dat před administrátorem.

Testování výkonu

Rád bych zvlášť varoval před používáním výsledků jakýchkoli zátěžových testů, které neprovedli jste.

Za prvé, struktura dat a profil zátěže testovaných aplikací se mohou výrazně lišit od úkolu, který se chystáte vyřešit. Před 10-15 lety výrobci databází rádi předkládali výsledky dosažené v testech TPC, ale nyní se zdá, že už nikdo tyto výsledky nebere vážně.

Za druhé, výkon systému závisí do značné míry na tom, pro kterou platformu byl kód původně napsán a na jakém vybavení byly testy prováděny. Mnohokrát jsem viděl testy, kde byl Oracle porovnáván s PostgreSQL. Výsledky – od bezpodmínečné převahy jednoho systému po stejně bezpodmínečnou převahu druhého.

A konečně, za třetí, nic nevíte o tom, kdo test provedl. Důležitá je jak kvalifikace, která ovlivňuje kvalitu nastavení OS a platformy, tak motivace, která ovlivňuje výsledky testu silněji než všechny ostatní faktory dohromady.

Pokud je výkon kritickým faktorem, proveďte test sami, ideálně s účastí specialistů, kteří budou nastavovat a udržovat průmyslový systém.