Risposta breve
Sì , puoi scrivere un benchmark significativo di un caso studiato, se lo fai con cura e capire che se è rilevante per il caso particolare, potrebbe non esserlo per altri casi. Ciò è altrettanto vero quando si confrontano i database dello stesso tipo (database relazionale rispetto a un altro database relazionale) o database di tipi diversi.
No , non è possibile scrivere un benchmark che dimostrerà magicamente che un database specifico è molto meglio di un altro in ogni caso, per ogni applicazione.
Risposta lunga
È sicuramente possibile affermare che "passare da un database a un altro ha migliorato le prestazioni del nostro sito".
Misuri le prestazioni del database precedente tramite la profilazione o le statistiche di runtime raccogliendo informazioni sufficienti sulle query e sulla loro velocità.
Si sposta l'applicazione nel nuovo database.
Fai le stesse misure.
Si confronta.
Ad esempio, se l'elenco completo di 3 182 432 prodotti è stato caricato in 2.834 s. su un vecchio database e si carica in 0,920 s. su un nuovo database, dato che in entrambi i casi l'applicazione ha una cache vuota, è una vittoria: il nuovo database ha migliorato le prestazioni del tuo sito relativamente a questa query.
Ora, come qualsiasi metrica delle prestazioni, è distorta:
D'accordo, la nuova query è più veloce. Ma aspetta, il tuo DBA non sapeva come usare il database che avevi prima , quindi la query che carica tutti i prodotti non è ottimizzata . Se lo riscrivi in questo modo, sarai in grado di caricare quei prodotti in 0,855 s. anziché 2.834.
Ok, hai un risultato migliore. Ma non pensi che sia ingiusto confrontare un database con dati nuovi appena scaricati in un database di 10 anni per il quale è stato eseguito l'ultimo piano di manutenzione tre anni fa? A proposito, non pensi che dovresti aver aggiornato il prodotto del database almeno una volta negli ultimi quattro anni?
Alcune query sono più veloci. Alcuni sono più lenti. Come si calcola il risultato medio per sapere che si sono ottenute prestazioni complessive quando si passa al nuovo database? Ok, il tempo che carichi tutti i 3 182 432 prodotti è più veloce. Ma importa, mentre la query viene eseguita sul sito Web solo in un raro caso in cui un amministratore esegue un'attività specifica che ha eseguito solo due volte negli ultimi dieci anni? D'altro canto, l'esecuzione di tutte le query nella home page per un nuovo utente comporta uno spreco di 0,281 s. con il nuovo database, quando era 0,207 s. con il vecchio database. Questo risultato conta molto di più, soprattutto perché quelle query non possono essere memorizzate nella cache per molto tempo e vengono eseguite decine di migliaia di volte al giorno.
Entrambi i database devono essere testati sugli stessi server , stesso hardware, stessa struttura. Ad esempio, non è possibile testare un database su un singolo disco rigido e l'altro su un RAID1 di due SSD. Quando si esegue la migrazione di un progetto di grandi dimensioni in un nuovo database, è probabile che si debba semplicemente ospitare il nuovo database su centinaia di altri server rack appena distribuiti, quando il database precedente rimarrà comunque sui computer precedenti.
Per riassumere, è possibile eseguire il benchmark delle query del database di un'applicazione e ottenere metriche precise . Ma poi, devi dare un significato ai numeri. In questo stato, è allettante dire che hai ottenuto le prestazioni del sito: altrimenti, la direzione sarebbe arrabbiata nell'apprendere che hai speso migliaia di dollari e mesi di lavoro solo per rallentare le cose.
L'errore più terribile è quello di prendere quelle conclusioni dai parametri di riferimento e concludere una stupidità come "Microsoft SQL Server è tre volte più veloce di Oracle": dire questo è come dire che "Java è meglio di PHP". Definisci meglio. Meglio in quali casi? Per quale tipo di applicazioni? Per quale team di sviluppatori?
Più interpreti e generalizzi, più la cosa diventa irrilevante e insignificante.
La query select [...]che puoi trovare nella revisione # 832 nel file ProductFactory.cs, la riga 117 viene eseguita in 0,5 s. con il nuovo database quando testato nelle condizioni specificate nell'allegato M, requisiti non funzionali, caso 3. Ciò consente di superare il requisito non funzionale 527 (vedere pagina 80, revisione 9). Lo stesso requisito non era soddisfatto con il database precedente, quando i risultati del test erano compresi nell'intervallo 0,9..1,3 s. nelle stesse condizioni.
è significativo per uno sviluppatore e abbastanza preciso da sapere cosa è stato testato, come e quali sono stati i risultati. Questo risponde alla tua domanda numero 2.
Purtroppo, non ha alcun senso per il management. Anziché:
La migrazione del nostro prodotto da MySQL alla versione più recente di Microsoft SQL Server ha migliorato le prestazioni complessive del nostro prodotto di cinque, riducendo allo stesso tempo i costi di due e l'impronta ambientale di tre. Riteniamo che la migrazione di tutte le nostre applicazioni a Microsoft SQL Server il prossimo anno darà risultati ancora migliori e aumenterà la competitività del nostro mercato.
è un semplice jibber-jabber di marketing e, tecnicamente, non significa nulla, ma sorprendentemente ha un valore per i dipartimenti di gestione e marketing.
Infine, possiamo confrontare diversi tipi di database? Direi che è totalmente possibile. Diciamo che ho un sito web che ospita foto di grandi dimensioni. Quelle foto sono archiviate in varbinary(max)Microsoft SQL Server 2005 (quindi non posso usarle filestream). Sono preoccupato per le prestazioni durante il caricamento di quelle foto, quindi decido di archiviarle come file, usando il file system come nuovo database. Innanzitutto, questi file sono archiviati sullo stesso computer del database. Profilo la nuova soluzione e ottengo il risultato che mostra che, nel mio caso, i file vengono caricati il 4% più velocemente dal file system che da Microsoft SQL Server. Il benchmark è molto chiaro. Ora posso pensare di distribuire un server dedicato ottimizzato per l'archiviazione diretta dei file, piuttosto che utilizzare il server ottimizzato per Microsoft SQL Server.