Jak duża może być baza danych MySQL zanim zacznie spadać wydajność

Ogólnie rzecz biorąc jest to kwestia bardzo subtelna i wcale nie trywialna. Zachęcam do lektury mysqlperformanceblog.com i Wysokiej Wydajności MySQL. Naprawdę myślę, że nie ma na to ogólnej odpowiedzi.

Pracuję nad projektem, który ma bazę danych MySQL z prawie 1TB danych. Najważniejszym czynnikiem skalowalności jest PAMIĘĆ RAM. Jeśli indeksy tabel pasują do pamięci, a zapytania są wysoce zoptymalizowane, możesz obsłużyć rozsądną liczbę zapytań za pomocą Przeciętna maszyna.

Liczba rekordów ma znaczenie, w zależności od tego, jak wyglądają tabele. Różnica polega na tym, że jest dużo pól varchar lub tylko kilka int lub Long.

Wielkość fizyczna bazy danych również ma znaczenie: pomyśl na przykład o kopiach zapasowych. W zależności od silnika, fizyczne pliki db rosną, ale nie kurczą się, na przykład z innodb. Więc usunięcie wielu wierszy nie pomaga zmniejszyć fizycznych plików.

Jest wiele w tej kwestii 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, wydajność zaczyna rzeczywiście spadać. Liczba rekordów ma oczywiście wpływ na wydajność: MySQL może być powolny przy dużych tabelach . Jeśli trafisz milion rekordów, pojawią się problemy z wydajnością, jeśli indeksy nie są ustawione poprawnie(na przykład brak indeksów dla pól w" where statements "lub" ON conditions " w połączeniach). Jeśli trafisz 10 milionów płyt, zaczniesz uzyskaj problemy z wydajnością, nawet jeśli masz wszystkie swoje indeksy w porządku. Ulepszenia sprzętu-dodanie większej ilości pamięci i większej 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ład 37 sygnałów przeszło z 32 GB PAMIĘCI RAM do 128 GB PAMIĘCI RAM dla serwera bazy danych Basecamp.

Skupiłbym się najpierw na Twoich indeksach, niż na adminie serwera, który spojrzy na Twój system operacyjny, a jeśli to wszystko nie pomoże, może to być czas na konfigurację master / slave.

- > Zobacz partycjonowanie .

2GB i ok. 15m rekordów to bardzo mała baza danych - na pentium III uruchomiłem dużo większe (!) i wszystko nadal działa dość szybko.. Jeśli twój jest powolny, jest to problem z projektowaniem bazy danych/aplikacji, a nie mysql.

Nie ma sensu mówić o "wydajności bazy danych", "wydajność zapytań" jest tutaj lepszym terminem. A odpowiedź brzmi: to zależy od zapytania, danych, na których działa, indeksów, sprzętu itp. Możesz zorientować się, ile wierszy będzie skanowanych i jakie indeksy będą używane w składni EXPLAIN.

2GB tak naprawdę nie liczy się jako "duża" baza danych - jest raczej średniej wielkości.

Uważaj również na złożone połączenia. Złożoność transakcji może być dużym czynnikiem oprócz wielkości transakcji.

Refaktoryzacja ciężkich zapytań czasami oferuje duży wzrost wydajności.

Kiedyś zostałem wezwany do spojrzenia na mysql, który "przestał działać". Odkryłem, że pliki DB znajdują się na urządzeniu sieciowym filer zamontowanym z NFS2 i o maksymalnym rozmiarze pliku 2GB. I oczywiście tabela, która przestała akceptować transakcje była dokładnie 2GB na dysku. Ale jeśli chodzi o krzywą wydajności, powiedziano mi, że działało jak mistrz, aż w ogóle nie działało! To doświadczenie zawsze służy mi jako miłe przypomnienie, że są zawsze wymiary powyżej i poniżej tego, co naturalnie podejrzewasz.

Punktem do rozważenia jest również cel systemu i dane na co dzień.

Na przykład, dla systemu z monitoringiem GPS Samochodów nie jest istotne zapytanie danych z pozycji samochodu w poprzednich miesiącach.

W związku z tym dane mogą być przekazywane do innych tabel historycznych w celu ewentualnej konsultacji i skrócić czas wykonywania codziennych zapytań.

Obecnie zarządzam bazą danych MySQL na infrastrukturze chmurowej Amazon, która wzrosła do 160 GB. Wydajność zapytań jest dobra. To, co stało się koszmarem, to tworzenie kopii zapasowych, przywracanie, dodawanie niewolników lub cokolwiek innego, co dotyczy całego zbioru danych, a nawet DDL na dużych tabelach. Uzyskanie czystego importu pliku zrzutu stało się problematyczne. Aby proces był wystarczająco stabilny, aby zautomatyzować, konieczne było dokonanie różnych wyborów, aby nadać priorytet stabilności nad wydajnością. Jeśli kiedykolwiek będziemy musieli odzyskanie po awarii przy użyciu kopii zapasowej SQL, będziemy w dół na kilka dni.

Poziome skalowanie SQL jest również dość bolesne i w większości przypadków prowadzi do używania go w sposób, w jaki prawdopodobnie nie zamierzałeś, gdy zdecydowałeś się umieścić swoje dane w SQL w pierwszej kolejności. Shards, read slaves, multi-master, et al, wszystkie są naprawdę gównianymi rozwiązaniami, które dodają złożoności wszystkim, co kiedykolwiek robisz z DB, i żaden z nich nie rozwiązuje problemu; tylko łagodzi go w jakiś sposób. Zdecydowanie polecam patrząc na przenoszenie niektórych danych z MySQL (lub naprawdę dowolnego SQL), gdy zaczynasz zbliżać się do zbioru danych o rozmiarze, w którym tego typu rzeczy stają się problemem.

Wydajność może ulec pogorszeniu w ciągu kilku tysięcy wierszy, jeśli baza danych nie jest prawidłowo zaprojektowana.

Jeśli masz odpowiednie indeksy, używaj odpowiednich silników (nie używaj MyISAM gdzie oczekuje się wielu DML), używaj partycjonowania, przydzielaj poprawną pamięć w zależności od zastosowania i oczywiście masz dobrą konfigurację serwera, MySQL może obsłużyć dane nawet w terabajtach!

Zawsze są sposoby na poprawę wydajności bazy danych.

To zależy od Twojego zapytania i walidacji.

Na przykład pracowałem z tabelą 100 000 leków, która ma nazwę rodzajową kolumny, gdzie ma więcej niż 15 znaków dla każdego leku w tej tabeli .Umieściłem zapytanie, aby porównać ogólną nazwę leków między dwoma tabelami.Uruchomienie zapytania zajmuje więcej minut.To samo, jeśli porównasz leki za pomocą indeksu narkotyków, używając kolumny id (jak wspomniano powyżej), zajmuje 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 wypełnioną blobem. Kiedyś moja aplikacja utknęła, ponieważ umieszczam binarne obrazy w polach zamiast przechowywać obrazy w plikach na dysku i umieszczać tylko nazwy plików w bazie danych. Iteracja dużej liczby wierszy z drugiej strony nie jest za darmo.