"Questo è necessario", disse ad alta voce, senza rivolgersi a nessuno. - Questo è necessario! Questo è esattamente ciò che dice: il compito principale di un'azienda è realizzare profitti nell'interesse degli azionisti. Ci pensiamo! Non hanno paura di nulla!
Yuliy Dubov, “Il male minore”
Vedendo un titolo del genere, probabilmente hai già deciso che l'articolo è stupidità o provocazione. Ma non affrettatevi a trarre conclusioni: i dipendenti di grandi aziende, in particolare quelle a partecipazione statale, molto spesso devono confrontare piattaforme diverse, anche completamente diverse, ad esempio quelle nel titolo.
Naturalmente nessuno paragona i DBMS in questo modo, perché i loro punti di forza e di debolezza sono ben noti. Di norma, le piattaforme che risolvono alcuni problemi applicativi sono soggette a confronto. Nell'articolo mostrerò la metodologia utilizzata in questo caso, utilizzando l'esempio dei database come argomento familiare in prima persona ai lettori di Habr. COSÌ,
motivazione
Quando si avvia un progetto educativo o un progetto hobbistico, le motivazioni per scegliere una piattaforma possono essere le più diverse: “questa è la piattaforma che conosco meglio”, “mi interessa capire questa”, “ecco la migliore documentazione” ... Nel caso di un'azienda commerciale, il criterio di selezione è lo stesso: quanto dovrò pagare e cosa otterrò con questi soldi.
Naturalmente, vuoi pagare meno e ottenere di più. Tuttavia, devi decidere cosa è più importante: pagare di meno o ottenere di più, e assegnare un peso a ciascun nodo. Supponiamo che una soluzione di alta qualità sia per noi più importante di una economica e assegniamo un peso del 40% al nodo “Costi” e del 60% al nodo “Opportunità”.
Nelle grandi aziende, di solito è vero il contrario: il peso dei costi non scende al di sotto del 50% e forse supera il 60%. Nell'esempio del modello, tutto ciò che è importante è che il peso totale dei nodi figli di qualsiasi nodo genitore sia pari al 100%.
Condizioni di interruzione
sito web Sono conosciuti circa 500 sistemi di gestione di database. Naturalmente, se scegli una piattaforma di destinazione tra così tante opzioni, potresti ritrovarti con un articolo di recensione, ma non con un progetto commerciale. Per ridurre lo spazio di scelta vengono formulati criteri di cut-off e se la piattaforma non soddisfa questi criteri non viene considerata.
I criteri di esclusione possono riguardare caratteristiche tecnologiche, ad esempio:
- Garanzie ACID;
- modello di dati relazionali;
- Supporto del linguaggio SQL (nota, questo non è lo stesso del “modello relazionale”);
- possibilità di scalatura orizzontale.
Possono esserci criteri generali:
- disponibilità di supporto commerciale in Russia;
- fonte aperta;
- disponibilità della piattaforma nel Registro del Ministero delle Telecomunicazioni e delle Comunicazioni di Massa;
- presenza della piattaforma in alcuni rating (ad esempio, nei primi cento del rating db-engines.com);
- la presenza di esperti nel mercato (ad esempio, in base ai risultati della ricerca del nome della piattaforma in un curriculum sul sito hh.ru).
Dopotutto, potrebbero esserci criteri specifici dell'azienda:
- disponibilità di specialisti nel personale;
- compatibilità con il sistema di monitoraggio X o il sistema di backup Y, su cui si basa tutto il supporto...
La cosa più importante è che ci sia un elenco di criteri di esclusione. Altrimenti ci sarà sicuramente qualche esperto (o “esperto”) che gode di particolare fiducia da parte del management che dirà “perché non hai scelto la piattaforma Z, so che è la migliore”.
Costo stimato
Il costo della soluzione è ovviamente composto dal costo delle licenze, dal costo del supporto e dal costo delle attrezzature.
Se i sistemi appartengono approssimativamente alla stessa classe (ad esempio, Microsoft SQL Server e PostgreSQL), per semplicità possiamo supporre che la quantità di apparecchiature per entrambe le soluzioni sarà approssimativamente la stessa. Ciò ti consentirà di non valutare l'attrezzatura, risparmiando così molto tempo e fatica. Se devi confrontare sistemi completamente diversi (ad esempio Oracle vs. Redis), allora è ovvio che per una corretta valutazione è necessario effettuare il dimensionamento (calcolo della quantità di apparecchiature). Dimensionare un sistema inesistente è un compito davvero ingrato, quindi si cerca comunque di evitare tali confronti. Questo è facile da fare: nelle condizioni di interruzione vengono scritti zero perdite di dati e un modello relazionale, o viceversa, un carico di 50mila transazioni al secondo.
Per valutare le licenze è sufficiente chiedere al venditore o ai suoi partner il costo di una licenza per un numero fisso di core e supporto per un periodo fisso. Di norma, le aziende hanno già forti rapporti con i fornitori di software e se il reparto operativo del database non è in grado di rispondere da solo alla domanda sui costi, è sufficiente una lettera per ottenere queste informazioni.
Diversi fornitori possono avere parametri di licenza diversi: per numero di core, volume di dati o numero di nodi. La base di standby può essere gratuita oppure può essere concessa in licenza allo stesso modo di quella principale. Se si riscontrano differenze nelle metriche, dovrai descrivere dettagliatamente lo stand modello e calcolare il costo delle licenze per lo stand.
Un punto importante per un confronto corretto sono le stesse condizioni di supporto. Ad esempio, il supporto Oracle costa il 22% del prezzo della licenza all'anno, ma non devi pagare per il supporto PostgreSQL. È corretto fare un paragone in questo modo? No, perché un errore che non può essere risolto da solo ha conseguenze completamente diverse: nel primo caso gli specialisti dell'assistenza ti aiuteranno rapidamente a risolverlo, ma nel secondo caso c'è il rischio di ritardare il progetto o di tempi di inattività del prodotto finito sistema per un periodo indeterminato.
È possibile equalizzare le condizioni di calcolo in tre modi:
- Utilizza Oracle senza supporto (in realtà ciò non avviene).
- Acquista il supporto per PostgreSQL, ad esempio da Postgres Professional.
- Prendere in considerazione i rischi associati alla mancanza di supporto.
Ad esempio, un calcolo del rischio potrebbe assomigliare a questo: in caso di guasto irreversibile del database, il tempo di inattività del sistema sarebbe di 1 giorno lavorativo. Il profitto previsto derivante dall'utilizzo del sistema è di 40 miliardi di MNT all'anno, il tasso di incidenti è stimato in 1/400, quindi il rischio di mancanza di supporto è stimato a circa 100 milioni di MNT all'anno. Ovviamente, il “profitto pianificato” e la “frequenza stimata degli incidenti” sono valori virtuali, ma è molto meglio avere un modello del genere che non averne alcuno.
In realtà, il sistema potrebbe essere troppo importante perché il costo reputazionale dei tempi di inattività a lungo termine sia inaccettabile, quindi sarà necessario supporto. Se sono consentiti tempi di inattività, rifiutare il supporto a volte può essere un buon modo per risparmiare denaro.
Supponiamo che dopo tutti i calcoli il costo operativo della piattaforma A per 5 anni risulti essere di 800 milioni di MNT, il costo della piattaforma operativa B è di 650 milioni di MNT e il costo della piattaforma operativa C è di 600 milioni di MNT. La piattaforma C, in quanto vincitrice, riceve un punto intero per il prezzo, mentre le piattaforme A e B ricevono un po' meno, in proporzione a quante volte sono più costose. In questo caso – 0.75 e 0.92 punti, rispettivamente.
Valutazione delle opportunità
La valutazione delle opportunità è divisa in molti gruppi, il cui numero è limitato solo dalla fantasia di chi effettua la valutazione. L'opzione ottimale sembra essere quella di dividere le capacità in team che le utilizzeranno; nel nostro esempio si tratta di sviluppatori, amministratori e responsabili della sicurezza delle informazioni. Supponiamo che i pesi di queste funzioni siano distribuiti come 40:40:20.
Le funzioni di sviluppo includono:
- facilità di manipolazione dei dati;
- ridimensionamento;
- presenza di indici secondari.
L'elenco dei criteri, così come il loro peso, sono molto soggettivi. Anche quando si risolve lo stesso problema, questi elenchi, pesi degli elementi e risposte varieranno in modo significativo a seconda della composizione del tuo team. Ad esempio, Facebook utilizza MySQL per archiviare i dati e Instagram è basato su Cassandra. È improbabile che gli sviluppatori di queste applicazioni abbiano compilato tali tabelle. Si può solo immaginare che Mark Zuckerberg abbia scelto un modello relazionale a tutti gli effetti, pagandolo con la necessità di sharding applicato, mentre Kevin Systrom ha costruito il ridimensionamento utilizzando la piattaforma, sacrificando la facilità di accesso ai dati.
Le funzioni amministrative includono:
- capacità del sistema di backup;
- facilità di monitoraggio;
- facilità di gestione della capacità – dischi e nodi;
- capacità di replica dei dati.
Si prega di notare che le domande devono essere formulate in modo quantitativo. Puoi anche concordare come valutare una particolare funzione. Proviamo, ad esempio, a valutare gli strumenti di backup utilizzando l'esempio degli strumenti forniti con Oracle DBMS:
Strumento
commento
Valutazione
imp/espr
Caricamento e caricamento dei dati
0.1
iniziare/terminare il backup
Copiare file
0.3
RMAN
Funzionalità di copia incrementale
0.7
ZDLRA
Solo copia incrementale, ripristino più rapido al punto
1.0
Se non esistono criteri di valutazione chiari, ha senso chiedere a diversi esperti di fornire valutazioni e poi fare una media.
Infine elenchiamo semplicemente le funzioni di sicurezza informatica:
- disponibilità di politiche di gestione delle password;
- la possibilità di connettere strumenti di autenticazione esterni (LDAP, Kerberos);
- modello di accesso;
- capacità di audit;
- crittografia dei dati su disco;
- crittografia durante la trasmissione in rete (TLS);
- protezione dei dati da parte dell'amministratore.
Test delle prestazioni
Separatamente, vorrei mettere in guardia dall'utilizzare come argomenti i risultati di eventuali test di carico che non sono stati effettuati da te.
Innanzitutto, la struttura dei dati e il profilo di carico delle applicazioni testate potrebbero differire in modo significativo dal problema che intendi risolvere. Circa 10-15 anni fa, i fornitori di database amavano ostentare i risultati ottenuti nei test TPC, ma ora, a quanto pare, nessuno prende sul serio questi risultati.
In secondo luogo, le prestazioni del sistema dipendono fortemente dalla piattaforma per la quale è stato originariamente scritto il codice e da quale apparecchiatura è stato eseguito il test. Ho visto molti test in cui Oracle è stato confrontato con PostgreSQL. I risultati vanno dalla superiorità incondizionata di un sistema alla superiorità altrettanto incondizionata di un altro.
E infine, in terzo luogo, non sai nulla di chi ha effettuato il test. Entrambe le qualifiche sono importanti, poiché influenzano la qualità della configurazione del sistema operativo e della piattaforma, nonché la motivazione, che influenza i risultati del test più di tutti gli altri fattori messi insieme.
Se le prestazioni sono un fattore critico, conduci tu stesso il test, preferibilmente con l'aiuto delle persone che configureranno e manterranno il sistema di produzione.
risultato
Infine, il risultato di tutto il lavoro svolto dovrebbe essere un foglio di calcolo in cui tutte le stime vengono combinate, moltiplicate e riassunte:
Come hai capito, cambiando le scale e aggiustando le valutazioni puoi ottenere qualsiasi risultato desiderato, ma questa è una storia completamente diversa...
Fonte: habr.com