W którym momencie baza danych MySQL zaczyna tracić wydajność?
Mam coś, co uważam za dużą bazę danych, z około 15 milionami rekordów, które zajmują prawie 2 GB. Czy w oparciu o te liczby istnieje jakaś zachęta do wyczyszczenia danych, czy też mogę bezpiecznie kontynuować skalowanie jeszcze przez kilka lat?
Odpowiedzi:
Rozmiar fizycznej bazy danych nie ma znaczenia. Liczba rekordów nie ma znaczenia.
Z mojego doświadczenia wynika, że największym problemem, na który się natkniesz, jest nie rozmiar, ale liczba zapytań, które możesz obsłużyć jednocześnie. Najprawdopodobniej będziesz musiał przejść do konfiguracji master / slave, aby zapytania odczytu mogły działać z urządzeniami slave, a zapytania zapisu - z urządzeniem master. Jeśli jednak nie jesteś jeszcze na to gotowy, zawsze możesz dostosować swoje indeksy do uruchomionych zapytań, aby przyspieszyć czas odpowiedzi. Jest także wiele ulepszeń, które możesz zrobić dla stosu sieciowego i jądra w Linuksie, które pomogą.
Miałem moje dostać do 10 GB, z tylko umiarkowaną liczbą połączeń i to dobrze spełniło żądania.
Najpierw skupię się na twoich indeksach, a następnie poproszę administratora serwera o sprawdzenie twojego systemu operacyjnego, a jeśli to wszystko nie pomoże, może to być czas na wdrożenie konfiguracji master / slave.
Zasadniczo jest to bardzo subtelna kwestia i wcale nie trywialna. Zachęcam do przeczytania mysqlperformanceblog.com i High Performance MySQL . Naprawdę uważam, że nie ma na to ogólnej odpowiedzi.
Pracuję nad projektem, który ma bazę danych MySQL z prawie 1 TB danych. Najważniejszym czynnikiem skalowalności jest pamięć RAM. Jeśli indeksy tabel mieszczą się w pamięci, a zapytania są wysoce zoptymalizowane, można obsłużyć rozsądną liczbę żądań na przeciętnej maszynie.
Liczba rekordów ma znaczenie, w zależności od wyglądu tabel. Różnica polega na tym, że ma się wiele pól varchar lub tylko kilka liczb całkowitych lub długich.
Ważny jest również rozmiar fizyczny bazy danych: na przykład pomyśl o tworzeniu kopii zapasowych. W zależności od silnika fizyczne pliki db będą się powiększać, ale nie kurczą się, na przykład za pomocą innodb. Usunięcie wielu wierszy nie pomaga zmniejszyć plików fizycznych.
Jest wiele takich problemów i jak w wielu przypadkach diabeł tkwi w szczegółach.
Rozmiar bazy danych ma znaczenie . Jeśli masz więcej niż jedną tabelę z ponad milionem rekordów, wtedy wydajność zaczyna się naprawdę obniżać. Liczba rekordów ma oczywiście wpływ na wydajność: MySQL może być powolny z dużymi tabelami . Jeśli trafisz milion rekordów, wystąpią problemy z wydajnością, jeśli wskaźniki nie zostaną ustawione poprawnie (na przykład brak wskaźników dla pól w „instrukcjach WHERE” lub „warunkach ON” w złączeniach). Jeśli osiągniesz 10 milionów rekordów, zaczniesz mieć problemy z wydajnością, nawet jeśli masz prawidłowe wszystkie swoje indeksy. Aktualizacje sprzętu - dodając więcej pamięci i więcej mocy procesora, zwłaszcza pamięci - często pomagają zmniejszyć najpoważniejsze problemy poprzez ponowne zwiększenie wydajności, przynajmniej do pewnego stopnia. Na przykład37 sygnałów przeszło z 32 GB pamięci RAM na 128 GB pamięci RAM dla serwera bazy danych Basecamp.
Skoncentrowałbym się najpierw na twoich indeksach, niż gdyby administrator serwera spojrzał na twój system operacyjny, a jeśli to wszystko nie pomoże, może to być czas na konfigurację master / slave.
To prawda. Inną rzeczą, która zwykle działa, jest po prostu zmniejszenie ilości danych, z którymi wielokrotnie pracował. Jeśli masz „stare dane” i „nowe dane”, a 99% zapytań działa z nowymi danymi, po prostu przenieś wszystkie stare dane do innej tabeli - i nie patrz na nią;)
-> Zobacz partycjonowanie .
Nie ma sensu mówić o „wydajności bazy danych”, „wydajność zapytań” jest tutaj lepszym określeniem. Odpowiedź brzmi: zależy od zapytania, danych, na których operuje, indeksów, sprzętu itp. Możesz dowiedzieć się, ile wierszy będzie skanowanych i jakie indeksy będą używane ze składnią EXPLAIN.
2 GB tak naprawdę nie liczy się jako „duża” baza danych - jest raczej średniej wielkości.
Obecnie zarządzam bazą danych MySQL w chmurze Amazon, która wzrosła do 160 GB. Wydajność zapytania jest w porządku. Koszmarem stały się kopie zapasowe, przywracanie, dodawanie niewolników lub cokolwiek innego, co dotyczy całego zestawu danych, a nawet DDL na dużych tabelach. Uzyskiwanie czystego importu pliku zrzutu stało się problematyczne. Aby proces był wystarczająco stabilny, aby zautomatyzować, konieczne było dokonanie różnych wyborów w celu ustalenia priorytetu stabilności nad wydajnością. Gdybyśmy kiedykolwiek musieli wyjść z katastrofy za pomocą kopii zapasowej SQL, nie działalibyśmy przez kilka dni.
Skalowanie w poziomie SQL również jest dość bolesne iw większości przypadków prowadzi do korzystania z niego w sposób, w jaki prawdopodobnie nie zamierzałeś, gdy wybierasz umieszczanie swoich danych w SQL. Odłamki, read slave, multi-master, i inni, są to naprawdę gówniane rozwiązania, które zwiększają złożoność wszystkiego, co kiedykolwiek robisz z DB, i żadne z nich nie rozwiązuje problemu; ogranicza to tylko w pewien sposób. Zdecydowanie zasugerowałbym przeniesienie niektórych danych z MySQL (lub naprawdę dowolnego SQL), gdy zaczniesz zbliżać się do zestawu danych o rozmiarze, w którym tego rodzaju rzeczy stają się problemem.
Uważaj również na złożone połączenia. Złożoność transakcji może być ważnym czynnikiem oprócz wielkości transakcji.
Refaktoryzacja ciężkich zapytań czasami zapewnia duży wzrost wydajności.
Kiedyś wezwano mnie do spojrzenia na mysql, który „przestał działać”. Odkryłem, że pliki DB znajdują się w filtrze urządzenia sieciowego podłączonego do NFS2 i o maksymalnym rozmiarze 2 GB. I rzeczywiście, tabela, która przestała akceptować transakcje, miała dokładnie 2 GB na dysku. Ale jeśli chodzi o krzywą wydajności, powiedziano mi, że działał jak mistrz aż do momentu, gdy w ogóle nie działał! To doświadczenie zawsze służy mi jako przypomnienie, że zawsze są wymiary powyżej i poniżej tego, co naturalnie podejrzewasz.
Punktem do rozważenia jest także cel systemu i danych z dnia na dzień.
Na przykład w przypadku systemu z monitorowaniem GPS samochodów nie ma odpowiednich danych zapytań z pozycji samochodu w poprzednich miesiącach.
Dlatego dane mogą być przekazywane do innych tabel historycznych w celu ewentualnych konsultacji i zmniejszenia czasu wykonywania codziennych zapytań.
Wydajność może spaść w ciągu kilku tysięcy wierszy, jeśli baza danych nie zostanie poprawnie zaprojektowana.
Jeśli masz odpowiednie indeksy, użyj odpowiednich silników (nie używaj MyISAM tam, gdzie oczekuje się wielu DML), użyj partycjonowania, przydziel odpowiednią pamięć w zależności od zastosowania i oczywiście dobrą konfigurację serwera, MySQL może obsługiwać dane nawet w terabajtach!
Zawsze istnieją sposoby na poprawę wydajności bazy danych.
To zależy od twojego zapytania i weryfikacji.
Na przykład pracowałem z tabelą 100 000 leków, która ma ogólną nazwę kolumny, w której ma więcej niż 15 znaków dla każdego leku w tej tabeli. Zadałem zapytanie, aby porównać ogólną nazwę leków między dwiema tabelami. więcej minut do uruchomienia. To samo, jeśli porównasz leki za pomocą indeksu leków, używając kolumny identyfikatora (jak wspomniano powyżej), zajmie to tylko kilka sekund.
Rozmiar bazy danych ma znaczenie pod względem bajtów i liczby wierszy tabeli. Zauważysz ogromną różnicę wydajności między lekką bazą danych a bazą danych wypełnioną kroplami. Gdy moja aplikacja utknęła, ponieważ umieszczam obrazy binarne w polach zamiast przechowywać obrazy w plikach na dysku i umieszczać tylko nazwy plików w bazie danych. Z drugiej strony iteracja dużej liczby wierszy nie jest darmowa.
Nie, to naprawdę nie ma znaczenia. Prędkość MySQL wynosi około 7 milionów wierszy na sekundę. Możesz więc trochę skalować
Wydajność zapytania zależy głównie od liczby rekordów, które należy przeskanować, indeksy odgrywają w nim dużą rolę, a rozmiar danych indeksów jest proporcjonalny do liczby wierszy i liczby indeksów.
Zapytania z indeksowanymi warunkami pola wraz z pełną wartością byłyby zwracane ogólnie w ciągu 1 ms, ale start_with, IN, Between, oczywiście zawiera warunki mogą zająć więcej czasu i więcej rekordów do skanowania.
Ponadto będziesz mieć wiele problemów z obsługą DDL, takich jak ALTER, DROP będzie powolny i trudny z większym ruchem na żywo, nawet po dodaniu indeksu lub nowych kolumn.
Zasadniczo wskazane jest zgrupowanie bazy danych w tyle klastrów, ile potrzeba (500 GB byłoby ogólnym testem porównawczym, jak twierdzą inni, zależy to od wielu czynników i może się różnić w zależności od przypadków użycia), w ten sposób zapewnia lepszą izolację i daje niezależność względem skali klastry (bardziej odpowiednie w przypadku B2B)