Aby poprawić wydajność SQL, dlaczego nie po prostu umieścić dużo pamięci RAM zamiast mieć szybsze dyski twarde?

31

Ludzie powtarzają mi, że aby poprawić wydajność serwera SQL, kup najszybsze dyski twarde z RAID 5 itp.

Pomyślałem więc, że zamiast wydawać wszystkie pieniądze na RAID 5 i superduperowalne szybkie dyski twarde (które nie są tanie), dlaczego po prostu nie dostać ton pamięci RAM? Wiemy, że serwer SQL ładuje bazę danych do pamięci. Pamięć jest znacznie szybsza niż jakiekolwiek dyski twarde.

Dlaczego nie wpakować na serwer 100 GB pamięci RAM? Następnie użyj zwykłego dysku twardego SCSI z RAID 1. Czy nie byłoby to o wiele tańsze i szybsze?

użytkownik1034912
źródło
33
Ktokolwiek mówi ci RAID 5, nie ma pojęcia. Jeśli naprawdę zależy Ci na wydajności, użyj RAID 10
MDMarra
5
Co oznacza skrót D in ACID? W końcu będziesz musiał coś spisać.
Adam Musch

Odpowiedzi:

51

Twoja analiza jest w porządku - do tego stopnia - że absolutnie przyspieszy. Nadal jednak musisz wziąć pod uwagę kilka innych problemów:

  1. Nie wszyscy mogą sobie pozwolić na wystarczającą pamięć; gdy masz wiele terabajtów danych, musisz na jakiś czas umieścić je na dysku. Jeśli nie masz dużo danych, wszystko jest wystarczająco szybkie.

  2. Wydajność zapisu w bazie danych będzie nadal ograniczona przez dyski, abyś mógł dotrzymać obietnicy, że dane zostały faktycznie zapisane.

Jeśli masz mały zestaw danych lub nie musisz go przechowywać na dysku, nie ma nic złego w tym pomyśle. Narzędzia takie jak VoltDB działają w celu zmniejszenia kosztów ogólnych, które zostały wykonane przez starsze założenia w implementacjach RDBMS, które ograniczają czystą wydajność w pamięci.

(Nawiasem mówiąc, ludzie mówiąc ci, aby używać RAID-5 do wydajności bazy danych, prawdopodobnie nie są świetnymi ludźmi do słuchania na ten temat, ponieważ prawie nigdy nie jest to najlepszy wybór - ma dobrą wydajność odczytu, ale słabą wydajność zapisu i pisze są prawie zawsze ograniczeniem produkcyjnym - ponieważ można wrzucić pamięć RAM do pamięci podręcznej, aby rozwiązać większość problemów z wydajnością po stronie odczytu).

Daniel Pittman
źródło
1
Ogólni użytkownicy zawsze narzekają na problemy z czytaniem. Rzadko na problemy z
pisaniem
2
@ użytkownik1034912 - różni się w zależności od przypadku użycia i użytkowników. Zasadniczo problemy z wydajnością zapisu są trudniejsze do rozwiązania, a zatem nakładają większe ograniczenia na ogólną wydajność systemu, co oznacza, że ​​po rozwiązaniu problemu z czytaniem zaczynają narzekać na problem z pisaniem ...
Daniel Pittman,
2
@ user1034912, użytkownicy zwykle nie widzą opóźnień zapisu, więc nie są ich świadomi. Większość tego, co użytkownicy postrzegają jako opóźnienia odczytu, wynika z powolnych zapytań, a nie wolnych dysków.
John Gardeniers
Doskonała odpowiedź! @ user1034912 mogą narzekać na problemy z odczytem, ​​które oczywiście mogą być efektem domina z powodu niskiej wydajności zapisu (i słabo skalowalnego kodu współbieżności).
Alex
RAID5 w relacyjnych bazach danych: en.wikipedia.org/wiki/… - Nie mówię, że się mylisz, ale konwencjonalna mądrość może opierać się na starych informacjach. Osobiście nie używam już RAID5; Używam RAID6, chyba że jest zbyt wolny.
gWaldo
11

