SSD vs HDD dla baz danych

42

Usiłuję kupić nowy serwer, na którym będzie działał serwer MySQL. Ten nowy serwer będzie niewolnikiem mojej głównej maszyny. Serwer ten będzie jednak przeznaczony wyłącznie do raportowania „Dużo odczytów i złożonych zapytań”.

Teraz zastanawiam się nad zainwestowaniem w półprzewodnikowe dyski twarde, ale zastanawiałem się, czy naprawdę jest to warte swojej ceny. Różnica między dyskiem SSD a dyskiem twardym SATA 7200 wynosi około 1500 USD, a dysk SSD ma mniej miejsca na dysku. Czy jeśli zainwestuję w dysk SSD, prędkość będzie zauważalna?

Mogę kupić 4 (500 GB SATA 7200) za 1500 USD mniej niż zakup 2 (500 GB SSD)

Czy możesz mi pomóc w podjęciu decyzji, czy warto uaktualnić, czy nie?

Jeszcze raz chciałbym wspomnieć, że nie używam, query_cachewięc będzie dużo odczytów dysku.

Ten serwer będzie miał 32 GB pamięci RAM i będzie działał na Ubuntu 12.04

Mikrofon
źródło
Jak duża jest twoja baza danych pod względem gigabajtów? Która z poniższych odpowiedzi jest najbardziej poprawna, tak naprawdę zależy od zrozumienia ilości danych.
Nathan Jolly,
1
Jeśli w końcu użyjesz dysków SSD, możesz poczekać do kwietnia na Ubuntu 14.04 lub włączyć TRIM ręcznie 12.04. Zobacz ten artykuł, aby uzyskać więcej informacji.
OSE
5
Serial ATA (SATA) to interfejs. Istnieją dyski SSD SATA i dyski twarde (HDD), które nie używają SATA.
Dennis
Kupowanie czegoś, co nie przynosi dla ciebie pieniędzy, nie jest inwestycją ...
inf3rno

Odpowiedzi:

25

Tak, przy dużej liczbie odczytów i zgłaszaniu dysku SSD zrobi ogromną różnicę. Z dysku o prędkości 7200 obr./min można oczekiwać nie więcej niż ~ 100 IOPS, podczas gdy najtańszy dysk SSD może być co najmniej 5 razy tak szybki. Przy dobrym dysku SSD możesz uzyskać 20000 IOPS lub nawet więcej.

Również losowe zapisy na SSD są znacznie szybsze, ponieważ dysk nie musi się ruszać za każdym razem.

nmad
źródło
4
Jak zdefiniowałbyś dobry dysk SSD?
Mike
Chodzi o wydajność i testy porównawcze. Chciałbym zrobić w Google testy porównawcze lub recenzje modelu dysku SSD, który kupujesz. Poza tym en.wikipedia.org/wiki/IOPS#Examples daje bardzo ogólny przegląd.
nmad
20

Należy wziąć pod uwagę trzy czynniki:

  1. Rozmiar twojej bazy danych
  2. Ilość pamięci, którą masz na serwerze
  3. Twoja konfiguracja my.cnf innodb_buffer_pool_size

Jeśli dostępna pamięć> rozmiar bazy danych , serwer prawdopodobnie będzie w stanie przechowywać wszystkie dane w pamięci, a zatem dysk SSD może być stratą pieniędzy. Bufor InnoDB nie ma nic wspólnego z query_cacheopcjami.

Jeśli dostępna pamięć <rozmiar bazy danych , zapytania mogą wymagać pobrania danych z dysku. W przypadku bardzo złożonych zapytań lub gdy wielu użytkowników uruchamia zapytania jednocześnie, może to zacząć obciążać dysk.

Ogólnie rzecz biorąc, bazy danych przechowują najczęściej używane dane w pamięci - jeśli 80% twoich danych jest rzadko / nigdy nie jest używane, będziesz musiał zachować tylko 20% bazy danych w pamięci, aby utrzymać wydajność.

Dokładna ilość potrzebnej pamięci nie będzie od razu oczywista, ale jeśli twoja baza danych nie przekracza 200 GB, zdecydowanie zaleciłbym skorzystanie z porady Up_One i wydanie dodatkowych pieniędzy na pamięć zamiast dysków SSD.

