AWS jest dostawcą nr 1 w chmurze w zakresie hostingu baz danych typu open source oraz w chmurze dla wdrożeń MySQL. Ponieważ organizacje kontynuują migrację do chmury, ważne jest, aby stawić czoła problemom z wydajnością, takim jak duże opóźnienia, niska przepustowość i opóźnienie replikacji przy większych odległościach między użytkownikami a infrastrukturą chmury. Podczas gdy wielu użytkowników AWS domyślnie korzysta z zarządzanego rozwiązania bazodanowego Amazon RDS, dostępne są alternatywy, które mogą poprawić wydajność MySQL w AWS dzięki zaawansowanym opcjom dostosowywania i nieograniczonej obsłudze typów instancji EC2. ScaleGrid oferuje atrakcyjną alternatywę dla hostingu MySQL na AWS, która oferuje lepszą wydajność, większą kontrolę i brak uzależnienia od dostawcy chmury oraz taką samą cenę jak Amazon RDS. W tym poście porównujemy wydajność MySQL Amazon RDS z MySQL Hosting w ScaleGrid na instancjach AWS High Performance.
TLDR
Wdrożenie MySQL firmy ScaleGrid na platformie AWS High Performance może zapewnić 2x-3x większą przepustowość przy o połowę krótszym czasie oczekiwania niż Amazon RDS dla MySQL, z dodatkową zaletą posiadania 2 replik do odczytu w porównaniu z 1 calową RDS.
MySQL na test wydajności AWS
| SkalaGrid | Amazon RDS | |
| Typ wystąpienia | AWS High Performance XLarge (zobacz szczegóły systemu poniżej) | Instancja DB r4.xlarge (Multi-AZ) |
| Typ wdrożenia | 3 Node Master-Slave Set z replikacją półsynchroniczną | Wdrożenie Multi-AZ z 1 repliką do odczytu |
| dysk SSD | Lokalny dysk SSD i ogólnego przeznaczenia – 2 TB | Ogólne zastosowanie – 2 TB |
| Miesięczny koszt (USD) | 1798 USD | 1789 USD |
| Amazon RDS Koszty | Cena | Ilość | Razem | Notatki |
| Multi-AZ | ||||
| instancja DB (godz.) | 0.48 USD | 730 | 350,40 USD | db.r4.xlarge |
| instancja DB (godz.) | 0.48 USD | 730 | 350,40 USD | db.r4.xlarge |
| Pamięć (GB) | 0.115 USD | 2000 | 230,00 USD | Ogólne zastosowanie – 2TB (Single-AZ) |
| Przeczytaj replikę | ||||
| instancja DB (godz.) | 0.48 USD | 730 | 350,40 USD | db.r4.xlarge (Single-AZ) |
| Pamięć (GB) | 0.115 USD | 2000 | 230,00 USD | Ogólne zastosowanie – 2TB (Single-AZ) |
| Inne koszty | ||||
| Backup Storage (GB) | 0,095 USD | 1000 | 95,00 $ | Zwolnij do 100% pamięci DB |
| Transfer danych (do internetu) | 0,09 USD | 0 | 0.00 USD | Bezpłatne do 1 GB/mies. |
| Transfer danych (do regionów) | 0,01 USD | 2000 | 20,00 USD | Wschód USA (N. Wirginia) |
| Wsparcie | 162,62 USD | 1 | 162,62 USD | 10% miesięcznego kosztu |
| 1.788,82 USD |
Jak widać w powyższej tabeli, ceny MySQL RDS mieszczą się w granicach 10 USD od w pełni zarządzanego i kompleksowego rozwiązania hostingowego MySQL.
Czym są zestawy replik o wysokiej wydajności firmy ScaleGrid?
Zestaw replik ScaleGrid MySQL na platformie AWS High Performance wykorzystuje hybrydę lokalnego dysku SSD i dysku EBS, aby osiągnąć zarówno wysoką wydajność, jak i wysoką niezawodność. Typowa konfiguracja jest wdrażana przy użyciu zestawu replik składającego się z trzech węzłów:
- Master i Slave-1 korzystają z lokalnych dysków SSD.
- Slave-2 używa dysku EBS (może być dyskiem ogólnego przeznaczenia lub zabezpieczonym dyskiem IOPS).
Co to oznacza? Ponieważ Master i Slave-1 działają na lokalnym dysku SSD, uzyskujesz najlepszą możliwą wydajność dysków z maszyn AWS. Koniec z sieciowym EBS, tylko niesamowicie szybki lokalny dysk SSD. Odczytuje i zapisuje do Twojego Podstawowego, a nawet odczyty z Slave-1 będą działać z prędkością SSD. Slave-2 korzysta z dysku danych EBS i można skonfigurować ilość IOPS wymaganą dla klastra. Ta konfiguracja zapewnia całkowite bezpieczeństwo danych, nawet w przypadku utraty lokalnych dysków SSD.
Zestaw replik MySQL AWS High Performance XLarge firmy ScaleGrid wykorzystuje instancje i3.xlarge (30,5 GB RAM) z lokalnym dyskiem SSD dla Master i Slave-1 oraz i3.2xlarge (61 GB RAM) dla Slave-2.
Konfiguracja MySQL
Podobna konfiguracja MySQL jest używana zarówno we wdrożeniach ScaleGrid, jak i RDS:
| Konfiguracja | Wartość |
| wersja | 5.7.25 wydanie społecznościowe |
| 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 |
Konfiguracja testu wydajności MySQL
| Konfiguracja | Szczegóły |
| Narzędzie | Sysbench wersja 1.0.17 |
| Host | 1 r4.xlarge znajduje się w tym samym centrum danych AWS co Master MySQL |
| # tabele | 100 |
| # wierszy na tabelę | 5 000 000 |
| Skrypt generujący obciążenie | oltp_read_write.lua |
Scenariusze i wyniki testów wydajności MySQL
Aby zapewnić dostarczanie informacji dla wszystkich typów obciążeń MySQL AWS, podzieliliśmy nasze testy na te trzy scenariusze, dzięki czemu możesz ocenić na podstawie intensywności obciążenia odczytu/zapisu:
- Obciążenie z intensywnym odczytem: 80% czyta i 20% pisze
- Zrównoważone obciążenie: 50% odczytów i 50% zapisów
- Obciążenie z intensywnym zapisem: 20% czyta i 80% pisze
Każdy scenariusz jest uruchamiany z różną liczbą wątków klienta sysbench w zakresie od 50 do 400, a każdy test trwa 10 minut. Mierzymy przepustowość w kategoriach zapytań na sekundę (QPS) i opóźnienia 95 percentyla i upewniamy się, że maksymalne opóźnienie replikacji na urządzeniach podrzędnych nie przekracza 30 sekund. W przypadku niektórych testów dotyczących wdrożenia ScaleGrid konfiguracja MySQL binlog_group_commit_sync_delay jest dostrojona tak, aby opóźnienie replikacji jednostki podrzędnej nie przekraczało 30 s. Ta technika jest określana jako „spowalnianie mistrza, aby przyspieszyć niewolników” i jest wyjaśniona na blogu J-F Gagne.
Jak zwiększyć wydajność #MySQL AWS dwukrotnie w porównaniu z Amazon RDS przy tym samym koszcieKliknij, aby tweetowaćScenariusz-1:intensywne obciążenie odczytu z 80% odczytów i 20% zapisów
Jak widać z testów obciążenia intensywnym odczytem, instancje MySQL ScaleGrid o wysokiej wydajności w AWS są w stanie konsekwentnie obsłużyć około 27 800 QPS w dowolnym miejscu od 50 do 400 wątków. To prawie 200% wzrost w stosunku do wydajności MySQL RDS, która wynosi średnio tylko 9411 QPS w tym samym zakresie wątków.
ScaleGrid utrzymuje również średnio o 53% niższe opóźnienia podczas całych testów wydajności MySQL AWS. Opóźnienia zarówno Amazon RDS, jak i ScaleGrid stale rosną wraz ze wzrostem liczby wątków, przy czym ScaleGrid osiąga maksymalny poziom 383 ms dla 400 wątków, podczas gdy Amazon RDS ma 831 ms na tym samym poziomie.
Scenariusz-2:Zrównoważone obciążenie pracą z 50% odczytami i 50% zapisami
W naszych testach wydajności zrównoważonego obciążenia, wdrożenie MySQL High Performance firmy ScaleGrid na AWS ponownie osiąga lepsze wyniki ze średnią 20 605 QPS w wątkach od 50 do 400. Amazon RDS średnio tylko 8296 dla tej samej liczby wątków, co daje 148% poprawę dzięki ScaleGrid.
Opóźnienia ScaleGrid i Amazon RDS znacznie spadły w testach zrównoważonego obciążenia w porównaniu z opisanymi powyżej testami intensywnego odczytu. Amazon RDS osiągnął średnie opóźnienie 258 ms w testach zrównoważonego obciążenia, gdzie ScaleGrid osiągnął średnio tylko 125 ms, osiągając ponad 52% redukcję opóźnień w porównaniu z MySQL na Amazon RDS.
Scenariusz-3:intensywne obciążenie zapisu z 20% odczytami i 80% zapisami
W naszym ostatecznym scenariuszu obciążenia MySQL AWS intensywnie korzystającym z zapisu, ScaleGrid osiągnął znacznie wyższą przepustowość ze średnią 17 007 QPS w zakresie od 50 do 400 wątków. Jest to poprawa o 123% w porównaniu z Amazon RDS, który osiągnął tylko 7638 QPS przy tej samej liczbie wątków.
Testy opóźnień 95. percentyla również wygenerowały znacznie niższe opóźnienia dla ScaleGrid, średnio 114 ms w ciągu 50 do 400 wątków. Amazon RDS osiągnął średnio 247 ms w swoich testach opóźnień, co skutkowało redukcją średnio o 54% opóźnień podczas wdrażania High Performance MySQL ScaleGrid w usługach AWS przez Amazon RDS.
Analiza
Jak zauważyliśmy na podstawie wyników testów, obciążenia o dużej intensywności odczytu skutkowały zarówno wyższą przepustowością, jak i opóźnieniami w przypadku zrównoważonych obciążeń i intensywnych zadań zapisu, niezależnie od tego, w jaki sposób MySQL został wdrożony na AWS:
| MySQL na średnich testach przepustowości AWS | ScaleGrid | Amazon RDS | Ulepszenie ScaleGrid |
| Przepustowość intensywnego odczytu | 27 795 | 9411 | 195,4% |
| Zrównoważ przepustowość obciążenia | 20 605 | 8296 | 148,4% |
| Przepustowość intensywnego zapisu | 17 007 | 7638 | 122.7% |
| MySQL na średnich testach opóźnienia AWS | ScaleGrid | Amazon RDS | Ulepszenie ScaleGrid |
| Opóźnienie intensywnego odczytu | 206ms | 439ms | -53,0% |
| Zrównoważone opóźnienie obciążenia | 125ms | 258ms | -51,6% |
| Intensywne opóźnienie zapisu | 114ms | 247ms | -53,8% |
Wyjaśnienie wyników
- Widzimy, że wdrożenie ScaleGrid MySQL we wdrożeniu AWS zapewniło prawie 3x lepszą przepustowość dla obciążenia intensywnie czytającego w porównaniu z wdrożeniem RDS.
- W miarę wzrostu obciążenia zapisu, chociaż bezwzględna przepustowość spadła, ScaleGrid nadal zapewniał blisko 2,5x lepszą przepustowość.
- W przypadku obciążeń intensywnie korzystających z zapisu okazało się, że opóźnienie replikacji zaczęło się pojawiać dla urządzenia podrzędnego EBS we wdrożeniu ScaleGrid. Ponieważ naszym celem było utrzymanie opóźnienia replikacji modułu podrzędnego w ciągu 30 sekund podczas naszych uruchomień, wprowadziliśmy binlog_group_commit_sync_delay, aby zapewnić lepsze wykonywanie równoległego modułu podrzędnego. To kontrolowało opóźnienie i skutkowało mniejszą bezwzględną przepustowością we wdrożeniu ScaleGrid, ale nadal mogliśmy zobaczyć 2,2 razy lepszą przepustowość w porównaniu z wdrożeniem RDS.
- We wszystkich scenariuszach z intensywnym odczytem, zapisem i zrównoważonym obciążeniem, ScaleGrid oferował charakterystykę opóźnień 0,5x niższą w porównaniu z RDS.
Wdrożenie „High Performance” ScaleGrid może zapewnić 2x-3x większą przepustowość przy o połowę mniejszym opóźnieniu RDS z dodatkową zaletą posiadania 2 replik do odczytu w porównaniu z 1 w RDS. Aby dowiedzieć się więcej o zaletach hostingu MySQL firmy ScaleGrid w porównaniu z Amazon RDS dla MySQL, sprawdź naszą stronę Porównaj dostawców MySQL lub rozpocznij bezpłatny 30-dniowy okres próbny, aby poznać w pełni zarządzaną platformę DBaaS.
