Jak duże bazy danych MySQL może dostać zanim zacznie się pogorszyć wydajność

głosy
253

W jakim punkcie jest baza danych MySQL zaczynają tracić wydajność?

  • Czy fizyczny rozmiar bazy danych ma znaczenia?
  • Czy liczba rekordów znaczenie?
  • Czy każdy występ degradacja liniowy lub wykładniczy?

Mam co uważam za duża baza danych, z grubsza zapisów 15M, które zajmują prawie 2GB. Na podstawie tych liczb, jest jakaś zachęta dla mnie, aby wyczyścić dane na zewnątrz, czy jestem bezpieczna, aby umożliwić jej skalowanie kontynuować przez kilka lat?

Utwórz 04/08/2008 o 15:31
źródło użytkownik
W innych językach...                            


14 odpowiedzi

głosy
169

Fizyczny rozmiar bazy danych nie ma znaczenia. Liczba rekordów nie mają znaczenia.

Z mojego doświadczenia wynika, że ​​największym problemem idziesz do pracy, by nie wielkość, ale liczba zapytań można obsłużyć na raz. Najprawdopodobniej będziesz musiał przejść do konfiguracji master / slave, tak że można uruchomić kwerendy odczytu wobec niewolników i zapytań zapisu prowadzonych przeciwko panu. Jednakże, jeśli nie jesteś jeszcze na to gotowa, zawsze możesz dostosować indeksów dla zapytań są uruchomione, aby przyspieszyć czas reakcji. Ponadto istnieje wiele szczypanie można zrobić do stosu sieciowego i jądra systemu Linux, które pomogą.

Miałem kopalni wstać do 10GB, tylko z umiarkowaną liczbę połączeń i obsługiwane żądania dobrze.

Chciałbym skupić się najpierw na swoich indeksów, a następnie mieć wygląd administratora serwera na swoim OS, a jeśli to wszystko nie pomoże to może być czas, aby wdrożyć konfiguracji master / slave.

Odpowiedział 04/08/2008 o 16:26
źródło użytkownik

głosy
71

Na ogół jest to bardzo subtelne i nie trywialny problem w ogóle. Zachęcam do zapoznania się mysqlperformanceblog.com i wysoką wydajność MySQL . Naprawdę myślę, że nie istnieje ogólna odpowiedź na to.

Pracuję nad projektem, który ma bazę danych MySQL z prawie 1 TB danych. Najważniejszym czynnikiem jest skalowalność pamięci RAM. Jeśli indeksy tabel pasuje do pamięci i twoi zapytania są wysoce zoptymalizowane, można służyć odpowiednią ilość wniosków o średniej maszynie.

Liczba rekordów ma znaczenia, w zależności od tego, jak tabele wyglądać. Jest to różnica mieć dużo pól varchar lub tylko kilka wskazówki i tęskni.

Fizyczny rozmiar spraw baz danych, a także: myśleć kopii zapasowych, na przykład. W zależności od silnika fizycznego db plików na rosnąć, ale nie kurczą się, na przykład z InnoDB. Więc usuwając wiele wierszy, nie pomaga się kurczyć plików fizycznych.

Jest dużo do tej kwestii i jak w wielu przypadkach diabeł tkwi w szczegółach.

Odpowiedział 04/08/2008 o 19:44
źródło użytkownik

głosy
8

Również zwrócić uwagę na kompleks łączy. złożoność transakcji może być ważnym czynnikiem oprócz wolumenu transakcji.

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

Odpowiedział 04/08/2008 o 20:01
źródło użytkownik

głosy
9

I raz został wezwany do spojrzeć na mysql, który miał „przestał działać”. Odkryłem, że pliki DB zamieszkiwali na filer Network Appliance zamontowanym z NFS2 iz maksymalny rozmiar pliku 2GB. I rzeczywiście, w tabeli, które zaprzestały przyjmowania transakcji było dokładnie 2 GB na dysku. Ale w odniesieniu do krzywej wydajności Powiedziano mi, że to działa jak mistrz aż do to nie działa w ogóle! To doświadczenie zawsze służy mi jako miły przypomnieniem, że nie zawsze są wymiary powyżej i poniżej jednego naturalnie podejrzanego.

Odpowiedział 06/08/2008 o 05:27
źródło użytkownik

głosy
16

To trochę bez sensu mówić o „wydajności bazy danych”, „wydajność zapytanie” jest lepsze określenie tutaj. A odpowiedź brzmi: to zależy od zapytania, danych, że działa on, indeksów, sprzętu, itd. Można zorientować się, ile wierszy zostaną zeskanowane i co indeksy będą używane z EXPLAIN składni.

2GB tak naprawdę nie liczy się jako „duże” bazy danych - to raczej średniej wielkości.

Odpowiedział 06/08/2008 o 20:53
źródło użytkownik

głosy
20

Chciałbym skupić się najpierw na swoich indeksów, niż mieć wygląd administratora serwera na swoim OS, a jeśli to wszystko nie pomoże to może być czas na konfiguracji master / slave.

To prawda. Inną rzeczą, która zazwyczaj pracuje, to po prostu zmniejszyć ilość danych, która jest wielokrotnie pracowałem. Jeśli masz „stare dane” i „nowych danych” i 99% zapytań pracować z nowymi danymi, po prostu przenieść wszystkie stare dane do innej tabeli - i nie patrzeć na niego;)

-> Zapraszamy do obejrzenia partycjonowania .

Odpowiedział 11/08/2008 o 20:19
źródło użytkownik

głosy
19