Uwaga: jeśli Twoja baza danych korzysta z MyISAM (możesz to sprawdzić za pomocą show table status;), rozważ zmianę na InnoDB. MyISAM key_buffer_cacheprzechowuje tylko bloki indeksu, gdzie jako pula buforów InnoDB przechowuje całe bloki danych. W większości przypadków InnoDB będzie lepszym silnikiem do pracy.

Nathan Jolly
źródło
Jak mogę umieścić bazę danych w pamięci? serwer jest niewolnikiem, więc będzie na nim cały czas zapisywał, ale z powodu raportów będzie też miał duże obciążenie odczytu
Mike
Jeśli twoje tabele to InnoDB i twoja pula buforów InnoDB jest wystarczająco duża, MySQL automatycznie zarządza buforowaniem twojej bazy danych w pamięci i będzie starał się przechowywać najczęściej używane dane w pamięci przez cały czas. Dokumentacja MySQL zapewnia całkiem dobry przegląd tego, jak to działa .
Nathan Jolly
@NathanJolly, nawet jeśli cała baza danych jest w pamięci, nadal będzie czytana i zapisywana na dysku twardym po zapisaniu danych + istnieją ograniczenia różnych serwerów. Na przykład wersja SQL Server Express jest ograniczona do używanej tylko 1 GB pamięci, więc nie może pomieścić dużej bazy danych w pamięci na pierwszym miejscu.
Jackofall
@Jackofall, choć jest to absolutnie prawda, pytanie tutaj określało obszerną bazę danych MySQL do odczytu. Każde zapytanie tylko do odczytu, które może być obsługiwane z pamięci zamiast docierać do dysku - nawet szybki dysk - to dobra wiadomość.
Nathan Jolly,
6

Nie sądzę, że to dobry pomysł!
Moja rada
zwiększenie wielkości puli buforów InnoDB jest najlepszym sposobem na przyspieszenie MySQL. Jeśli możesz dodać więcej pamięci RAM, zrób to. Spowoduje to zapisanie większości twoich gorących danych w pamięci, więc wyobraź sobie! Dysk vs pamięć!
Idealny scenariusz to mieć pamięć o wielkości bazy danych
SSD - jest świetny, ale będzie kosztowny! i nadaje się tylko do prac wymagających intensywnego czytania.

Sprawdź ten link, aby znaleźć fajny artykuł na ten temat od Vadima Tkachenko

Up_One
źródło
1
Artykuł, do którego linkujesz, ma prawie 4 lata, ceny dysków SSD w porównaniu do tego momentu w czasie są o ponad połowę niższe, a wydajność również znacznie wzrosła. Pamięć rozmiar bazy danych? Co powiesz na bazę danych 500 Gb? To nie tylko ilość pamięci RAM, ale także serwer, który musisz kupić, który ma tak wiele dostępnych banków pamięci.
Jarosław
Jeśli chodzi o rozmiar DB! Tak, nie ma takiej możliwości - Ale jak już powiedziałem To byłby idealny scenariusz!
Up_One
6

Aby dać alternatywę: możesz użyć obu, dużego dysku twardego (najlepiej RAID1 z trzema dyskami) do przechowywania danych i mniejszego dysku SSD do przechowywania indeksów.

Racjonalne uzasadnienie:

  • indeksy są dość małe, więc możesz użyć mniejszego dysku SSD
  • typowe zapytania i tak powinny przede wszystkim trafić do indeksów
  • RAID1 zapewnia odporność na awarie
  • RAID1 zapewnia równoważenie obciążenia dla losowych odczytów
  • trzy dyski pozostawiają odporność na uszkodzenia w przypadku awarii dysku
  • indeksy można odbudować, jeśli dysk SSD ulegnie awarii
Simon Richter
źródło
5

Zrób to.

Wspomniałeś, że masz duże obciążenie do odczytu, więc już uniknąłeś dużego problemu z używaniem dysków SSD w bazach danych: zużycie. Brak zapisu oznacza brak zużycia, więc jesteś złoty.

Jak wspomniano w edvinas.me, Twój IOPS jest o rząd wielkości szybszy w przypadku SSD niż w przypadku wirujących dysków. W przypadku bazy danych IOPS prawie przekłada się na żądania na sekundę. Ignorując pamięć podręczną RAM, obsłużysz około 100 razy więcej żądań z dysku SSD niż z dysku 7200 RPM.

