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

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?

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).

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.

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.

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).

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ń.

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.

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.

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!

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)