– Questo è incredibile, – disse ad alta voce senza rivolgersi a nessuno. – È incredibile! È scritto chiaramente: l'obiettivo principale della società è l'estrazione di profitti nell'interesse degli azionisti. Pensateci! Non hanno paura di niente!
Yuli Dubov, «Il male minore»
Vedendo un titolo del genere, avrete sicuramente già deciso che l'articolo è o una stupidaggine o una provocazione. Ma non affrettatevi a trarre conclusioni: i dipendenti delle grandi aziende, in particolare di quelle con partecipazione statale, spesso devono confrontare diverse piattaforme, comprese quelle totalmente diverse – come quelle menzionate nel titolo.
Naturalmente, nessuno confronta i sistemi di gestione di database, poiché i loro punti di forza e di debolezza sono ben noti. Di solito, i confronti riguardano piattaforme che risolvono qualche problema applicativo. In questo articolo mostrerò la metodologia utilizzata in questo caso, prendendo come esempio i database, un argomento ben noto ai lettori di Habr. Dunque,
Motivazione
Quando si inizia un progetto didattico o un progetto hobby, la motivazione per la scelta della piattaforma può essere la più varia: «questa piattaforma è quella che conosco meglio», «mi interessa capire questa», «qui c'è la migliore documentazione»... Nel caso di un'azienda commerciale, il criterio di scelta è uno solo: quanto costerà e cosa otterrò per quei soldi.
Naturalmente, si desidera pagare il meno possibile e ricevere il più possibile. Tuttavia, è necessario decidere cosa è più importante: pagare meno o ottenere di più, e attribuire un peso a ciascun nodo. Supponiamo che ci interessi di più una soluzione di qualità rispetto a una economica, e assegniamo al nodo «Costo» un peso del 40%, mentre al nodo «Funzionalità» un peso del 60%.
Nelle grandi aziende, di solito è esattamente l'opposto: il peso del costo non scende mai sotto il 50%, e può anche superare il 60%. Nell'esempio modellistico, ciò che conta è che il peso totale dei nodi figli di qualsiasi nodo genitore deve essere 100%.
Criteri di esclusione
Al sito sono note circa 500 sistemi di gestione di database. Naturalmente, se si deve scegliere una piattaforma target tra così tante opzioni, potrebbe risultare un articolo di panoramica, ma non un progetto commerciale. Per restringere lo spazio di scelta, vengono formulati criteri di esclusione; e se una piattaforma non soddisfa tali 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 generali:
- presenza di supporto commerciale in Italia;
- codice sorgente aperto;
- presenza della piattaforma nel Registro del Ministero delle Comunicazioni;
- presenza della piattaforma in qualche classifica (ad esempio, tra i primi cento nella classifica db-engines.com);
- presenza di esperti sul mercato (ad esempio, in base ai risultati della ricerca del nome della piattaforma nei curriculum sul sito hh.ru).
Alla fine, potrebbero esserci criteri specifici per l'azienda:
- presenza di specialisti nel personale;
- compatibilità con il sistema di monitoraggio X o con il sistema di backup Y, su cui tutto il supporto è basato…
La cosa più importante è avere un elenco di criteri di esclusione. Altrimenti, ci sarà sempre un qualche esperto (o «esperto») molto ascoltato dalla direzione, che 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'hardware.
Se i sistemi sono all'incirca della stessa categoria (ad esempio, Microsoft SQL Server e PostgreSQL), è possibile considerare, per semplificare, che il numero di hardware per entrambe le soluzioni sarà all'incirca lo stesso. Questo permetterà di non stimare l'hardware, risparmiando così molto tempo e sforzi. Tuttavia, se si stanno confrontando sistemi completamente diversi (ad esempio, Oracle contro Redis), è ovvio che, per una corretta valutazione, è necessario effettuare un sizing (calcolo della quantità di hardware). Il sizing di un sistema inesistente è un compito piuttosto ingrato, quindi si cerca di evitare tali confronti. È semplice: nelle condizioni di esclusione si scrivono zero perdite di dati e modello relazionale oppure, viceversa, un carico di 50.000 transazioni al secondo.
Per valutare le licenze, è sufficiente chiedere al fornitore o ai suoi partner il costo della licenza per un numero fisso di core e supporto per un periodo definito. In genere, le aziende hanno già stabilito rapporti solidi con i fornitori di software, e se il dipartimento operazioni DB non riesce a fornire autonomamente informazioni sui costi, è sufficiente una sola email per ottenerle.
Diversi fornitori possono avere metriche di licensing diverse: in base al numero di core, al volume dei dati o al numero di nodi. Un database standby può essere gratuito o può essere licenziato come il principale. Se si riscontrano delle differenze nelle metriche, sarà necessario descrivere dettagliatamente il modello di prova e calcolare il costo delle licenze per il banco di prova.
Un punto importante per un confronto corretto sono le identiche condizioni di supporto. Ad esempio, il supporto per Oracle costa il 22% del prezzo della licenza all'anno, mentre per il supporto di PostgreSQL non si deve pagare. È corretto confrontare così? No, perché un errore che non può essere risolto autonomamente ha conseguenze completamente diverse: nel primo caso, gli esperti del supporto agiranno rapidamente per risolverlo, mentre nel secondo caso c'è il rischio di ritardi nel progetto o di inattività del sistema pronto per un periodo indefinito.
Si possono uniformare le condizioni di calcolo in tre modi:
- Utilizzare Oracle senza supporto (in realtà questo non accade mai).
- Acquistare supporto per PostgreSQL – ad esempio, dalla società Postgres Professional.
- Tenere conto dei rischi associati all'assenza di supporto.
Ad esempio, il calcolo dei rischi potrebbe essere così: in caso di un guasto irreparabile del database, l'inattività del sistema sarà di 1 giorno lavorativo. Il profitto previsto dall'uso del sistema è di 40 miliardi di tugrik mongoli all'anno, la frequenza degli incidenti è stimata come 1/400, pertanto il rischio di mancanza di supporto è valutato in circa 100 milioni di tugrik mongoli all'anno. È evidente che il "profitto previsto" e la "frequenza degli incidenti stimata" sono grandezze virtuali, ma è molto meglio avere un modello simile che non averne affatto.
In realtà, il sistema può essere troppo importante, e le perdite reputazionali dovute a un prolungato inattività sarebbero inaccettabili, quindi è necessaria assistenza. Se l'inattività è consentita, a volte rinunciare al supporto può essere un buon modo per risparmiare.
Supponiamo che dopo tutti i calcoli, il costo di gestione della piattaforma A per 5 anni sia stato di 800 milioni di tugrik mongoli, il costo di gestione della piattaforma B sia di 650 milioni di tugrik, mentre il costo di gestione della piattaforma C sia di 600 milioni di tugrik. La piattaforma C, vincitrice, ottiene un punteggio completo per il costo, mentre le piattaforme A e B ricevono punteggi leggermente inferiori, proporzionalmente a quanto sono più costose. In questo caso, rispettivamente 0.75 e 0.92 punti.
Valutazione delle capacità
La valutazione delle capacità è suddivisa in numerosi gruppi, il cui numero è limitato solo dalla fantasia di chi effettua la valutazione. L'opzione ottimale sembra essere la suddivisione delle capacità per team che utilizzeranno queste capacità; nel nostro esempio, 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 includono:
- facilità di manipolazione dei dati;
- scalabilità;
- presenza di indici secondari.
L'elenco dei criteri, così come i loro pesi, è molto soggettivo. Anche nella risoluzione dello stesso problema, questi elenchi, i pesi degli elementi e le risposte varieranno notevolmente a seconda della composizione del proprio team. Ad esempio, Facebook utilizza MySQL per l'archiviazione dei dati, mentre Instagram è basato su Cassandra. È improbabile che gli sviluppatori di queste applicazioni abbiano compilato tali tabelle. Si può solo ipotizzare che Mark Zuckerberg abbia scelto un modello relazionale completo, pagando per questo il prezzo necessario per la sharding applicativa, mentre Kevin Systrom abbia integrato la scalabilità nei mezzi della piattaforma, sacrificando la facilità di accesso ai dati.
Le funzioni di amministrazione includono:
- capacità del sistema di backup;
- facilità di monitoraggio;
- facilità di gestione delle risorse - dischi e nodi;
- capacità di replicazione dei dati.
Si prega di notare che la formulazione delle domande deve consentire una valutazione quantitativa. Si può anche concordare come valutare una determinata funzione. Proviamo, ad esempio, a valutare gli strumenti di backup utilizzando gli strumenti forniti con il 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
Solo copia incrementale, il ripristino più veloce a un punto
1.0
Se mancano criteri chiari per la valutazione, ha senso chiedere a diversi esperti di fornire delle valutazioni e poi fare una media.
Infine, elenchiamo semplicemente le funzioni di sicurezza delle informazioni:
- esistenza di politiche di gestione delle password;
- possibilità di collegare strumenti di autenticazione esterni (LDAP, Kerberos);
- modello di accesso basato sui ruoli;
- capacità di audit;
- crittografia dei dati su disco;
- crittografia durante la trasmissione in rete (TLS);
- protezione dei dati dagli amministratori.
Test di prestazioni
Vorrei preliminarmente avvisare di non utilizzare come argomenti i risultati di test di carico condotti da terzi.
In primo luogo, la struttura dei dati e il profilo di carico delle applicazioni testate possono differire notevolmente da quello dell'attività che si intende svolgere. Circa 10-15 anni fa, i produttori di database amavano vantarsi dei risultati ottenuti nei test TPC, ma ora sembra che nessuno prenda sul serio questi risultati.
In secondo luogo, le prestazioni del sistema dipendono in modo significativo dalla piattaforma per cui il codice è stato inizialmente scritto e dall'hardware su cui è stato eseguito il test. Ho visto molti test in cui Oracle è stato confrontato con PostgreSQL. I risultati variano da una netta superiorità di un sistema a un'altra altrettanto netta superiorità dell'altro.
Infine, in terzo luogo, non si sa nulla su chi ha condotto il test. È importante sia la competenza, che influisce sulla qualità della configurazione del sistema operativo e della piattaforma, sia la motivazione, che può influenzare i risultati del test più di tutti gli altri fattori messi insieme.
Se le prestazioni sono un fattore critico, esegui il test autonomamente, preferibilmente coinvolgendo specialisti che si occuperanno della configurazione e della manutenzione del sistema industriale.
Risultato
Infine, il risultato di tutto il lavoro svolto dovrebbe essere un foglio di calcolo in cui tutte le valutazioni sono consolidate, moltiplicate e sommate:
Come potete capire, modificando i pesi e regolando le valutazioni è possibile ottenere qualsiasi risultato desiderato, ma questa è un'altra storia...
Fonte: habr.com
