"Això és necessari", va dir en veu alta, sense dirigir-se a ningú. - Això és necessari! Això és exactament el que diu: la tasca principal d'una empresa és obtenir beneficis en interès dels accionistes. Bé, pensa-hi! No tenen por de res!
Yuliy Dubov, "El mal menor"
Després d'haver vist aquest titular, probablement ja heu decidit que l'article és una estupidesa o una provocació. Però no us afanyeu a treure conclusions: els empleats de les grans corporacions, especialment les corporacions amb participació estatal, sovint han de comparar diferents plataformes, incloses les completament diferents, per exemple, les del títol.
Per descomptat, ningú compara els SGBD d'aquesta manera, perquè els seus punts forts i febles són coneguts. Per regla general, les plataformes que resolen algun problema d'aplicació estan subjectes a comparació. En l'article mostraré la metodologia que s'utilitza en aquest cas, fent servir l'exemple de les bases de dades com a tema que és familiar als lectors d'Habr de primera mà. Tan,
RњRѕS, ReRІR ° C † ReSЏ
Quan inicies un projecte educatiu o un projecte d'afició, la motivació per escollir una plataforma pot ser molt diversa: “aquesta és la plataforma que conec millor”, “m'interessa entendre aquesta”, “aquí tens la millor documentació” ... En el cas d'una empresa comercial, el criteri de selecció és el mateix: quant hauré de pagar i què obtindré per aquests diners.
Naturalment, voleu pagar menys i obtenir més. Tanmateix, heu de decidir què és més important: pagar menys o obtenir més, i assignar un pes a cada node. Suposem que una solució d'alta qualitat és més important per a nosaltres que una de barata, i assignem un pes del 40% al node "Cost" i del 60% al node "Oportunitats".
A les grans corporacions, sol ser el contrari: el pes del cost no baixa del 50%, i potser més del 60%. A l'exemple del model, tot el que és important és que el pes total dels nodes fills de qualsevol node pare ha de ser del 100%.
Condicions de tall
Lloc web Es coneixen uns 500 sistemes de gestió de bases de dades. Naturalment, si trieu una plataforma objectiu entre tantes opcions, podeu acabar amb un article de revisió, però no un projecte comercial. Per tal de reduir l'espai d'elecció, es formulen criteris de tall, i si la plataforma no compleix aquests criteris, no es considera.
Els criteris de tall poden relacionar-se amb característiques tecnològiques, per exemple:
- garanties ACID;
- model de dades relacionals;
- Suport del llenguatge SQL (nota, això no és el mateix que el "model relacional");
- possibilitat d'escalat horitzontal.
Hi pot haver criteris generals:
- disponibilitat de suport comercial a Rússia;
- codi obert;
- disponibilitat de la plataforma al Registre del Ministeri de Telecomunicacions i Comunicacions de Masses;
- presència de la plataforma en alguna classificació (per exemple, en el primer centenar de la classificació db-engines.com);
- la presència d'experts al mercat (per exemple, en funció dels resultats de la recerca del nom de la plataforma en un currículum al lloc web hh.ru).
Després de tot, pot haver-hi criteris específics de l'empresa:
- disponibilitat d'especialistes en el personal;
- compatibilitat amb el sistema de monitorització X o el sistema de còpia de seguretat Y, en què es basa tot el suport...
El més important és que hi hagi una llista de criteris de tall. En cas contrari, definitivament hi haurà algun expert (o "expert") que gaudeixi d'una confiança especial per part de la direcció que dirà "per què no vau triar la plataforma Z, sé que és la millor".
Estimació de costos
El cost de la solució consisteix, òbviament, en el cost de les llicències, el cost del suport i el cost de l'equip.
Si els sistemes són aproximadament de la mateixa classe (per exemple, Microsoft SQL Server i PostgreSQL), per simplificar podem suposar que la quantitat d'equips per a ambdues solucions serà aproximadament la mateixa. Això us permetrà no avaluar l'equip, estalviant així molt de temps i esforç. Si heu de comparar sistemes completament diferents (per exemple, Oracle vs. Redis), aleshores és obvi que per a una valoració correcta cal fer un dimensionament (càlcul de la quantitat d'equip). Dimensionar un sistema inexistent és una tasca molt ingrata, així que encara intenten evitar aquestes comparacions. Això és fàcil de fer: en les condicions de tall, s'escriu una pèrdua de dades zero i un model relacional, o viceversa, una càrrega de 50 mil transaccions per segon.
Per avaluar les llicències, n'hi ha prou amb demanar al venedor o als seus socis el cost d'una llicència per a un nombre fix de nuclis i suport durant un període determinat. Per regla general, les empreses ja tenen relacions sòlides amb els venedors de programari, i si el departament d'operacions de la base de dades no pot respondre la pregunta de costos per si sol, n'hi ha prou amb una carta per obtenir aquesta informació.
Els diferents proveïdors poden tenir diferents mètriques de llicència: per nombre de nuclis, volum de dades o nombre de nodes. La base d'espera pot ser gratuïta o es pot llicenciar de la mateixa manera que la principal. Si es descobreixen diferències en les mètriques, haureu de descriure detalladament el model d'estand i calcular el cost de les llicències de l'estand.
Un punt important per a una comparació correcta són les mateixes condicions de suport. Per exemple, el suport d'Oracle costa el 22% del preu de la llicència a l'any, però no cal que pagueu el suport de PostgreSQL. És correcte comparar així? No, perquè un error que no es pot solucionar pel vostre compte té conseqüències completament diferents: en el primer cas, els especialistes de suport us ajudaran ràpidament a solucionar-lo, però en el segon cas, hi ha el risc de retardar el projecte o el temps d'inactivitat de l'acabat. sistema per un període indefinit.
Podeu igualar les condicions de càlcul de tres maneres:
- Utilitzeu Oracle sense suport (en realitat això no passa).
- Compreu suport per a PostgreSQL, per exemple, a Postgres Professional.
- Tingueu en compte els riscos associats a la manca de suport.
Per exemple, un càlcul de risc podria semblar així: en cas d'error fatal de la base de dades, el temps d'inactivitat del sistema seria d'1 dia laborable. El benefici previst de l'ús del sistema és de 40 milions de MNT a l'any, la taxa d'accidents s'estima en 1/400, per tant, el risc de manca de suport s'estima en aproximadament 100 milions de MNT per any. Òbviament, "benefici previst" i "freqüència estimada d'accidents" són valors virtuals, però és molt millor tenir aquest model que no tenir-ne cap.
En realitat, el sistema pot ser massa important perquè el cost reputacional del temps d'inactivitat a llarg termini sigui inacceptable, de manera que caldrà suport. Si es permet el temps d'inactivitat, de vegades rebutjar el suport pot ser una bona manera d'estalviar diners.
Suposem que després de tots els càlculs, el cost de la plataforma operativa A durant 5 anys resulta ser de 800 milions de MNT, el cost de la plataforma operativa B és de 650 milions de MNT i el cost de la plataforma operativa C és de 600 milions de MNT. La plataforma C, com a guanyadora, rep un punt complet pel preu, mentre que les plataformes A i B reben una mica menys, en proporció a quantes vegades són més cares. En aquest cas, 0.75 i 0.92 punts, respectivament.
Avaluació d’oportunitats
L'avaluació d'oportunitats es divideix en molts grups, el nombre dels quals només està limitat per la imaginació de la persona que fa l'avaluació. L'opció òptima sembla ser dividir les capacitats en equips que utilitzaran aquestes capacitats; en el nostre exemple, aquests són desenvolupadors, administradors i oficials de seguretat de la informació. Suposem que els pesos d'aquestes funcions es distribueixen com a 40:40:20.
Les funcions de desenvolupament inclouen:
- facilitat de manipulació de dades;
- escalat;
- presència d'índexs secundaris.
La llista de criteris, així com els seus pesos, són molt subjectius. Fins i tot quan es resol el mateix problema, aquestes llistes, pesos d'elements i respostes variaran significativament en funció de la composició del vostre equip. Per exemple, Facebook utilitza MySQL per emmagatzemar dades, i Instagram es basa en Cassandra. És poc probable que els desenvolupadors d'aquestes aplicacions hagin omplert aquestes taules. Només es pot endevinar que Mark Zuckerberg va triar un model relacional complet, pagant-lo amb la necessitat de fragmentació aplicada, mentre que Kevin Systrom va construir l'escala mitjançant la plataforma, sacrificant la facilitat d'accés a les dades.
Les funcions d'administració inclouen:
- capacitats del sistema de còpia de seguretat;
- facilitat de seguiment;
- facilitat de gestió de la capacitat: discs i nodes;
- capacitats de replicació de dades.
Tingueu en compte que les preguntes s'han de redactar de manera quantitativa. Fins i tot podeu posar-vos d'acord sobre com avaluar una funció concreta. Anem, per exemple, a intentar valorar les eines de còpia de seguretat utilitzant l'exemple d'eines subministrades amb el SGBD Oracle:
Eina
Comentari
Avaluació
imp/exp
Càrrega i càrrega de dades
0.1
començar/finalitzar la còpia de seguretat
Còpia de fitxers
0.3
RMAN
Capacitat de còpia incremental
0.7
ZDLRA
Només còpia incremental, recuperació més ràpida al punt
1.0
Si no hi ha uns criteris d'avaluació clars, té sentit demanar a diversos experts que donen puntuacions i després fer-ne una mitjana.
Finalment, només enumerem les funcions de seguretat de la informació:
- disponibilitat de polítiques de gestió de contrasenyes;
- la capacitat de connectar eines d'autenticació externes (LDAP, Kerberos);
- model d'accés;
- capacitats d'auditoria;
- xifratge de dades al disc;
- xifratge durant la transmissió a través de la xarxa (TLS);
- protecció de dades de l'administrador.
Proves de rendiment
Per separat, m'agradaria advertir que no utilitzeu com a arguments els resultats de les proves de càrrega que no heu fet per vosaltres.
En primer lloc, l'estructura de dades i el perfil de càrrega de les aplicacions que s'estan provant poden diferir significativament del problema que resoldreu. Fa uns 10-15 anys, als venedors de bases de dades els encantava lluir els resultats obtinguts en les proves TPC, però ara, sembla, ningú es pren seriosament aquests resultats.
En segon lloc, el rendiment del sistema depèn força de la plataforma per a la qual es va escriure el codi originalment i de quin equip es va dur a terme la prova. He vist moltes proves on es comparava Oracle amb PostgreSQL. Els resultats van des de la superioritat incondicional d'un sistema fins a la superioritat igualment incondicional d'un altre.
I finalment, en tercer lloc, no saps res de qui va fer la prova. Ambdues qualificacions són importants, ja que influeixen en la qualitat de la configuració del sistema operatiu i de la plataforma, així com en la motivació, que influeix en els resultats de la prova més que tots els altres factors combinats.
Si el rendiment és un factor crític, feu la prova vosaltres mateixos, preferiblement amb l'ajuda de les persones que configuraran i mantindran el sistema de producció.
Resultat
Finalment, el resultat de tot el treball realitzat hauria de ser un full de càlcul on es combinen, es multipliquen i es sumen totes les estimacions:
Com enteneu, canviant les escales i ajustant les qualificacions podeu aconseguir qualsevol resultat desitjat, però aquesta és una història completament diferent...
Font: www.habr.com