(Parlando da un punto di vista MySQL...)
Alcune "regole pratiche":
- Singolo
INSERT:10 ms - 100 o più righe inserite da un singolo
INSERT:10 volte più veloce per riga. BEGIN; INSERT...; INSERT...; ... COMMIT;:Anche 10x.- Quanto sopra presuppone HDD; L'SSD potrebbe essere 10 volte più veloce.
- Se più connessioni stanno facendo inserimenti, possono poter correre in parallelo. 10 thread potrebbero essere in grado di eseguire 5 volte il lavoro nello stesso tempo trascorso. (Naturalmente, questo può aggiungere complessità indesiderata all'app.)
Cifre simili per UPDATE , anche se non è facile eseguire aggiornamenti diversi su righe diverse con un'unica query.
Il tuo test mostra 8,5 ms per riga UPDATEd quando si esegue una riga alla volta. In batch con BEGIN...COMMIT probabilmente ci vorranno circa 85 ms per tutte le 100 righe, anche su HDD.
Alcune applicazioni si prestano al batching; alcuni no. Se vuoi parlare del miglioramento delle prestazioni di MySQL, dobbiamo entrare nei dettagli della tua applicazione.
I contatori "Mi piace" e "Visualizza" possono devono essere spostati in una tabella "parallela" poiché tendono ad essere aggiornati uno alla volta, con alcune interferenze con altre attività. Tendono anche a consentire automaticamente il multi-threading, quindi molto meno di 850 ms per 100. In condizioni di attività molto elevate (oltre, ad esempio, 1.000 visualizzazioni al secondo), tali contatori possono essere raggruppati artificialmente tramite codice app aggiuntivo.
Riscrivi il tuo benchmark per riflettere l'attività che avverrà nell'applicazione reale. (Sto indovinando che gli Aggiornamenti avvengano in parallelo, non in serie. E saranno distribuiti casualmente nel tempo.)
Un'altra cosa... Se ogni "conteggio visualizzazioni" arriva a un server web, allora c'è anche connessione e disconnessione; da qui il trascorso è probabile che il tempo sia superiore a 8,5 ms. Ma "trascorso" non è il problema critico; il vero problema è "quanti aggiornamenti possono essere eseguiti al secondo".)
E un'altra cosa... Se esegui il test "parallelo", non raggiungere la stessa riga per ogni richiesta. Probabilmente sarà molto più lento che se colpissi righe diverse. (Colpire una riga casuale sarebbe meglio. Avere una distorsione in quale riga colpire sarebbe ancora più realistico.)