Wersja skrócona: rozważ rozmiar zestawu roboczego. Wersja długa: jak duże są twoje dane? Jeśli może zmieścić się w pamięci nowoczesnego serwera, tak, masz absolutną rację. Niestety, największy Xeon może teraz zająć 2 TB pamięci RAM i nie jest to już tak duży zestaw danych. Jeśli nie możesz kupić maszyny wystarczająco dużej, aby pomieścić cały zestaw roboczy w pamięci RAM, musisz rozwiązać problemy z mózgiem, a nie z portfelem.

Marcin
źródło
+1 za ostatnie zdanie, które jest niezwykle cytowane. : D
pkoch
8

Jeśli chcesz prędkości:

  • Zwiększ pamięć RAM, aby co najmniej często używane indeksy mogły całkowicie zmieścić się w pamięci RAM (na przykład w systemie, na którym pracuję, pamięć RAM o pojemności 32 GB wystarcza na bazę danych o pojemności 350 GB, ponieważ indeksy są tym, czego potrzebujesz w pamięci RAM, a nie surowymi danymi)
  • Użyj RAID10 z dowolnymi dyskami (im szybsze dyski, tym lepiej)
  • Unikaj RAID5
  • Podziel mdf, ldf i temp DB na dyskretne zestawy wrzecion (przykład: tempdb na własnym zestawie RAID1, ldf na własnym zestawie wrzecion RAID1 lub RAID10, mdf na zestawie RAID 10 z co najmniej 4 dyskami ogółem)

Wykonaj te kroki, a SQL Server poleci.

Następnie, jeśli chcesz, dodaj więcej pamięci RAM ... ale najpierw wykonaj powyższe czynności, a być może skończysz.

Jonesome przywraca Monikę
źródło
2

RAM to nowy dysk, dysk to nowa taśma.

W http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Zauważ, że to było sześć lat temu. Tak, mamy systemy baz danych, które starają się (i starają się) utrzymać cały zestaw danych w pamięci RAM i raczej oddzielić do wielu komputerów niż używać dysku, ponieważ dysk jest wolniejszy. Musisz zapisać zestaw danych na dysk, ale jak w powyższym motto, bardziej przypomina to wykonywanie kopii zapasowej w tle niż operację online. Trwałość osiąga się poprzez dołączanie tylko dzienników z tymi bazami danych (myślę, że MongoDB i Redis, ale jest ich o wiele więcej).

chx
źródło
4
-1, ponieważ jest to miłe, ponieważ nie jest tak naprawdę dostępne lub odpowiednie dla większości aplikacji lub większości z nas tutaj. Aby uzyskać do 500 GB danych (lub nawet więcej), wystarczy dwa serwery SQL (podstawowy i zapasowy) i naprawdę szybko używasz normalnych narzędzi dla setek lub tysięcy użytkowników. Bardzo niewielu z nas potrzebuje skalowania do setek tysięcy współbieżnych użytkowników lub wielu centrów danych, więc złożoność proponowanego podejścia znacznie przewyższa korzyści dla większości z nas. IOW: Skalowanie w pionie jest łatwe, tanie i skuteczne dla każdego, kto nie jest na Facebooku ani w Google.
Jonesome przywraca Monikę
1

To pytanie jest podobne do podstawowego, które w ciągu ostatnich 5-10 lat doprowadziło do wielu badań i rozwoju architektury baz danych. Teraz, gdy możliwe jest przechowywanie całej bazy danych w pamięci RAM dla wielu przypadków użycia, baza danych musi być zaprojektowana wokół pracy w pamięci RAM, zamiast po prostu zastosować starsze odziedziczone architektury do pamięci RAM.

Tak jak wiele mniejszych i bardziej specjalistycznych języków zostało powszechnie przyjętych w ostatnich latach, wkraczamy w erę, że potrzebne będą specjalne bazy danych.

W celu dalszej lektury na ten temat polecam artykuł naukowy The End of a Architectural Era (Nadszedł czas na całkowite przepisanie) . To nie jest trudna lektura.

Nie jest jasne, czy to pytanie dotyczyło konkretnie programu SQL Server. Oryginalny plakat powinien to wyjaśnić.

Daniel Pittman napisał:

