Planowanie pojemności baz danych

Uwaga: ten post jest inspirowany niedawnym postem Julii Evans o planowaniu wydajności.

RDBMS

Najpierw ustalmy kilka podstawowych zasad. Tak… ten post jest przeznaczony dla tych z nas, którzy używają MySQL z jednym programem piszącym na raz i 2 lub więcej replikami do odczytu. Wiele z tego, o czym tutaj opowiem, dotyczy inaczej lub wcale w klastrach magazynów danych z wieloma zapisami, chociaż te również mają swój własny zestaw kompromisów i zastrzeżeń. Więc… Twój przebieg na pewno będzie się różnić.

Jednak ten wpis na blogu BĘDZIE obowiązywał niezależnie od tego, czy korzystasz z samoobsługowych hostów fizycznych, czy znajdujesz się w AWS, gdzie możesz korzystać z magicznych instancji zarezerwowanych i zapewniać niemal natychmiastową obsługę administracyjną. Przebywanie w „chmurze” nie pozbawi Cię możliwości i ograniczeń Twojej infrastruktury i nie zwolni Cię z tej odpowiedzialności wobec Twojego zespołu i klientów.

Fragmentacja

Omówiłem już duże pociągnięcia tego w jednym z moich wcześniejszych postów, głównie skupiłem się tam na korzyściach z funkcjonalnego lub poziomego shardingu. Tak, jest to absolutny warunek wstępny, ponieważ to, czego użyjesz, aby uzyskać dostęp do warstwy bazy danych, zdecyduje, jak dużą elastyczność musisz skalować.

Jeśli jesteś zupełnie nową firmą, możesz nie potrzebować funkcjonalnego shardingu pierwszego dnia, ale jeśli masz nadzieję (i podejrzewam, że tak) się rozwiniesz, nie zamykaj się w otwartym ORM-ie, który nie pozwoli ci na podział Twoje dane w sposób funkcjonalny w dół. Dodatkowe punkty, jeśli nie uruchomisz swojej firmy ze wszystkimi danymi relacyjnymi w jednym schemacie.

Możliwość dzielenia odczytów i zapisów

Jest to coś, co musisz umieć zrobić, ale niekoniecznie egzekwować jako ustaloną zasadę. Będą przypadki użycia, w których zapis będzie musiał zostać odczytany bardzo szybko i gdzie tolerancja na takie rzeczy, jak opóźnienia/konsystencja ostateczna jest niska. Można je mieć, ale w tych samych aplikacjach będziesz mieć również scenariusze odczytów, które mogą tolerować dłuższy okres ostatecznej spójności. Kiedy takie odczyty są w dużych ilościach, czy naprawdę chcesz, aby ten tom trafił do twojego jedynego autora, jeśli tak naprawdę nie musi? Zrób sobie przysługę i upewnij się, że już wkrótce w dniach rozwoju możesz kontrolować użycie adresu IP do odczytu lub zapisu w swoim kodzie.

Przejdźmy teraz do procesu myślowego planowania rzeczywistej wydajności… Klaster bazy danych nie nadąża, co mam zrobić?

Określ wąskie gardło systemu

• Czy masz wąskie gardło, jeśli chodzi o pisanie lub czytanie?
• Czy problem jest tak wysoki, jak procesor?
• Czy występuje jako pojemność IO?
• Czy to rosnące opóźnienie w replikach bez wyraźnego winowajcy zapytania odczytu?
• Czy to blokuje?
• Skąd mam wiedzieć, który to jest?

Każdy z nich może być sam w sobie postem. Chodzi mi o to, że musisz znać swój system i specyficzne metryki DB, aby móc dowiedzieć się, który element jest wąskim gardłem.

Potrzebujesz linii bazowej

Zawsze upewnij się, że masz dostępne podstawowe metryki systemowe do wizualizacji przez co najmniej kilka tygodni wstecz. Wiele narzędzi to zapewnia (Cacti, Munin, Graphite…itd.). Gdy już wiesz, do jakiej metryki systemowej jesteś najbardziej przywiązany, musisz ustalić wartości bazowe i szczytowe. W przeciwnym razie ustalenie, czy Twój obecny problem jest błędem związanym z nową aplikacją, czy rzeczywistym wzrostem, będzie o wiele bardziej podatne na błędy, niż byś chciał.

