AWS è il provider cloud n. 1 per l'hosting di database open source e il cloud di riferimento per le implementazioni MySQL. Man mano che le organizzazioni continuano a migrare al cloud, è importante affrontare problemi di prestazioni, come latenza elevata, velocità effettiva ridotta e ritardo di replica con distanze maggiori tra gli utenti e l'infrastruttura cloud. Sebbene molti utenti AWS utilizzino per impostazione predefinita la loro soluzione di database gestita, Amazon RDS, sono disponibili alternative che possono migliorare le prestazioni di MySQL su AWS attraverso opzioni di personalizzazione avanzate e supporto illimitato del tipo di istanza EC2. ScaleGrid offre un'interessante alternativa all'hosting di MySQL su AWS che offre prestazioni migliori, maggiore controllo e nessun vincolo del fornitore cloud e lo stesso prezzo di Amazon RDS. In questo post, confrontiamo le prestazioni di MySQL Amazon RDS e MySQL Hosting su ScaleGrid su istanze AWS High Performance.
TLDR
La distribuzione di MySQL su AWS High Performance di ScaleGrid può fornire 2x-3x il throughput a metà della latenza di Amazon RDS per MySQL con il vantaggio aggiuntivo di avere 2 repliche di lettura rispetto a 1 in RDS.
MySQL su AWS Performance Test
| Griglia di scala | Amazon RDS | |
| Tipo di istanza | AWS High Performance XLarge (vedi i dettagli del sistema di seguito) | Istanza DB r4.xlarge (Multi-AZ) |
| Tipo di distribuzione | Set master-slave a 3 nodi con replica semisincrona | Distribuzione multi-AZ con 1 replica di lettura |
| Disco SSD | SSD locale e uso generico – 2 TB | Uso generico – 2 TB |
| Costo mensile (USD) | $ 1.798 | $ 1,789 |
| Amazon RDS Costi | Prezzo | Quantità | Totale | Note |
| Multi-AZ | ||||
| Istanza database (hr) | $ 0,48 | 730 | $ 350,40 | db.r4.xlarge |
| Istanza database (hr) | $ 0,48 | 730 | $ 350,40 | db.r4.xlarge |
| Archiviazione (GB) | $0,115 | 2000 | $ 230,00 | Uso generico:2 TB (AZ singola) |
| Leggi Replica | ||||
| Istanza database (hr) | $ 0,48 | 730 | $ 350,40 | db.r4.xlarge (Single-AZ) |
| Archiviazione (GB) | $0,115 | 2000 | $ 230,00 | Uso generico:2 TB (AZ singola) |
| Altri costi | ||||
| Archiviazione di backup (GB) | $0,095 | 1000 | $ 95,00 | Libera fino al 100% dello spazio di archiviazione DB |
| Trasferimento dati (su Internet) | $0,09 | 0 | $ 0,00 | Gratuito fino a 1 GB/mese |
| Trasferimento dati (verso le regioni) | $ 0,01 | 2000 | $ 20,00 | Stati Uniti orientali (Virginia settentrionale) |
| Supporto | $ 162,62 | 1 | $ 162,62 | 10% del costo mensile |
| Totale | $ 1.788,82 |
Come puoi vedere dalla tabella sopra, il prezzo di MySQL RDS è entro $ 10 dalla soluzione di hosting MySQL completamente gestita e all-inclusive di ScaleGrid.
Cosa sono i set di repliche ad alte prestazioni di ScaleGrid?
Il set di repliche ScaleGrid MySQL su AWS High Performance utilizza un ibrido di SSD locale e disco EBS per ottenere prestazioni elevate e affidabilità elevata. Una configurazione tipica viene distribuita utilizzando un set di repliche a 3 nodi:
- Il Master e lo Slave-1 utilizzano dischi SSD locali.
- Slave-2 utilizza un disco EBS (può essere generico o un disco IOPS con provisioning).
Cosa significa? Poiché Master e Slave-1 sono in esecuzione su SSD locale, ottieni le migliori prestazioni del disco possibili dalle tue macchine AWS. Niente più EBS basato sulla rete, solo velocissimo SSD locale. Legge e scrive sul tuo primario, e anche le letture da Slave-1 funzioneranno a velocità SSD. Slave-2 utilizza un disco dati EBS e puoi configurare la quantità di IOPS richiesta per il tuo cluster. Questa configurazione garantisce la massima sicurezza per i tuoi dati, anche in caso di smarrimento dei dischi SSD locali.
Il set di repliche MySQL AWS High Performance XLarge di ScaleGrid utilizza istanze i3.xlarge (30,5 GB RAM) con SSD locale per Master e Slave-1 e un i3.2xlarge (61 GB RAM) per Slave-2.
Configurazione MySQL
Una configurazione MySQL simile viene utilizzata su entrambe le distribuzioni ScaleGrid e RDS:
| Configurazione | Valore |
| versione | 5.7.25 community edition |
| innodb_buffer_pool_size | 25G |
| innodb_log_file_size | 1G |
| innodb_flush_log_at_trx_commit | 1 |
| sync_binlog | 1 |
| innodb_io_capacity | 3000 |
| innodb_io_capacity_max | 6000 |
| slave_parallel_workers | 30 |
| slave_parallel_type | LOGICAL_CLOCK |
Configurazione benchmark delle prestazioni MySQL
| Configurazione | Dettagli |
| Strumento | Sysbench versione 1.0.17 |
| Host | 1 r4.xlarge situato nello stesso datacenter AWS di Master MySQL |
| # Tabelle | 100 |
| # righe per tabella | 5.000.000 |
| Script per la generazione del carico di lavoro | oltp_read_write.lua |
Scenari e risultati del test delle prestazioni MySQL
Per assicurarci di fornire risultati informativi per tutti i tipi di carico di lavoro MySQL AWS, abbiamo suddiviso i nostri test in questi tre scenari in modo che tu possa valutare in base all'intensità del tuo carico di lavoro in lettura/scrittura:
- Carico di lavoro ad alta intensità di lettura: 80% legge e 20% scrive
- Carico di lavoro bilanciato: 50% legge e 50% scrive
- Carico di lavoro ad alta intensità di scrittura: 20% letture e 80% scritture
Ogni scenario viene eseguito con un numero variabile di thread client sysbench compreso tra 50 e 400 e ogni test viene eseguito per una durata di 10 minuti. Misuriamo il throughput in termini di query al secondo (QPS) e latenza del 95° percentile e ci assicuriamo che il ritardo di replicazione massimo sugli slave non superi i 30 secondi. Per alcuni dei test sull'implementazione di ScaleGrid, la configurazione di MySQL binlog_group_commit_sync_delay è ottimizzata in modo che il ritardo di replica dello slave non superi i 30 secondi. Questa tecnica viene definita "rallentare il padrone per accelerare gli schiavi" ed è spiegata nel blog di J-F Gagne.
Come migliorare le prestazioni di #MySQL AWS 2 volte rispetto ad Amazon RDS allo stesso costoFai clic per twittareScenario-1:carico di lavoro ad alta intensità di lettura con l'80% di letture e il 20% di scritture
Come possiamo vedere dai test del carico di lavoro ad alta intensità di lettura, le istanze MySQL ad alte prestazioni ScaleGrid su AWS sono in grado di gestire costantemente circa 27.800 QPS da 50 fino a 400 fili. Si tratta di un aumento di quasi il 200% rispetto alle prestazioni di MySQL RDS, che hanno una media di soli 9.411 QPS nella stessa gamma di thread.
ScaleGrid mantiene anche una latenza inferiore del 53% in media durante l'intero test delle prestazioni di MySQL AWS. Sia la latenza di Amazon RDS che quella di ScaleGrid aumentano costantemente all'aumentare del numero di thread, dove ScaleGrid raggiunge un massimo di 383 ms per 400 thread mentre Amazon RDS è a 831 ms allo stesso livello.
Scenario-2:carico di lavoro bilanciato con il 50% di letture e il 50% di scritture
Nei nostri test di prestazioni del carico di lavoro bilanciato, la distribuzione MySQL High Performance di ScaleGrid su AWS supera di nuovo le prestazioni con una media di 20.605 QPS su thread che vanno da 50 a 400. Amazon RDS solo una media di 8.296 per lo stesso numero di thread, con un miglioramento del 148% con ScaleGrid.
La latenza di ScaleGrid e Amazon RDS è diminuita significativamente nei test del carico di lavoro bilanciato rispetto ai test ad alta intensità di lettura trattati sopra. Amazon RDS ha registrato una latenza media di 258 ms nei test del carico di lavoro bilanciato, dove ScaleGrid ha raggiunto una media di soli 125 ms ottenendo una riduzione di oltre il 52% della latenza rispetto a MySQL su Amazon RDS.
Scenario-3:carico di lavoro ad alta intensità di scrittura con il 20% di letture e l'80% di scritture
Nel nostro scenario finale di carico di lavoro MySQL AWS ad alta intensità di scrittura, ScaleGrid ha ottenuto prestazioni di throughput significativamente più elevate con una media di 17.007 QPS nell'intervallo da 50 a 400 thread. Si tratta di un miglioramento del 123% rispetto ad Amazon RDS che ha raggiunto solo 7.638 QPS sullo stesso numero di thread.
I test di latenza del 95° percentile hanno anche prodotto una latenza significativamente inferiore per ScaleGrid con una media di 114 ms su 50-400 thread. Amazon RDS ha raggiunto una media di 247 ms nei test di latenza, con una riduzione media della latenza del 54% durante la distribuzione di MySQL ad alte prestazioni di ScaleGrid sui servizi AWS su Amazon RDS.
Analisi
Come abbiamo osservato dai risultati dei test, i carichi di lavoro ad alta intensità di lettura hanno comportato sia un throughput e una latenza più elevati rispetto a carichi di lavoro bilanciati e carichi di lavoro ad alta intensità di scrittura, indipendentemente da come MySQL è stato distribuito su AWS:
| Medie dei test delle prestazioni di MySQL su AWS Throughput | ScaleGrid | Amazon RDS | Miglioramento ScaleGrid |
| Produttività ad alta intensità di lettura | 27.795 | 9,411 | 195,4% |
| Bilancia il throughput del carico di lavoro | 20.605 | 8.296 | 148,4% |
| Produttività ad alta intensità di scrittura | 17.007 | 7.638 | 122,7% |
| Medie dei test delle prestazioni di latenza di MySQL su AWS | ScaleGrid | Amazon RDS | Miglioramento ScaleGrid |
| Latenza ad alta intensità di lettura | 206ms | 439ms | -53.0% |
| Latenza bilanciata del carico di lavoro | 125ms | 258ms | -51,6% |
| Latenza intensiva di scrittura | 114ms | 247ms | -53,8% |
Spiegazione dei risultati
- Vediamo che la distribuzione ScaleGrid MySQL su AWS ha fornito un throughput quasi 3 volte migliore per il carico di lavoro ad alta intensità di lettura rispetto alla distribuzione RDS.
- Con l'aumento del carico di scrittura, anche se il throughput assoluto è diminuito, ScaleGrid ha comunque fornito prestazioni di throughput quasi 2,5 volte migliori.
- Per i carichi di lavoro ad alta intensità di scrittura, abbiamo riscontrato che il ritardo di replica ha iniziato a manifestarsi per lo slave EBS nella distribuzione di ScaleGrid. Poiché il nostro obiettivo era mantenere il ritardo di replica dello slave entro 30 secondi per le nostre esecuzioni, abbiamo introdotto binlog_group_commit_sync_delay per garantire che lo slave potesse ottenere una migliore esecuzione parallela. Ciò ha controllato il ritardo e ha comportato un throughput assoluto inferiore sull'implementazione di ScaleGrid, ma abbiamo comunque potuto vedere un throughput 2,2 volte migliore rispetto all'implementazione di RDS.
- Per tutti gli scenari di carico di lavoro ad alta intensità di lettura, scrittura e bilanciamento, ScaleGrid ha offerto caratteristiche di latenza 0,5 volte inferiori rispetto a RDS.
La distribuzione ScaleGrid 'High Performance' può fornire 2x-3x il throughput a metà della latenza di RDS con l'ulteriore vantaggio di avere 2 repliche di lettura rispetto a 1 in RDS. Per ulteriori informazioni sui vantaggi dell'hosting MySQL di ScaleGrid rispetto ad Amazon RDS per MySQL, consulta la nostra pagina Confronta provider MySQL o avvia una prova gratuita di 30 giorni per esplorare la piattaforma DBaaS completamente gestita.