Jeśli masz mały zestaw danych lub nie musisz go przechowywać na dysku, nie ma w tym nic złego> z twoim pomysłem. Narzędzia takie jak VoltDB działają w celu zmniejszenia narzutów, które starsze założenia w implementacjach RDBMS ograniczają czystą wydajność w pamięci.

Zmniejszenie kosztów ogólnych ze starszych założeń w implementacjach RDBMS było dokładnie celem projektowym VoltDB , ale skaluje się w poziomie bez ograniczeń architektonicznych co do wielkości danych i może utrzymywać się na dysku dla pełnej trwałości przy użyciu migawek i rejestrowania poleceń.

BenjaminBallard
źródło
0

Jeśli uda ci się uzyskać serwer z wystarczającą ilością pamięci RAM, aby pomieścić przynajmniej gorącą część zestawu danych, nic ci nie będzie. Ponadto RAID 1 i 5 nie są najszybszym sposobem na uporządkowanie danych - RAID 0 jest szybszy, ale wtedy będziesz musiał wziąć pod uwagę większe prawdopodobieństwo awarii systemu plików, która zniszczy bazę danych - nie jest to miłe zdarzenie . Możesz RAID 1 lub RAID 5 macierz RAID 0, pod warunkiem, że masz wystarczającą liczbę napędów i kontrolerów.

Możesz nawet grać tutaj z replikacją - zapisuj na obciążonym dysku serwerze, który replikuje się na jeden lub więcej serwerów obciążonych pamięcią, gdzie wykonujesz skomplikowane zapytania.

Niestety, RDBMS wydają się być w sferę wielkiego żelaza - nie są tak łatwe w uprawie poziomej.

wariat
źródło
0

Jest to przypadek „zależy od tego, co robisz”. Być może „właściwą” radą jest całkowite uniknięcie SQL i użycie memcache / redis / etc!

Zgadzam się z tobą, że dodatkowa pamięć RAM bardzo pomoże, zwłaszcza jeśli jesteś w stanie odczytać cały zestaw roboczy do pamięci RAM. Tak, nadal będzie musiał zapisywać dane, ale jeśli przeważnie czytasz, zapisy nie będą miały wpływu na dyskowe operacje we / wy.

Jednak wydajność dysku jest często wąskim gardłem na serwerach SQL i trudniejsza niż inne rzeczy, takie jak pamięć RAM do aktualizacji później (jeśli masz serwer, który nie jest w pełni zapełniony modułami DIMM).

Było wiele komentarzy na temat powolności RAID5, ale powiedziałbym, że nie zawsze tak jest, więc bądź ostrożny przed wypowiedzeniem oświadczeń. Naprawdę wysokiej klasy serwery z szybkimi kartami RAID i dużą ilością BBWC czasami działają znacznie szybciej w RAID5 (lub RAID50 z> 4 dyskami) niż w RAID10 ...

Przez lata osobiście doświadczyłem powolnych macierzy RAID5, ale po przeprowadzeniu testów porównawczych DL360 G5 z 4 dyskami SAS 146G w ~ 2009 roku, musieliśmy dwukrotnie sprawdzić nasze testy. Rzeczywiście, tablica szła szybciej z RAID5 niż RAID10 w prawie każdym teście. BBWC i szybkie obliczenia parzystości pozwoliły serwerowi na wykorzystanie 4 dysków znacznie efektywniej jako macierzy RAID5 niż RAID10. Niektóre testy wykazały 50% lepszą przepustowość z RAID5 i prawie żaden nie był wolniejszy. Wolniejsze testy były tylko o 5-10% niższe.

Ostrzegam ludzi, którzy składają ogólne oświadczenia, że ​​RAID5 działa wolno, wszyscy mówią to online, ale nie zawsze jest to prawda.

Matt
źródło
-1