Jednak podstawowe metryki serwera mogą zajść tylko tak daleko - w pewnym momencie okaże się, że potrzebujesz również metryk kontekstowych. Wydajność zapytań i postrzegana wydajność po stronie aplikacji pokażą Ci, jaki czas reakcji na zapytania postrzega aplikacja. Istnieje wiele narzędzi umożliwiających śledzenie ciężkiego kontekstu. Niektóre z nich to open source, takie jak Anemometer i narzędzia komercyjne, takie jak Vivid Cortex (używamy ich w SendGrid. Zobacz, jak rozmawiamy o tym tutaj). Ale na samym początku musisz przyzwyczaić się do tego, że to, co postrzega Twoja aplikacja, jest tym, co postrzegają Twoi klienci. I najpierw musisz znaleźć sposób, żeby się dowiedzieć.

Poznaj wzorce ruchu w swojej firmie

Czy jesteś firmą podatną na ekstremalne szczyty w określone dni tygodnia (np. marketing)? Czy masz regularne uruchomienia, które trzykrotnie lub czterokrotnie zwiększają ruch, jak w przypadku gier? Tego rodzaju pytania będą decydować o tym, jak dużą rezerwę należy zachować lub czy trzeba inwestować w elastyczny wzrost.

Określ stosunek surowych numerów ruchu w stosunku do wykorzystywanej przepustowości

Jest to po prostu odpowiedź na pytanie: „Jeśli nie dokonaliśmy optymalizacji kodu, ile e-maili/sprzedaży/użytkowników online/cokolwiek” możemy obsłużyć z instancjami baz danych, które mamy w tej chwili?

Idealnie, jest to konkretna wartość, która sprawia, że ​​matematyka w kierunku planowania rocznego wzrostu jest prostym równaniem matematycznym. Ale życie nigdy nie jest idealne, a wartość ta będzie się różnić w zależności od pory roku lub całkowicie zewnętrznych szczęśliwych czynników, takich jak rejestracja nowego głównego klienta. We wczesnych startupach liczba ta jest szybszym celem, ale powinna się ustabilizować, gdy firma przechodzi od wczesnych dni do bardziej ugruntowanej działalności z bardziej przewidywalnymi wzorcami wzrostu.

Czy naprawdę muszę kupić więcej maszyn?

Musisz znaleźć sposób, aby określić, czy jest to naprawdę pojemność — muszę podzielić zapisy, aby obsłużyć bardziej współbieżne obciążenie zapisu lub dodać więcej replik do odczytu — w porównaniu. wąskie gardło wydajności oparte na kodzie (to nowe zapytanie z niedawnego wdrożenia może naprawdę mieć swoje wyniki w pamięci podręcznej w czymś tańszym i nie przebijać tak bardzo bazy danych).

Jak to robisz? Musisz zapoznać się ze swoimi zapytaniami. Małym krokiem do tego jest połączenie innotop, slow log i pt-query-digest z Percona Toolkit. Można to zautomatyzować, wysyłając dzienniki bazy danych do centralnej lokalizacji i automatyzując część skrótu.

Ale to też nie jest cały obraz, powolne logi wymagają dużej wydajności, jeśli zbytnio obniżysz ich próg. Jeśli możesz żyć z mniej selektywnym próbkowaniem, będziesz musiał wykryć wszystkie konwersacje między aplikacją a magazynem danych. W środowisku open source można korzystać z tak prostych rozwiązań, jak tcpdump lub korzystać z hostowanych produktów, takich jak Datadog, New Relic lub VividCortex.

Zadzwoń

Planowanie wydajności może w 90% obejmować naukę i 10% sztukę, ale to 10% nie powinno oznaczać, że nie powinniśmy dążyć do jak największej części obrazu. Jako inżynierowie możemy czasami skupiać się na brakujących 10% i nie zdawać sobie sprawy, że jeśli wykonaliśmy pracę, to 90% może dać nam lepsze wyobrażenie o stanie naszego stacka, bardziej efektywnym wykorzystaniu naszego czasu, optymalizacji wydajności i zdolności planowania zwiększa się ostrożnie, co ostatecznie skutkuje znacznie lepszym zwrotem z inwestycji w nasze produkty.