TRIM nie robi dużej różnicy, ponieważ jest to obciążenie wymagające dużego odczytu i wygląda na to, że i tak planujesz zapełnić dysk. Nie stresuj się tym.

Nie jestem pewien, skąd wzięła się rzecz za 1500 $. Sprawdzając mojego lokalnego (australijskiego) dostawcę, mogę uzyskać dysk SSD o pojemności 960 GB renomowanej marki za 750 USD ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adapter-ssd-read-500mb-s-write-400mb-s / ). Wirujące dyski są mniej więcej darmowe, ale 750 USD jest o wiele bardziej smaczne niż 1500 USD.

(Och, czekaj - prawdopodobnie zamawiasz u znanego dostawcy, więc płacą ci za dysk SSD? Zawsze kupuję dysk SSD osobno i wymieniam go w sobie, ale nie wiem, czy to dozwolone w twoim otoczeniu).

Prawdopodobnie uciekniesz także z mniejszej ilości pamięci RAM, ale nie znając dokładnego obciążenia pracą, trudno jest ocenić, czy możesz bezpiecznie zmniejszyć ilość pamięci RAM bez pogorszenia wydajności.

Jeśli nadal nie masz pewności, możesz uzyskać duże dyski o prędkości 10 000 obr./min, ale w końcu kosztują prawie tyle samo co dysk SSD, a jednocześnie są znacznie wolniejsze.

Jeśli musisz skalować znacznie powyżej 1 TB, dyski SSD stają się zbyt drogie, ale przy 1 TB powiedziałbym, że SSD to wyraźna wygrana.

Ian Howson
źródło
3

Zdecydowanie zgadzam się, że największy huk za złotówki wynika ze zwiększenia twojego rozmiaru innodb_db_bufferpool, ale niestety to całkowicie zależy od tego, jak duży jest twój zestaw danych i jak często dostępne są różne bloki dysku. Utrzymuję kilka baz danych, które są dość duże 200 GB +, więc dopasowanie wszystkiego do pamięci RAM nie jest tak naprawdę opcją iz tego powodu niedawno przeszliśmy na pamięć masową opartą na SSD. Przeprowadziłem dość duże badania w zakresie wykorzystania IOPS dla MySQL na różnych macierzach RAID, do których mam dostęp. Oto wyniki:

1253 IOPS - 4 x SCSI 15k (3,5 ") dysk

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 odczyt: io = 3071,7 MB, bw = 5012,8 KB / s, iops = 1253 , runt = 627475 ms, zapis: io = 104,4 MB, mc = 1671.7 KB / s, iops = 417, runt = 627475 ms, procesor: usr = 0,63%, sys = 3,11%, ctx = 985926, majf = 0, minf = 22

2558 IOPS - dysk 8 x 10K RPM 900 GB SAS (2,5 ")

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 odczyt: io = 3071,7 MB, bw = 10236 KB / s, iops = 2558, runt = 307293 ms zapis: io = 104,4 MB, mc = 3413,5 KB / s, iops = 853, runt = 307293 ms cpu: usr = 2,73%, sys = 8,72%, ctx = 904875, majf = 0, minf = 25

23 456 IOPS - serwer SSD Rackspace Performance 2

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 odczyt: io = 3071,7 MB, bw = 93708 KB / s, iops = 23426, runt = 33566 ms pisz: io = 1024,4 MB, mc = 31249 KB / s, iops = 7812, runt = 33566 msec procesor: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35.484 IOPS - 2 x Mirrored EDGE Boost 480GB 2.5 "MLC ( http://www.edgememory.com )

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 odczyt: io = 3068.4 MB, bw = 141934 KB / s, iops = 35483, runt = 22137 ms pisz: io = 1027,7 MB, mc = 47537 KB / s, iops = 11884, runt = 22137 ms cpu: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20

Jest więc jasne, że dzisiejszy dysk SSD wysokiej jakości jest niesamowity. Dwa zwierciadlane dyski SSD mogą z łatwością przewyższyć 16-dyskową obudowę pamięci masowej SAN, co jest przekonującym stwierdzeniem.

Jeśli jesteś zainteresowany pełnymi szczegółami, resztę pisania znajdziesz na moim blogu:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html

Juha Vehnia
źródło