Masz do wyboru mieszankę cukierków i naprawdę zależy od tego, jaki smak chcesz.

  1. Bazy danych będą miały konfigurację do buforowania zapytań i miejsca, w którym pamięć podręczna istnieje, pamięć lub dysk twardy.
  2. RAID 5 nie zawsze jest najszybszy, ale RAID 0 (JBOD) jest paskiem i jest szybki, ponieważ RAID 5 jest również paskiem, idea jest bardzo podobna.
  3. RAID 1 nie poprawi twojej prędkości, to tylko lustro.
  4. Wydajność SQL oparta jest na indeksowaniu i jest pierwszą rzeczą do sprawdzenia. Bardzo ważne w relacyjnych bazach danych.
  5. Nie indeksuj wszystkiego, nadmierne indeksowanie może również zmniejszyć prędkość, ponieważ indeksowanie staje się nadmiernie obciążone.
  6. Czasami z połączeniami SQL baza danych staje się wolniejsza. Używanie programowania do zapętlania zestawu minimalnych wyników indeksowanych poprawia szybkość.
  7. Serwery wirtualne to koszmar prędkości, jeśli nie zapłacisz dolarów.

Po prostu zainwestuj w wiedzę (bezpłatnie) przed wypłatą gotówki. 1. Naucz się konfiguracji dla swojej bazy danych i spójrz na aktualną konfigurację, aby ją zoptymalizować. 2. Spójrz na instrukcje programowania i SQL, test jednostkowy za pomocą prostych skryptów, które naśladują związane z tym operacje, może nawet nie być tym, co twoim zdaniem jest problemem. JEŻELI proste skrypty zajmują czas przy użyciu sprzężeń SQL, podziel je i zrób to samo z zaprogramowaną pętlą, aby zrobić to samo. To jest pamięć może pomóc 3. Spójrz na plan hostingowy i serwer. Użyj ps aux w konsoli Linux i sprawdź, czy coś zasysa twoją pamięć i procesor.

Absolutny dysk twardy poprawia prędkość, ale nie zależy od ciebie na przestrzeni wirtualnego serwera. Pamięć nie poprawia szybkości, chyba że skonfigurujesz dla niej usługi, kropka. Pomaga to w paski RAID (0,5), RPM i synchroniczny odczyt / zapis z szybką magistralą. Procesor rdzeniowy z dobrą pamięcią podręczną l1, l2, l3 pomoże w przetwarzaniu wąskiego gardła. czy słyszę to dla Xeona!

Mark Allen
źródło
2
RAID1 absolutnie poprawi prędkość w sytuacjach odczytu. Większość kontrolerów jest wystarczająco inteligentna, aby używać wielu wrzecion do odczytu z (identycznych) zestawów danych jednocześnie. RAID0 to zły pomysł, ponieważ jesteś ograniczony do wrzeciona na raz.
Bryan Boettcher
-4

Ogólnie rzecz biorąc, należy pamiętać o rozmiarze i skalowalności. Choć wydaje się, że zaczynasz od małych potrzeb w zakresie pamięci, Twoje dane będą rosły bardzo szybko i wykładniczo. DB najlepiej używać danych atomowych, które są danymi w podziale na najmniejszy możliwy rozmiar. Ze względu na mały rozmiar podróżuje szybciej w hurtowni danych. Następnie bierzesz również pod uwagę strukturę DB. W przyszłości możesz tworzyć linki do zewnętrznych baz danych, dlatego też struktura jest tak ważna. W tym scenariuszu zapytanie nie miałoby większego znaczenia, gdyby połowa danych żyła poza martwą bazą danych. W przypadku zapytań o dane nie chodzi o to, aby przechowywać dane w pamięci RAM; raczej zapytanie powinno umożliwiać szybki dostęp do danych i ich zwracanie.

  • Naprawdę nie zawsze używasz RAID 5 do danych. Zależy to od danych i ich znaczenia, oprócz tego, co wcześniej wspomniano o kopiach zapasowych. RAID 1 może być używany i jest.
  • Aby zaktualizować szybkość, musisz zaktualizować wszystkie serwery w zakresie zapytań. Ponieważ duża część danych jest poza twoją kontrolą, będzie wąskie gardło gdzieś poza twoją bazą danych. (W przypadku aktualizacji własnej)
galaxy6
źródło
Wow, czy skopiowałeś to ze swoich (niezrozumienia) swoich podręczników?
adapttr
Ugh. Ile razy trzeba ludziom mówić, że RAID nie jest rozwiązaniem kopii zapasowej?
Cromulent