"Je to nevyhnutné," povedala nahlas, pričom nikoho neoslovila. - Toto je potrebné! To je presne to, čo hovorí: hlavnou úlohou spoločnosti je dosahovať zisk v záujme akcionárov. Dobre, premýšľajte o tom! Ničoho sa neboja!
Yuliy Dubov, "menšie zlo"
Po zhliadnutí takéhoto titulku ste sa už zrejme rozhodli, že článok je buď hlúposť, alebo provokácia. Neponáhľajte sa však so závermi: zamestnanci veľkých korporácií, najmä korporácií so štátnou účasťou, musia pomerne často porovnávať rôzne platformy, vrátane úplne odlišných - napríklad tie v názve.
Samozrejme, že nikto neporovnáva DBMS týmto spôsobom, pretože ich silné a slabé stránky sú dobre známe. Platformy, ktoré riešia nejaký aplikačný problém, sú spravidla predmetom porovnávania. V článku ukážem metodiku, ktorá sa v tomto prípade používa, na príklade databáz ako predmetu, ktorý je čitateľom Habr známy z prvej ruky. takže,
Motivácia
Keď začínate so vzdelávacím projektom alebo záujmovým projektom, motivácia pre výber platformy môže byť veľmi rôznorodá: „toto je platforma, ktorú poznám najlepšie“, „mám záujem pochopiť túto“, „tu je najlepšia dokumentácia“ ... V prípade obchodnej spoločnosti je kritérium výberu rovnaké: koľko budem musieť zaplatiť a čo za tieto peniaze dostanem.
Prirodzene, chcete platiť menej a získať viac. Musíte sa však rozhodnúť, čo je dôležitejšie – platiť menej alebo dostať viac, a každému uzlu priradiť váhu. Predpokladajme, že kvalitné riešenie je pre nás dôležitejšie ako lacné, a uzlu „Cost“ priradíme váhu 40 % a uzlu „Príležitosti“ 60 %.
Vo veľkých korporáciách je to väčšinou naopak – nákladová váha neklesne pod 50 %, a možno aj viac ako 60 %. V modelovom príklade je dôležité len to, že celková váha dcérskych uzlov ktoréhokoľvek nadradeného uzla musí byť 100 %.
Medzné podmienky
webové stránky Je známych asi 500 systémov správy databáz. Prirodzene, ak si z toľkých možností vyberiete cieľovú platformu, môžete skončiť s recenzným článkom, nie však s komerčným projektom. Aby sa zmenšil priestor na výber, sú formulované hraničné kritériá, a ak platforma tieto kritériá nespĺňa, neprichádza do úvahy.
Hraničné kritériá sa môžu týkať technologických prvkov, napríklad:
- ACID záruky;
- relačný dátový model;
- podpora jazyka SQL (pozn. toto nie je to isté ako „relačný model“);
- možnosť horizontálneho škálovania.
Môžu existovať všeobecné kritériá:
- dostupnosť komerčnej podpory v Rusku;
- otvorený zdroj;
- dostupnosť platformy v registri Ministerstva telekomunikácií a masových komunikácií;
- prítomnosť platformy v nejakom hodnotení (napríklad v prvej stovke hodnotenia db-engines.com);
- prítomnosť odborníkov na trhu (napríklad na základe výsledkov vyhľadávania názvu platformy v životopise na webovej stránke hh.ru).
Koniec koncov, môžu existovať kritériá špecifické pre podnik:
- dostupnosť špecialistov na personál;
- kompatibilita s monitorovacím systémom X alebo záložným systémom Y, na ktorých je celá podpora založená...
Najdôležitejšie je, že existuje zoznam hraničných kritérií. V opačnom prípade sa určite nájde nejaký odborník (alebo „expert“), ktorý sa teší špeciálnej dôvere zo strany vedenia, ktorý povie „prečo ste si nevybrali platformu Z, viem, že je najlepšia“.
Odhad nákladov
Náklady na riešenie samozrejme pozostávajú z nákladov na licencie, nákladov na podporu a nákladov na vybavenie.
Ak sú systémy približne rovnakej triedy (napríklad Microsoft SQL Server a PostgreSQL), potom pre jednoduchosť môžeme predpokladať, že množstvo vybavenia pre obe riešenia bude približne rovnaké. To vám umožní nehodnotiť vybavenie, čím ušetríte veľa času a úsilia. Ak máte porovnávať úplne odlišné systémy (povedzme Oracle vs. Redis), potom je zrejmé, že pre správne posúdenie je potrebné urobiť dimenzovanie (výpočet množstva vybavenia). Dimenzovanie neexistujúceho systému je veľmi nevďačná úloha, preto sa takýmto porovnávaniam stále snažia vyhnúť. Je to jednoduché: v podmienkach cut-off sa zapíše nulová strata dát a relačný model alebo naopak - zaťaženie 50 tisíc transakcií za sekundu.
Na vyhodnotenie licencií stačí požiadať predajcu alebo jeho partnerov o cenu licencie na pevný počet jadier a podporu na dobu určitú. Spoločnosti už spravidla majú silné vzťahy s dodávateľmi softvéru a ak oddelenie prevádzky databáz nedokáže samo odpovedať na otázku nákladov, potom na získanie týchto informácií stačí jeden list.
Rôzni dodávatelia môžu mať rôzne licenčné metriky: podľa počtu jadier, objemu dát alebo počtu uzlov. Pohotovostná základňa môže byť bezplatná, alebo môže byť licencovaná rovnako ako hlavná. Ak sa zistia nejaké rozdiely v metrikách, budete musieť podrobne opísať model stánku a vypočítať náklady na licencie na stánok.
Dôležitým bodom pre správne porovnanie sú rovnaké podmienky podpory. Napríklad podpora Oracle stojí 22 % z ceny licencie ročne, ale nemusíte platiť za podporu PostgreSQL. Je správne takto porovnávať? Nie, pretože chyba, ktorú nemožno opraviť svojpomocne, má úplne iné dôsledky: v prvom prípade vám špecialisti podpory rýchlo pomôžu opraviť, ale v druhom prípade existuje riziko oneskorenia projektu alebo odstávky dokončeného systému na dobu neurčitú.
Podmienky výpočtu môžete vyrovnať tromi spôsobmi:
- Používajte Oracle bez podpory (v skutočnosti sa to nestane).
- Kúpte si podporu pre PostgreSQL – napríklad od Postgres Professional.
- Berte do úvahy riziká spojené s nedostatkom podpory.
Výpočet rizika môže vyzerať napríklad takto: v prípade fatálneho zlyhania databázy bude výpadok systému 1 pracovný deň. Predpokladaný zisk z používania systému je 40 miliárd MNT ročne, nehodovosť sa odhaduje na 1/400, teda riziko nedostatočnej podpory sa odhaduje na približne 100 miliónov MNT ročne. Je zrejmé, že „plánovaný zisk“ a „odhadovaná frekvencia nehôd“ sú virtuálne hodnoty, ale je oveľa lepšie mať takýto model ako nemať žiadny.
V skutočnosti môže byť systém príliš dôležitý na to, aby boli reputačné náklady na dlhodobé prestoje neprijateľné, takže bude potrebná podpora. Ak sú prestoje povolené, odmietnutie podpory môže byť niekedy dobrým spôsobom, ako ušetriť peniaze.
Predpokladajme, že po všetkých výpočtoch sú náklady na prevádzku platformy A na 5 rokov 800 miliónov MNT, náklady na prevádzku platformy B sú 650 miliónov MNT a náklady na prevádzku platformy C sú 600 miliónov MNT. Platforma C ako víťaz získava za cenu plný bod, platformy A a B o niečo menej, úmerne tomu, koľkokrát sú drahšie. V tomto prípade – 0.75 a 0.92 bodu.
Posúdenie príležitosti
Hodnotenie príležitostí je rozdelené do mnohých skupín, ktorých počet je obmedzený len predstavivosťou hodnotiteľa. Ako optimálna možnosť sa javí rozdelenie schopností do tímov, ktoré budú tieto schopnosti využívať; v našom príklade sú to vývojári, správcovia a pracovníci informačnej bezpečnosti. Predpokladajme, že váhy týchto funkcií sú rozdelené ako 40:40:20.
Funkcie vývoja zahŕňajú:
- jednoduchosť manipulácie s údajmi;
- škálovanie;
- prítomnosť sekundárnych indexov.
Zoznam kritérií, ako aj ich váhy sú veľmi subjektívne. Dokonca aj pri riešení rovnakého problému sa tieto zoznamy, váhy položiek a odpovede budú výrazne líšiť v závislosti od zloženia vášho tímu. Napríklad Facebook používa na ukladanie dát MySQL a Instagram je postavený na Cassandre. Je nepravdepodobné, že vývojári týchto aplikácií vyplnili takéto tabuľky. Dá sa len hádať, že Mark Zuckerberg si vybral plnohodnotný relačný model, zaplatil za to potrebou aplikovaného shardingu, zatiaľ čo Kevin Systrom vybudoval škálovanie pomocou platformy, čím obetoval jednoduchý prístup k údajom.
Medzi administratívne funkcie patrí:
- schopnosti zálohovacieho systému;
- jednoduchosť monitorovania;
- jednoduchosť správy kapacity – disky a uzly;
- schopnosti replikácie údajov.
Upozorňujeme, že otázky musia byť formulované kvantitatívne. Môžete sa dokonca dohodnúť, ako hodnotiť konkrétnu funkciu. Skúsme napríklad ohodnotiť zálohovacie nástroje na príklade nástrojov dodávaných s Oracle DBMS:
Nástroj
Komentár
Ohodnotenie
imp/exp
Nahrávanie a načítanie údajov
0.1
začať/ukončiť zálohovanie
Kopírovanie súborov
0.3
RMAN
Schopnosť prírastkového kopírovania
0.7
ZDLRA
Iba prírastkové kopírovanie, najrýchlejšia obnova do bodu
1.0
Ak neexistujú jasné hodnotiace kritériá, má zmysel požiadať niekoľkých odborníkov, aby udelili hodnotenia a potom ich spriemerovali.
Nakoniec jednoducho vymenujeme funkcie informačnej bezpečnosti:
- dostupnosť zásad správy hesiel;
- možnosť pripojenia externých autentifikačných nástrojov (LDAP, Kerberos);
- vzor prístupu;
- schopnosti auditu;
- šifrovanie údajov na disku;
- šifrovanie počas prenosu cez sieť (TLS);
- ochranu údajov pred správcom.
Testovanie výkonu
Samostatne by som chcel varovať pred používaním výsledkov akýchkoľvek záťažových testov, ktoré ste neurobili vy, ako argumenty.
Po prvé, dátová štruktúra a profil záťaže testovaných aplikácií sa môžu výrazne líšiť od problému, ktorý sa chystáte riešiť. Asi pred 10-15 rokmi sa predajcovia databáz radi chválili výsledkami dosiahnutými v testoch TPC, no zdá sa, že tieto výsledky už nikto neberie vážne.
Po druhé, výkon systému dosť silne závisí od platformy, pre ktorú bol kód pôvodne napísaný a od akého zariadenia bol test vykonaný. Videl som veľa testov, kde bol Oracle porovnávaný s PostgreSQL. Výsledky siahajú od bezpodmienečnej nadradenosti jedného systému po rovnako bezpodmienečnú nadradenosť iného systému.
A nakoniec po tretie, nevieš nič o tom, kto test robil. Dôležité sú obe kvalifikácie, ktoré ovplyvňujú kvalitu nastavenia OS a platformy, ako aj motiváciu, ktorá ovplyvňuje výsledky testov viac ako všetky ostatné faktory dohromady.
Ak je výkon kritickým faktorom, vykonajte test sami, najlepšie s pomocou ľudí, ktorí budú konfigurovať a udržiavať výrobný systém.
Výsledok
Nakoniec, výsledkom všetkej vykonanej práce by mala byť tabuľka, v ktorej sú všetky odhady spojené, vynásobené a zhrnuté:
Ako viete, zmenou stupnice a úpravou hodnotenia môžete dosiahnuť akýkoľvek požadovaný výsledok, ale to je úplne iný príbeh...
Zdroj: hab.com