– Trebuie să recunosc, – a spus ea tare, fără a se adresa cuiva. – Trebuie să recunosc! Este scris clar – principala sarcină a societății este obținerea de profit în interesul acționarilor. Gândiți-vă! Nu le este frică de nimic!
Iulii Dubov, „Răul mai mic”
Văzând un astfel de titlu, cu siguranță ați decis deja că articolul este fie o prostie, fie o provocare. Dar nu vă grăbiți să trasați concluzii: angajaților corporațiilor mari, în special celor de stat, le este adesea necesar să compare diferite platforme, inclusiv complet diferite – de exemplu, cele menționate în titlu.
Desigur, nimeni nu compară DBMS-uri, căci punctele lor forte și slabe sunt bine cunoscute. De obicei, sunt comparate platforme care rezolvă o anumită sarcină aplicativă. În acest articol, voi arăta metoda utilizată în acest caz, folosind baza de date ca subiect, bine cunoscut cititorilor de pe Habr. Așadar,
Motivația
Când începeți un proiect educațional sau un hobby, motivația pentru alegerea platformei poate fi variată: „cunoștințele mele despre această platformă sunt cele mai bune”, „îmi face plăcere să mă lămuresc cu aceasta”, „aici e cea mai bună documentație”… În cazul unei companii comerciale, criteriul de alegere este unul singur: cât trebuie să plătesc și ce voi obține pentru acești bani.
Evident, dorim să plătim mai puțin și să obținem mai mult. Cu toate acestea, trebuie să decidă ce este mai important – să plătesc mai puțin sau să primesc mai mult, și să alocăm un punctaj fiecărui nod. Să presupunem că pentru noi este mai importantă soluția de calitate, decât cea ieftină, și astfel atribuim nodului „Cost” un punctaj de 40%, iar nodului „Funcționalități” – 60%.
În corporațiile mari, de obicei, totul este invers – punctajul costului nu scade sub 50%, iar poate fi chiar mai mult de 60%. În exemplul model, este important doar că suma punctajelor nodurilor copil ale oricărui nod părinte trebuie să fie 100%.
Criterii de excluziune
Site-ului sunt cunoscute aproximativ 500 de sisteme de gestionare a bazelor de date. Evident, dacă alegi o platformă țintă dintr-un asemenea număr de opțiuni, poate ieși un articol de revizuire, dar nu un proiect comercial. Pentru a restrânge spațiul de alegere, se formulează criterii de excludere, iar dacă platforma nu îndeplinește aceste criterii, atunci nu este considerată.
Criteriile de excluziune pot ține de caracteristicile tehnologice, de exemplu:
- Garanții ACID;
- model relațional de date;
- suport pentru limba SQL (rețineți că nu este același lucru cu «modelul relațional»);
- capacitate de scalare orizontală.
Pot exista criterii generale:
- existența suportului comercial în Rusia;
- cod sursă deschis;
- existența platformei în Registrul Ministerului Comunicațiilor;
- existența platformei într-un clasament (de exemplu, în prima sută a clasamentului db-engines.com);
- existența experților pe piață (de exemplu, după rezultatele căutării denumirii platformei în CV-uri pe site-ul hh.ru).
În cele din urmă, pot exista criterii specifice întreprinderii:
- existența specialiștilor în echipă;
- compatibilitatea cu sistemul de monitorizare X sau cu sistemul de backup Y, pe care se bazează întreaga asistență…
Cel mai important este ca lista criteriilor eliminatorii să existe. Altfel, cu siguranță va apărea un expert (sau un «expert») care se bucură de o mare încredere în rândul conducătorilor, care va spune «de ce nu ați ales platforma Z, știu că este cea mai bună».
Evaluarea costului
Costul soluției este evident format din costul licențelor, costul asistenței și costul echipamentului.
Dacă sistemele sunt aproximativ de aceeași clasă (de exemplu, Microsoft SQL Server și PostgreSQL), atunci, pentru simplitate, se poate considera că cantitatea de echipament pentru ambele soluții va fi aproximativ aceeași. Acest lucru va permite evitarea evaluării echipamentului, economisind astfel mult timp și efort. Dacă, însă, trebuie să compari sisteme complet diferite (să zicem, Oracle vs. Redis), este evident că pentru o evaluare corectă este necesară realizarea unui sizing (calculul cantității de echipament). Sizingul unei sisteme inexistente este o activitate destul de nerecunoscătoare, prin urmare, se încearcă în general să se evite astfel de comparații. Este simplu: în condițiile eliminatorii se specifică pierdere zero de date și model relațional sau, dimpotrivă, o sarcină de 50 de mii de tranzacții pe secundă.
Pentru a evalua licențele, este suficient să solicitați de la furnizor sau partenerii săi prețul licenței pentru un număr fix de nuclee și suport pentru o perioadă fixă. De obicei, companiile au deja relații consolidate cu furnizorii de software, iar dacă departamentul de exploatare a bazelor de date nu poate răspunde la întrebare, pentru a obține această informație este suficientă o scrisoare.
Furnizorii pot avea metrici diferite pentru licențiere: în funcție de numărul de nuclee, volumul de date sau numărul de noduri. O bază de date standby poate fi gratuită sau poate fi licențiată la fel ca cea principală. Dacă au fost identificate diferențe în metrici, va fi necesar să descrieți detaliat modelul standului și să calculați costul licențelor pentru stand.
Un aspect important pentru o comparație corectă este condițiile egale de suport. De exemplu, suportul Oracle costă 22% din prețul licenței pe an, în timp ce pentru suportul PostgreSQL nu se percepe nimic. Este corect să comparăm astfel? Nu, deoarece consecințele unei erori care nu poate fi rezolvată prin forțe proprii sunt complet diferite: în primul caz, specialiștii de suport vor ajuta rapid la soluționarea acesteia, iar în al doilea caz există riscul întârzierii proiectului sau a opririi unui sistem final pentru o perioadă nedefinită.
Puteți uniformiza condițiile de calcul în trei moduri:
- Folosind Oracle fără suport (în realitate, așa ceva nu există).
- Cumpărând suport pentru PostgreSQL – de exemplu, de la compania Postgres Professional.
- Includând în calcul riscurile asociate cu lipsa suportului.
De exemplu, calculul riscurilor poate arăta astfel: în cazul unei defecțiuni iremediabile a bazei de date, oprirea sistemului va dura 1 zi lucrătoare. Profitul estimat din utilizarea sistemului este de 40 miliarde tugriki mongole pe an, iar frecvența defecțiunilor este evaluată la 1/400, astfel, riscul lipsei de suport este estimat la aproximativ 100 milioane tugriki mongole pe an. Este evident că „profitul estimat” și „frecv. estimată de defecțiuni” sunt valori virtuale, dar este mult mai bine să aveți un astfel de model decât să nu aveți deloc.
În realitate, sistemul poate fi esențial, iar pierderile de reputație cauzate de un timp de nefuncționare îndelungat ar fi inacceptabile, așa că suportul va fi necesar. Dacă întreruperea este permisă, renunțarea la suport poate fi uneori o modalitate bună de a economisi.
Să presupunem că, după toate calculele, costul de operare al platformei A timp de 5 ani a fost de 800 milioane tugriki mongolezi, costul de operare al platformei B – 650 milioane tugriki, iar costul de operare al platformei C – 600 milioane tugriki. Platforma C, ca învingătoare, primește un punct complet pentru cost, iar platformele A și B primesc puțin mai puțin, proporțional cu cât sunt mai scumpe. În acest caz – 0.75 și 0.92 puncte, respectiv.
Evaluarea capacităților
Evaluarea capacităților se împarte în numeroase grupuri, numărul lor fiind limitat doar de imaginația celui care face evaluarea. O variantă optimă pare a fi împărțirea capacităților în funcție de echipele care le vor utiliza; în exemplul nostru, acestea sunt dezvoltatorii, administratorii și ofițerii de securitate a informației. Să presupunem că greutățile acestor funcții sunt distribuite astfel: 40:40:20.
Funcțiile de dezvoltare includ:
- ușurința în manipularea datelor;
- scalabilitate;
- disponibilitatea indicilor secundari.
Lista criteriilor, precum și greutățile acestora, sunt foarte subiective. Chiar și atunci când se rezolvă aceeași problemă, aceste liste, greutățile punctelor și răspunsurile vor varia semnificativ în funcție de compoziția echipei dumneavoastră. De exemplu, Facebook utilizează MySQL pentru stocarea datelor, în timp ce Instagram este bazat pe Cassandra. Este puțin probabil ca dezvoltatorii acestor aplicații să fi completat astfel de tabeluri. Se poate doar specula că Mark Zuckerberg a ales un model relațional complet, plătind pentru aceasta cu necesitatea sharding-ului aplicațional, în timp ce Kevin Systrom a construit scalabilitatea folosind capacitățile platformei, sacrificând ușurința accesului la date.
Funcțiile de administrare includ:
- capacitățile sistemului de backup;
- ușurința monitorizării;
- ușurința în gestionarea resurselor – discuri și noduri;
- capacitățile de replicare a datelor.
Rețineți că formulările întrebărilor trebuie să permită evaluarea cantitativă. Puteți chiar să conveniți asupra modului de evaluare a unei anumite funcții. Să încercăm, de exemplu, să evaluăm instrumentele de backup utilizând instrumentele furnizate cu SGBD-ul Oracle:
Instrument
Comentariu
Evaluare
imp/exp
Export și import de date
0.1
backup începere/încheiere
Copiere de fișiere
0.3
RMAN
Posibilitatea copiei incrementală
0.7
ZDLRA
Numai copie incrementală, recuperare rapidă la punctul de salvare
1.0
Dacă nu există criterii clare de evaluare, este bine să cereți mai multor experți să ofere evaluări, iar apoi să le mediați.
În final, să enumerăm funcțiile de securitate informațională:
- existența politicilor de gestionare a parolelor;
- posibilitatea conectării unor sisteme externe de autentificare (LDAP, Kerberos);
- model de acces pe bază de roluri;
- abilități de audit;
- criptarea datelor pe disc;
- criptarea în timpul transmisiei prin rețea (TLS);
- protecția datelor de către administrator.
Testarea performanței
Aș dori să vă avertizez în mod special să nu folosiți ca argumente rezultatele unor teste de sarcină efectuate de altele.
În primul rând, structura datelor și profilul de sarcină al aplicațiilor testate pot diferi semnificativ de sarcina pe care intenționați să o rezolvați. Cu 10-15 ani în urmă, producătorii de baze de date își etalau adesea rezultatele obținute în teste TPC, dar acum pare că nimeni nu ia în serios aceste rezultate.
În al doilea rând, performanța sistemului depinde destul de mult de platforma pentru care a fost scris inițial codul și de echipamentul pe care a fost efectuat testul. Am văzut numeroase teste în care Oracle era comparat cu PostgreSQL. Rezultatele variau de la superioritatea incontestabilă a unei sisteme la aceeași superioritate a celeilalte.
Și în sfârșit, în al treilea rând, nu știți nimic despre cine a efectuat testul. Este important atât calificarea, care influențează calitatea configurării sistemului de operare și a platformei, cât și motivația, care afectează rezultatele testului mai mult decât toate celelalte factori la un loc.
Dacă performanța este un factor critic, efectuați testul singur, de preferat cu implicarea specialiștilor care vor configura și întreține un sistem industrial.
Rezultatul
În cele din urmă, rezultatul întregii munci ar trebui să fie un tabel electronic în care toate evaluările sunt consolidate, înmulțite și sumate:
După cum înțelegeți, prin modificarea greutăților și ajustarea evaluărilor se poate obține orice rezultat dorit, dar aceasta este o altă poveste...
Sursa: habr.com
