– Non ci posso credere, – disse ad alta voce senza rivolgersi a nessuno. – Non ci posso credere! È scritto chiaramente: il principale obiettivo della società è il profitto a beneficio degli azionisti. Pensateci! Non hanno paura di nulla!
Yuliy Dubov, «Il male minore»
Vedendo un titolo del genere, avrete già pensato che l'articolo sia una sciocchezza o una provocazione. Ma non affrettatevi a giudicare: ai dipendenti delle grandi aziende, in particolare delle aziende a partecipazione statale, capita abbastanza spesso di confrontare diverse piattaforme, anche tra loro molto diverse – come quelle menzionate nel titolo.
Certo, nessuno confronta i DBMS, poiché i loro punti di forza e di debolezza sono ben noti. Di solito, vengono messe a confronto piattaforme che risolvono un determinato compito pratico. In questo articolo mostrerò la metodologia utilizzata a tal fine, prendendo come esempio le basi di dati, un tema ben noto ai lettori di Habr. Dunque,
Motivazione
Quando avvii un progetto di studio o un progetto per hobby, le motivazioni per scegliere una piattaforma possono essere molto varie: «questa piattaforma la conosco meglio», «mi interessa capire questa», «qui c'è la migliore documentazione»… Nel caso di un'azienda commerciale, il criterio di scelta è uno solo: quanto dovrò pagare e cosa riceverò in cambio.
Naturalmente, si desidera pagare di meno e ricevere di più. Tuttavia, è necessario decidere cosa sia più importante: pagare meno o ricevere di più, e attribuire a ciascun nodo un peso. Supponiamo che per noi sia più importante una soluzione di qualità piuttosto che una economica, quindi attribuiamo al nodo «Costo» un peso del 40% e al nodo «Funzionalità» del 60%.
Nelle grandi corporazioni di solito è il contrario: il peso del costo non scende mai sotto il 50% e può anche superare il 60%. Nell'esempio modellistico, l'importante è che il peso totale dei nodi figli di qualsiasi nodo genitore sia 100%.
Condizioni di esclusione
Sito Ci sono circa 500 sistemi di gestione dei database. Naturalmente, se si deve scegliere una piattaforma target tra così tante opzioni, si può ottenere un articolo di revisione, ma non un progetto commerciale. Per ridurre lo spazio di scelta, vengono formulate delle criteri di esclusione, e se una piattaforma non soddisfa questi criteri, non viene considerata.
I criteri di esclusione possono riguardare caratteristiche tecnologiche, ad esempio:
- garanzie ACID;
- modello relazionale dei dati;
- supporto per il linguaggio SQL (notare che non è la stessa cosa del «modello relazionale»);
- possibilità di scalabilità orizzontale.
Possono esserci criteri di carattere generale:
- presenza di supporto commerciale in Russia;
- codice sorgente aperto;
- presenza della piattaforma nel Registro del Ministero delle Telecomunicazioni;
- presenza della piattaforma in qualche classifica (ad esempio, tra i primi cento nella classifica di db-engines.com);
- presenza di esperti nel mercato (ad esempio, attraverso risultati della ricerca del nome della piattaforma nei CV su hh.ru).
Infine, possono esserci criteri specifici per l'azienda:
- presenza di specialisti nello staff;
- compatibilità con il sistema di monitoraggio X o con il sistema di backup Y, su cui si basa tutto il supporto…
La cosa più importante è avere un elenco di criteri di esclusione. Altrimenti, ci sarà sicuramente un esperto (o un 'esperto') che gode della particolare fiducia della direzione, il quale dirà 'perché non avete scelto la piattaforma Z, so che è la migliore'.
Valutazione dei costi
Il costo della soluzione è ovviamente composto dal costo delle licenze, dal costo del supporto e dal costo dell'attrezzatura.
Se i sistemi appartengono più o meno alla stessa categoria (ad esempio, Microsoft SQL Server e PostgreSQL), per semplificare si può considerare che la quantità di hardware necessaria per entrambe le soluzioni sarà più o meno la stessa. Questo permetterà di non dover valutare l'hardware, risparmiando così tempo ed energie. Tuttavia, se si devono confrontare sistemi completamente diversi (come Oracle vs. Redis), è evidente che per una valutazione corretta è necessario effettuare un sizing (calcolo della quantità di hardware). Effettuare un sizing su un sistema inesistente è un compito piuttosto ingrato, quindi si cerca di evitare tale confronto. È semplice: nelle condizioni restrittive si indicano perdita di dati pari a zero e modello relazionale, oppure viceversa – un carico di 50.000 transazioni al secondo.
Per valutare le licenze, è sufficiente richiedere al fornitore o ai suoi partner il costo della licenza per un numero fisso di core e supporto per un periodo determinato. Di solito, le aziende hanno già stabilito solidi rapporti con i fornitori di software, e se il dipartimento di gestione delle basi di dati non può rispondere alla domanda sul costo autonomamente, per ottenere queste informazioni basta una sola email.
Diverse aziende fornitrici possono avere metriche di licenza diverse: basate sul numero di core, sul volume dei dati o sul numero di nodi. Una base standby può essere gratuita oppure può essere soggetta a licenza come la base principale. Se vengono rilevate delle differenze nelle metriche, sarà necessario descrivere dettagliatamente il modello di stand e calcolare il costo delle licenze per lo stand.
Un aspetto importante per un confronto corretto è avere condizioni di supporto identiche. Ad esempio, il supporto per Oracle costa il 22% del prezzo della licenza all'anno, mentre per il supporto di PostgreSQL non è necessario pagare nulla. È corretto confrontare in questo modo? No, perché gli effetti di un errore che non può essere risolto autonomamente sono completamente diversi: nel primo caso, gli specialisti del supporto possono intervenire rapidamente per risolvere il problema, mentre nel secondo caso c'è il rischio di ritardi nel progetto o di inattività del sistema già pronto per un periodo indefinito.
Le condizioni di calcolo possono essere equiparate in tre modi:
- Utilizzare Oracle senza supporto (in realtà, ciò è inesistente).
- Acquistare supporto per PostgreSQL – ad esempio, da Postgres Professional.
- Includere nel calcolo i rischi legati all'assenza di supporto.
Ad esempio, la valutazione dei rischi potrebbe apparire così: in caso di un guasto irreparabile del database, il fermo della sistema durerebbe 1 giorno lavorativo. Il profitto previsto dall'utilizzo del sistema è di 40 miliardi di tugrik mongoli all'anno, e la frequenza degli incidenti è stimata a 1/400, pertanto il rischio di mancanza di supporto è valutato a circa 100 milioni di tugrik mongoli all'anno. È evidente che il "profitto previsto" e la "frequenza stimata degli incidenti" sono valori virtuali, ma avere un modello del genere è molto meglio che non averne affatto.
In realtà, il sistema può essere troppo importante e le perdite reputazionali a causa di un prolungato fermo potrebbero essere inaccettabili, quindi sarà necessario il supporto. Tuttavia, se il fermo è accettabile, a volte rinunciare al supporto può essere un buon modo per risparmiare.
Supponiamo che, dopo tutti i calcoli, il costo operativo della piattaforma A per 5 anni sia di 800 milioni di tugrik mongoli, il costo operativo della piattaforma B sia di 650 milioni di tugrik, e il costo operativo della piattaforma C sia di 600 milioni di tugrik. La piattaforma C, essendo la vincitrice, ottiene un punteggio pieno, mentre le piattaforme A e B ricevono punteggi leggermente inferiori, proporzionalmente a quanto sono più costose. In questo caso, ottengono rispettivamente 0.75 e 0.92 punti.
Valutazione delle opportunità
La valutazione delle opportunità si suddivide in diverse categorie, il numero delle quali è limitato solo dalla fantasia di chi conduce la valutazione. Una soluzione ottimale sembra essere quella di suddividere le opportunità in base ai team che le utilizzeranno; nel nostro caso, questi sono sviluppatori, amministratori e ufficiali della sicurezza informatica. Supponiamo che i pesi di queste funzioni siano distribuiti come 40:40:20.
Le funzioni di sviluppo possono includere:
- facilità di manipolazione dei dati;
- scalabilità;
- presenza di indici secondari.
La lista dei criteri e i loro pesi sono molto soggettivi. Anche per la stessa problematica, queste liste, i pesi degli elementi e le risposte differiscono notevolmente a seconda della composizione del tuo team. Ad esempio, Facebook utilizza MySQL per l'archiviazione dei dati, mentre Instagram è costruito su Cassandra. È improbabile che gli sviluppatori di queste applicazioni abbiano compilato tali tabelle. Possiamo solo ipotizzare che Mark Zuckerberg abbia scelto un modello relazionale completo, pagando il prezzo della necessità di sharding applicativo, mentre Kevin Systrom ha impostato la scalabilità tramite la piattaforma, sacrificando la comodità di accesso ai dati.
Le funzioni di amministrazione comprendono:
- le capacità del sistema di backup;
- la facilità di monitoraggio;
- la facilità nella gestione delle risorse – dischi e nodi;
- le capacità di replica dei dati.
Si prega di notare che le formulazioni delle domande devono consentire una valutazione quantitativa. È possibile anche concordare un metodo per valutare ogni singola funzione. Proviamo, ad esempio, a dare valutazioni sugli strumenti di backup utilizzando quelli forniti con i DBMS Oracle:
Strumento
Commento
Valutazione
imp/exp
Esportazione e importazione dei dati
0.1
inizio/fine backup
Copia di file
0.3
RMAN
Possibilità di copia incrementale
0.7
ZDLRA
Copia incrementale solo, ripristino più rapido al punto
1.0
Se non ci sono criteri di valutazione chiari, ha senso chiedere a diversi esperti di fornire valutazioni e poi fare una media.
Infine, elenchiamo semplicemente le funzioni della sicurezza informatica:
- presenza di politiche di gestione delle password;
- possibilità di collegamento a strumenti di autenticazione esterni (LDAP, Kerberos);
- modello di accesso basato sui ruoli;
- capacità di audit;
- cifratura dei dati su disco;
- cifratura durante la trasmissione sulla rete (TLS);
- protezione dei dati dall'amministratore.
Test delle prestazioni
Vorrei anche mettere in guardia dall'utilizzare come argomenti i risultati di test di carico effettuati da altri.
In primo luogo, la struttura dei dati e il profilo di carico delle applicazioni testate possono differire notevolmente dalla questione che intendi risolvere. Dieci o quindici anni fa, i produttori di database amavano vantarsi dei risultati ottenuti nei test TPC, ma adesso sembra che nessuno prenda più sul serio tali risultati.
In secondo luogo, le prestazioni del sistema dipendono fortemente dalla piattaforma per la quale il codice è stato originariamente scritto e dall'hardware su cui è stato eseguito il test. Ho visto molti test in cui Oracle è stata paragonata a PostgreSQL. I risultati vanno dalla netta superiorità di un sistema all'altra altrettanto netta superiorità dell'altro.
Infine, terzo punto, non sapete nulla su chi ha condotto il test. È importante sia la qualificazione, che influisce sulla qualità della configurazione del sistema operativo e della piattaforma, sia la motivazione, che influisce sui risultati del test più di tutti gli altri fattori messi insieme.
Se le prestazioni sono un fattore critico, eseguite il test autonomamente, preferibilmente con la partecipazione di specialisti che si occuperanno della configurazione e del supporto del sistema industriale.
Risultato
Infine, il risultato di tutto il lavoro svolto dovrebbe essere un foglio di calcolo, dove tutte le valutazioni sono riunite, moltiplicate e sommate:
Come potete capire, modificando i pesi e regolando le valutazioni si può ottenere qualsiasi risultato richiesto, ma questa è un'altra storia completamente diversa...
Fonte: habr.com
