Piszę biznesplan i muszę zasymulować koszt, kiedy moja witryna będzie dostępna dla 500 000 unikalnych użytkowników.
- odwiedzający: 500 000
- liczba odsłon strony: 1 500 000
- liczba odsłon strony pająka: 500 000
- łączna liczba wyświetleń strony: 2 000 000
Każda strona wykonuje 50 zapytań + -
- zapytania dziennie: 100 milionów
- na godzinę: 4 miliony
- na minutę: 70 000
- na sekundę: 1200
- szczyt: 3000
Do tego obliczenia potrzebuję 3000 zapytań sekund ... jaki serwer może to obsłużyć?
Problem polega na tym, że moja strona robi 2000 wizyt dziennie i - + 150/200 zapytań na sekundę ... od tego momentu oczekuję 50 000 zapytań na sekundę.
Ile serwerów potrzebnych w klastrze lub replikacji zarządza tym zadaniem?
Odpowiedzi:
Pracowałem kiedyś dla firmy zajmującej się handlem elektronicznym, której strona internetowa miała kilka milionów odsłon dziennie. Mieliśmy jeden DELL PE 1750 z 2 jednordzeniowymi procesorami i 2 GB pamięci RAM, wielkość bazy danych ok. 4 GB. W godzinach szczytu serwer ten obsługiwał do 50 000 zapytań na sekundę.
Powiedziawszy to: baza danych była dobrze skonstruowana, wszystkie zapytania zostały precyzyjnie dostrojone (mieliśmy cotygodniowe sesje analizujące dzienniki wolnych zapytań oraz naprawiające zapytania i indeksy), a także konfiguracja serwera. Buforowanie jest zdecydowanie dobrym pomysłem, ale MySQL tak robi, po prostu musisz przeanalizować wydajność, a następnie dostroić sposób użycia pamięci (pamięć podręczna zapytań w porównaniu z innymi opcjami).
Z tego doświadczenia mogę powiedzieć, że największy wpływ mają brakujące indeksy, złe indeksy i zły projekt bazy danych (np. Długie pola łańcuchowe jako klucze podstawowe i podobne bzdury).
źródło
Wszystko zależy od złożoności zapytania, ilości pamięci serwerów i szybkości dysków.
Jeśli zapytania są bardzo proste lub bardzo dobrze dostrojone, wystarczy jeden duży serwer bazy danych. Jeśli jednak zapytania są bardzo złożone (lub proste, ale źle dostrojone), będziesz potrzebować kilku serwerów.
źródło
Tak naprawdę nie można tego oszacować, nie wiedząc nic na temat konkretnych zapytań, schematu bazy danych i jego wielkości.
Prosty WYBÓR w kolumnie indeksowanej jest zupełnie inną bestią niż kilka JOIN opartych na nieindeksowanych ... i oczywiście wiele się zmieni, jeśli zaangażowane tabele zawierają rekordy 1K lub 1M.
Również:
źródło
Jak zauważył Ignacio, możesz zajrzeć do buforowania. W cms, a może nawet przed stosem. Ponad 50 zapytań dla każdej (każdej!) Strony to naprawdę dużo.
źródło
Sądząc po twoich komentarzach, największym czynnikiem będzie rozmiar twojego zestawu danych lub przynajmniej rozmiar „gorącego” zestawu danych. 3,000qps, a nawet 8000qps na 16-rdzeniowym serwerze nie stanowi żadnego problemu, o ile serwer rzadko musi iść na dysk w celu spełnienia zapytania. Gdy aktywny zestaw danych przekroczy ilość pamięci używanej przez InnoDB do buforowania, wydajność spadnie gwałtownie.
źródło
W przypadku dużych „gorących” zestawów danych prawdopodobnie warto zainwestować na czas, aby przejść na schemat „dużych zbiorów danych”, właśnie po to są. Na przykład, jeśli masz do pobrania ogromną ilość danych, ale nigdy nie przepisujesz, a jedynie dodajesz nowe dane, spójrz na Apache Hive. Rozejrzyj się, zwykle jest to smak, który można wystarczająco łatwo połączyć z istniejącym kodem, co również zapobiegnie zgadze związanej z brakiem pamięci podręcznej.
źródło
Jest zbyt wiele rzeczy, które mogą wpływać na twoje zapytania na sekundę, proszę nie ufaj moim danym bez testowania siebie. Publikuję tutaj mój wynik testu prędkości, aby pomóc komuś oszacować qps przy użyciu bieżącej bazy danych i maszyny mysql (2018-09). W moim teście rozmiar danych jest mniejszy niż pamięć serwera (co znacznie zmniejsza IO i znacznie poprawia wydajność).
Korzystam z jednego procesora 3,75 GB pamięci, 100 GB SSD, instancji serwera mysql w chmurze gcp i otrzymuję:
źródło