2GB i około 15M zapisów jest bardzo mała baza danych - Zabrakło mi znacznie większe z nich na Pentium III i wszystko nadal działać dość szybko .. Jeśli twój jest wolny to jest problem projektowania baz danych / aplikacji, a nie mysql (!) jeden.

Odpowiedział 05/08/2010 o 10:03
źródło użytkownik

głosy
33

Wielkość bazy danych ma znaczenia . Jeśli masz więcej niż jedną tabelę z ponad milion rekordów, wówczas wydajność rzeczywiście zaczyna się pogarszać. Liczba rekordów ma oczywiście wpływ na wydajność: MySQL może być powolny z dużych tabel . Jeśli trafisz jeden milionów płyt dostaniesz problemy z wydajnością, jeśli indeksy nie są ustawione w prawo (na przykład nie indeksy dla pól „gdzie w sprawozdaniu” lub „ON” w warunkach przyłącza). Jeśli trafisz 10 milionów płyt, to zaczynają się problemy z wydajnością nawet jeśli masz wszystkie indeksy rację. Rozbudowa komputera - dodanie większej ilości pamięci i większej mocy procesora, zwłaszcza pamięci - często pomaga zmniejszyć najpoważniejszych problemów poprzez zwiększenie wydajności znowu, przynajmniej do pewnego stopnia. Na przykład37 sygnałów się z 32 GB RAM 128 GB pamięci RAM dla serwera bazy Basecamp.

Odpowiedział 26/01/2012 o 11:33
źródło użytkownik

głosy
9

Punkt do rozważenia jest również celem systemu i danych w dnia na dzień.

Na przykład dla systemu z monitoringu GPS pojazdów nie jest istotne dane zapytanie z pozycji samochodu w poprzednich miesiącach.

W związku z tym dane mogą być przekazywane do innych tabelach historycznych dla ewentualnej konsultacji i skrócić czas realizacji do dnia zapytań dziennie.

Odpowiedział 06/12/2012 o 06:13
źródło użytkownik

głosy
4

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

Jeśli masz odpowiednie indeksy, należy użyć odpowiednich silników (nie używać MyISAM gdzie są oczekiwane wiele DML), używać partycjonowanie, przydzielać pamięć poprawne w zależności od zastosowania i oczywiście mieć dobrą konfigurację serwera MySQL może obsługiwać dane nawet w TB!

Nie zawsze są sposoby poprawy wydajności bazy danych.

Odpowiedział 19/09/2013 o 12:26
źródło użytkownik

głosy
2

To zależy od tego zapytania i walidacji.

Na przykład, pracowałem ze stołem 100 000 leków, które ma kolumnę nazwę rodzajową, gdzie ma więcej niż 15 znaków dla każdego leku w tej tabeli .I wprowadzone zapytanie do porównania nazwę rodzajową narkotyków pomiędzy dwa zapytania tables.The trwa więcej minut do run.The samo, jeśli porównać leków przy użyciu indeksu leków, stosując kolumnę iD (jak wspomniano powyżej), to zajmuje tylko kilka sekund.

Odpowiedział 29/11/2016 o 12:05
źródło użytkownik

głosy
2

Wielkość bazy danych ma znaczenia, jeśli chodzi o liczbę bajtów i wierszy tabeli. można zauważyć ogromną różnicę wydajności pomiędzy lekkim bazy i jeden blob wypełnione. Raz mój wniosek utknął ponieważ kładę obrazy binarne wewnątrz pól zamiast utrzymywania obrazów w plikach na dysku i wprowadzenie tylko nazwy plików w bazie danych. Iteracja dużą liczbę wierszy z drugiej strony nie jest za darmo.

Odpowiedział 05/06/2017 o 10:27
źródło użytkownik

głosy
4

Jestem obecnie zarządzanie bazą danych MySQL w chmurze infrastruktury Amazona że wzrosła do 160 GB. wydajność kwerendy jest w porządku. Co stało się koszmarem jest tworzenie kopii zapasowych, przywracanie, dodawanie niewolnicy, czy cokolwiek innego, co dotyczy całego zestawu danych, a nawet DDL na dużych tabelach. Uzyskanie czystego import pliku zrzutu stało się problematyczne. W celu uczynienia procesu wystarczająco stabilny, aby zautomatyzować, różne wybory musiały być wykonane do priorytetowego traktowania stabilności wydajności. Jeśli kiedykolwiek miał do odzyskania po awarii przy użyciu kopii zapasowej SQL, bylibyśmy w dół przez kilka dni.

Poziomo skalowanie SQL jest także dość bolesne, a w większości przypadków prowadzi do używania go w sposób, którego zapewne nie zamierzają kiedy zdecydował się umieścić swoje dane w SQL w pierwszej kolejności. Odłamki, przeczytaj niewolników, multi-master, et al, wszystkie one są naprawdę gówniany rozwiązania, które dodają złożoności do wszystkiego, co kiedykolwiek zrobić z DB, i żaden z nich nie rozwiązuje problemu; tylko łagodzi go w pewnym sensie. Chciałbym zdecydowanie sugerują, patrząc na przeniesienie niektórych danych z MySQL (lub naprawdę dowolnego SQL) po uruchomieniu zbliża zestawu danych o rozmiarze gdzie tego typu rzeczy stać się problemem.

Odpowiedział 30/06/2017 o 16:25
źródło użytkownik

głosy
0

Nie, to nie robi to większego znaczenia. Prędkość MySQL jest około 7 milionów wierszy na sekundę. Dzięki czemu można go skalować sporo

Odpowiedział 25/05/2019 o 12:18
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more