Pogłębiony poradnik
Symulator skalowania bazy danych i IOPS: gdy koszt zarządzanej bazy wyprzedza przychód na użytkownika
Analiza branży dla zarządu
Zarządzana baza danych to ta część stosu, o której ludzie najbardziej chcą zapomnieć, i która odwzajemnia się, gdy przychodzi faktura. Zaczyna się od małej instancji i małego dysku. Potem użytkownicy rosną, funkcje dodają zapytania, tabele wypełniają się historią, a plan, który był tani, staje się największą pozycją na rachunku. W przeciwieństwie do serwerów WWW bazy danych nie skalują się przez dodawanie tanich, identycznych maszyn. Skalują się przez przejście na większe instancje, dodanie zarezerwowanej przepustowości i kopiowanie wszystkiego do replik, a każdy z tych kroków mnoży koszt.
Istotą problemu jest to, że koszt rośnie skokowo, a przychód płynnie. Rozmiary instancji się podwajają: z dwóch do czterech, ośmiu i szesnastu vCPU, a cena mniej więcej podwaja się za każdym razem. Przechowywanie i IOPS są rozliczane osobno, a repliki mnożą je wszystkie. Przychód na użytkownika nie podwaja się, gdy podwaja się Twoja instancja. Biznes, który jest komfortowo rentowny przy 30 000 użytkowników, może odkryć, że następny rozmiar zjada zysk z kolejnych 10 000 użytkowników.
Model domina śledzi łańcuch. Użytkownicy i IOPS na tysiąc użytkowników ustalają szczytowe zapotrzebowanie na warstwę przechowywania. Wymagania obliczeniowe decydują o rozmiarze instancji, który wraz z replikami, przechowywaniem i zarezerwowaną przepustowością ustala rachunek. Rachunek staje się udziałem w przychodzie, który ostatecznie rozstrzyga o zysku. Źle zindeksowane zapytanie może zmienić pierwsze pole trzykrotnie bez żadnej zmiany liczby użytkowników, dlatego strojenie zapytań jest często najtańszym sposobem obniżenia wszystkich kolejnych pól.
Góra lodowa oddziela instancję, którą widzą wszyscy, od dodatków, które sprawiają, że rachunek jest większy od oczekiwanego. Widoczne są instancja główna i przechowywanie. Pod linią wody znajdują się repliki, które powtarzają moc obliczeniową i przechowywanie, zarezerwowane IOPS ponad poziom bazowy zawarty w dysku, kopie zapasowe przechowywane tygodniami oraz ruch replikujący dane między strefami. Każda z tych pozycji jest rozliczana pod innym nagłówkiem, więc łatwo je niedoszacować w planowaniu. Użyj symulatora, aby przetestować, jak Twoja architektura zachowuje się wraz ze wzrostem liczby użytkowników i gdzie baza danych przestaje być osiągalna cenowo.
Wzory i założenia metodyczne
Model opisuje pojedynczy miesiąc. Szczytowe zapotrzebowanie na IOPS to użytkownicy na tysiąc razy IOPS na tysiąc razy współczynnik szczytu równy 2,5. Wymagana moc obliczeniowa to 0,0005 vCPU na użytkownika, zaokrąglona w górę do rozmiaru instancji będącego potęgą dwójki, z minimum dwóch. Każda replika powtarza instancję główną, przechowywanie i zarezerwowane IOPS. Zarezerwowane IOPS są rozliczane powyżej poziomu bazowego 3000. Przechowywanie, kopie zapasowe i replikacja między strefami dodają się do sumy, a pozostałe koszty to 40% przychodu.
- Szczytowe IOPS
- I = użytkownicy ÷ 1000 × IOPS na 1000 × 2,5
- Operacje na sekundę, które warstwa przechowywania musi wytrzymać w szczycie.
- Rozmiar instancji
- V = 2^ceil(log₂(max(2, użytkownicy × 0,0005)))
- vCPU na instancji głównej, które występują w rozmiarach będących potęgami dwójki.
- Rachunek za bazę danych
- D = (1 + repliki) × (V × cena + koszt IOPS + przechowywanie) + kopie zapasowe + między strefami
- Moc obliczeniowa, przepustowość i przechowywanie powtórzone na każdym węźle, plus kopie zapasowe i replikacja.
- Zarezerwowane IOPS
- max(0, I − 3000) × $0,10 na węzeł
- Przepustowość ponad to, co zawiera dysk, rozliczana na każdym węźle.
- Zysk netto
- Wynik = przychód × (1 − 40%) − D
- Wynik miesięczny. Punkt krytyczny to miejsce, w którym spada do zera.
Kaskadowa elastyczność
Repliki i IOPS na użytkownika to najbardziej elastyczne dane wejściowe, ponieważ każde z nich mnoży się na każdym węźle. Przychód na użytkownika skaluje całą marżę. Użytkownicy zmieniają wynik zarówno przez przychód, jak i przez przejście na większą instancję, więc wzrost nie jest darmową wygraną.
Trzy rzeczywiste studia przypadku
Start na własnych środkach
Mały produkt na minimalnej bazie danych
Młody produkt ma trzy tysiące użytkowników, jedną replikę i lekkie dane na użytkownika. Przychód na użytkownika jest wysoki, a instancja ma minimalny rozmiar. Załaduj ten przykład, aby zobaczyć, że baza danych jest na początku pomijalna i jak wysoki przychód na użytkownika daje miejsce na wzrost.
Skalowanie w średniej firmie
Duża baza użytkowników z wydajnymi zapytaniami
Produkt z trzystoma tysiącami użytkowników utrzymuje niskie IOPS na użytkownika dzięki indeksowaniu i buforowaniu oraz używa dwóch replik. Rachunek jest duży w liczbach bezwzględnych, ale stanowi skromny udział przychodu. Załaduj ten przykład, aby zobaczyć skalę działającą na korzyść, gdy zapytania są dostrojone.
Kryzys typu czarny łabędź
Ciężkie zapytania i zbyt wiele replik
Produkt z dużą bazą użytkowników i niskim przychodem na użytkownika uruchamia niezindeksowane zapytania, pięć replik i dużo przechowywanych danych na użytkownika. Zarezerwowane IOPS i repliki mnożą każdy koszt. Załaduj ten przykład, aby zobaczyć rachunek za bazę przewyższający przychód i która dźwignia przywraca miesiąc.
Macierz wskaźników branżowych
| Wskaźnik | Strefa zagrożenia | Średnia branżowa | Czołowe 10% najlepszych |
|---|---|---|---|
| Koszt bazy danych jako udział przychodu | Powyżej 35% | 8–15% | Poniżej 6% |
| Koszt bazy danych na aktywnego użytkownika miesięcznie | Powyżej $0,25 | $0,05–0,12 | Poniżej $0,04 |
| Repliki dla typowego SaaS | Więcej niż 3 bez wyraźnej potrzeby odczytów | 1–2 | 1 rezerwowa plus ukierunkowane repliki odczytu |
| Udział zarezerwowanych IOPS faktycznie wykorzystywany w szczycie | Poniżej 30% | 50–70% | 70–85% |
| Retencja kopii zapasowych | Miesiące pełnych migawek | 7–14 dni | Retencja warstwowa z archiwum |
Zmienne i dźwignie
Aktywni użytkownicy
Użytkownicy generujący obciążenie bazy danych w typowym miesiącu.
Dźwignia: Nie zakładaj, że więcej użytkowników zawsze oznacza lepszą marżę; sprawdź, czy przychód na użytkownika nadal pokrywa następny rozmiar instancji.
Przychód na użytkownika miesięcznie
Średni miesięczny przychód z jednego aktywnego użytkownika.
Dźwignia: Podnieś przychód na użytkownika przez progi cenowe, ponieważ koszt bazy danych na użytkownika rośnie wraz z użyciem i przechowywaniem.
IOPS istotne w szczycie na 1000 użytkowników
Średnia liczba operacji odczytu i zapisu na sekundę generowanych przez każdy tysiąc użytkowników. Najbardziej wpływają na nią projekt zapytań i indeksowanie.
Dźwignia: Dodaj brakujące indeksy, buforuj gorące odczyty i grupuj zapisy; zmniejszenie IOPS często pozwala uniknąć zarówno większych dysków, jak i większych instancji.
Cena vCPU miesięcznie
Ile Twoja zarządzana baza danych pobiera miesięcznie za vCPU dla klasy instancji, której używasz.
Dźwignia: Porównaj rodziny instancji i zobowiąż się do zarezerwowanej mocy, gdy Twoje obciążenie stanie się przewidywalne.
Repliki odczytu i instancje rezerwowe
Dodatkowe kopie bazy danych do odczytów lub przełączania awaryjnego. Każda powtarza koszt mocy obliczeniowej, przechowywania i IOPS.
Dźwignia: Kwestionuj każdą replikę: zachowaj jedną rezerwową do przełączania awaryjnego, a repliki odczytu dodawaj tylko wtedy, gdy odczyty naprawdę ich potrzebują.
Dane przechowywane na użytkownika (GB)
Średnia liczba gigabajtów przestrzeni bazy danych dodawanej przez każdego użytkownika, w tym indeksy.
Dźwignia: Archiwizuj stare wiersze do tańszego magazynu, ustaw limity retencji i kompresuj duże kolumny.
Jak korzystać z tego symulatora
- 1Zacznij od realistycznego ustawienia wstępnego lub wpisz użytkowników, przychód na użytkownika i szczegóły obecnej instancji.
- 2Przeczytaj pięć pól efektu domina, aby zobaczyć, czy zapotrzebowanie na IOPS czy rozmiar instancji zaczerwieni się pierwszy.
- 3Naciśnij „Znajdź mój punkt krytyczny”, aby zobaczyć obciążenie lub liczbę replik, która zeruje zysk.
- 4Porównaj obecną konfigurację z planem strojenia na wykresie 24-miesięcznym.
- 5Co kwartał przeglądaj wolne zapytania i nieużywane repliki, zanim nastąpi kolejny skok instancji.
Błędy, których należy unikać
- Zakładanie, że koszt bazy danych rośnie proporcjonalnie do liczby użytkowników, gdy rośnie skokowo i mnoży się wraz z replikami.
- Rezerwowanie IOPS znacznie powyżej tego, co wykorzystuje obciążenie, bo ustawienie skopiowano z większego systemu.
- Utrzymywanie replik odczytu, z których nie korzysta żadne zapytanie, i płacenie za moc obliczeniową i przechowywanie dwa lub trzy razy.
- Skalowanie instancji w górę, zanim przyjrzysz się wolnym zapytaniom i brakującym indeksom, które stworzyły to obciążenie.
Najczęściej zadawane pytania
Czym są IOPS i dlaczego są rozliczane?
IOPS oznacza operacje wejścia i wyjścia na sekundę: ile odczytów i zapisów wykonuje warstwa przechowywania. Niektóre poziomy przechowywania zawierają poziom bazowy i rozliczają zarezerwowaną przepustowość ponad nim. Sprawdź aktualne zasady swojego dostawcy.
Kiedy dodać replikę odczytu?
Gdy odczyty wyraźnie dominują, a instancja główna jest wąskim gardłem, albo gdy potrzebujesz mniejszych opóźnień geograficznych lub przełączania awaryjnego. Dodawanie replik z przyzwyczajenia mnoży cały rachunek.
Dlaczego koszt skacze przy określonych liczbach użytkowników?
Instancje występują w stałych rozmiarach, więc przekroczenie progu przenosi Cię do następnego rozmiaru o mniej więcej dwukrotnie wyższej cenie. Model używa rozmiarów będących potęgami dwójki, aby pokazać te skoki.
Czy większa instancja jest lepsza niż więcej replik?
Dla zapisów zwykle odpowiedzią jest większa instancja główna. Dla odczytów pomagają repliki lub buforowanie. Właściwa mieszanka zależy od obciążenia, więc mierz przed skalowaniem.
Jak znaleźć liczbę użytkowników, przy której baza danych staje się zbyt droga?
Naciśnij „Znajdź mój punkt krytyczny”. Narzędzie przesuwa każdą daną wejściową w stronę gorszego końca i podaje wartość, przy której miesięczny zysk spada do zera.
Jak dokładne jest to narzędzie?
To edukacyjny model z przykładowymi cenami, a nie oferta ani porada inżynieryjna. Zastąp stałe aktualnymi cenami swojego dostawcy i zmierzonym obciążeniem.
To edukacyjny model planistyczny oparty na jawnie podanych założeniach. Nie stanowi porady finansowej, podatkowej ani prawnej. Należy zastąpić dane wejściowe własnymi liczbami, a ważne decyzje skonsultować z wykwalifikowanym specjalistą.