Dysk pod bazę danych - odczyt sekwencyjny vs losowy

Cześć,
jak mierzymy wydajność dysku to bierzemy pod uwagę szybkość odczytu (oraz zapisu) sekwencyjnego oraz losowego.
Jeśli kupię sobie 4 dyski i zrobię sobie RAIDa to zwiększy mi się szybkość jedynie odczytu sekwencyjnego.
Pytanie: jeśli dysk ma służyć pod bazę danych (relacyjną) to większe znaczenie ma odczyt sekwencyjny czy losowy?

Moje wątpliwości wynikają z tego, że raz dane zapisuję do jednej tabeli a raz do drugiej i mam wątpliwość czy jak będę wydobywał dane z jednej tabeli to czy te dane będą pobierane jeszcze sekwencyjnie czy już bardziej losowo?
Zastanawiam się również czy RAID powinien zwiększyć wydajność bazy danych?
Czy dyski nvme robią różnicę w stosunku do zwykłych ssd (SATA) - w kontekście baz danych?

Poniżej zdjęcie z testów jednego z dysków: który parametr jest kluczowy w kontekście baz danych:
Z góry dziękuję za wyjaśnienie tematu.

Sekwencyjny interesuje cię wyłącznie gdy głównie kopiujesz gigantyczne pliki (kilkaset GB) w tę i we wtę. Czyli w praktyce nigdy. Marketingowa ściema.
Edit: w teorii mógłbyś porównywać sekwencyjny odczyt/zapis gdy porównujesz dwa dyski o identycznych parametrach odczytu/zapisu losowego. Ale w praktyce lepiej wtedy porównywać trwałość dysku (jak długo podziała), jego zachowanie przy dużym zapełnieniu (czy nie zwalnia, czy nie umiera wcześniej od tego), a nie dodatkowe MB/s przy sekwencyjnym zapisie/odczycie, którego praktycznie nie używasz.

Także interesuj się tylko i wyłącznie randomem, czy to pod serwery czy codziennie klikanie po internecie. I to prawdopodobnie nawet nie wartościami W MB tylko ilością operacji na sekundę (IOPS).

Dzięki.
Też mi się właśnie tak wydawało, ale wolałem to potwierdzić :).

dzek69 napisał(a):

Sekwencyjny interesuje cię wyłącznie gdy głównie kopiujesz gigantyczne pliki (kilkaset GB) w tę i we wtę. Czyli w praktyce nigdy. Marketingowa ściema.

NAWET gdyby myśleć o serii insertów do jednej tabeli, to punkt zapisu / odczytu dysku się przemieszcza.
a) do odzyskanej po skasowanych rekordach przestrzeni
b) zapis rekordu głównego / nagłówka / pliku LOG (w sensie transakcyjnym) / indeksów

Był kiedyś w kręgu Debiana poradnik, jak przydzielać fizyczne dyski / mount pointy. W szczególności dla baz danych, inny dysk na dane (w praktyce: dane główne + indeksy), inny na Log transakcyjny (a jeszcze inny /var, gdzie są /var/log, ale to zupełnie inny sens słowa Log)

Inne miejsce, gdzie paluchami można dotknąć tematu, to wyjęty z pudełka MySQL jest dość słabo zestrojony. Jest oficjalny i wiele niezaleznych poradników, jak to nastrajać, w tym np cache zapisu (jest pewne ryzyko, ale może się opłacać)

Dyski pólprzewodnikowe nie lubią np być zapisywane w jedno miejsce, a reszta mało używana., przyśpiesza to ich starzenie / zużycie. Dla celów serwerowych są specjalne wersje dysków, a i nowsze kontrolery macierzowe "coś tam" mają w tym temacie, nie zagłębiałem się. "Podobno" kontroler macierzowy starego typu do mechanicznych dysków szybciej zużyje dyski pólprzewodnikowe niż dedykowany. Wiedza typu "widziałem przez ramię kolegi"

Podobno w/w pomysł z Debiana ma mniejszy sens na płycie głownej HDD dawniej / SATA amatorskiej a serwerowej. Rdziennie serwerowa płyta / kontroler ma podobno dopiero dobrze zrównoleglac takie operacje, amatorskie że tylko trochę

Duzo zalezy od tego

Kofcio napisał(a):

Pytanie: jeśli dysk ma służyć pod bazę danych (relacyjną) to większe znaczenie ma odczyt sekwencyjny czy losowy?

Duzo zalezy od tego co taka baza bedzie robic. Jesli sa pojedyncze zapytania po w miare losowym id to jakby nie kombinowac dostep bedzie losowy. Ale jesli np. przetwarzana jest cala tabela (np. w ML duzo bardziej typowe niz odczytywanie pojedynczych wierszy) to predkosc dostepu sekwencyjnego ma ogromne znaczenie. Programisci baz danych doskonale zdaja sobie sprawe z roznicy w predkosci miedzy dostepem sekwencyjnym i losowym i przy implementacji baz danych (oczywiscie nie mam pojecia czy kazdej) niektore algorytmy beda przetwarzac duzo wiecej danych niz powinny tylko po to zeby zapewnic sekwencyjny dostep do dysku.

Moje wątpliwości wynikają z tego, że raz dane zapisuję do jednej tabeli a raz do drugiej i mam wątpliwość czy jak będę wydobywał dane z jednej tabeli to czy te dane będą pobierane jeszcze sekwencyjnie czy już bardziej losowo?

Znow - zalezy. Jesli duze ilosci danych beda zapisywane w transakcji to z duzym prawdopodobienstwem z punktu widzenia dysku zapis bedzie w miare sekwencyjny, nawet jesli pojedyncze inserty nie beda do tej samej tabeli po kolei. Jesli nie bedzie transakcji to wtedy trzeba zagwarantowac ze zostanie zapisane (tyle ze podobno hardware czesto klamie twierdzac ze flush sie udal - sam nie weryfikowalem i to informacje sprzed lat - moze cos sie zmienilo) i wydaje mi sie ze widzialem w opisie ktorejs bazy danych (to jakas zabawka byla, moze H2 albo cos podobnego) ze w zwiazku z tym i tak te rzekome gwarancje sa olewane po stronie software, wiec to otwiera mozliwosci optymalizacji zapisu. Ale nawet jesli jest zapisywane losowo, to pozniej baza danych moze sobie poukladac dane tak zeby byly blisko siebie.

Ale nawet jesli jest zapisywane losowo, to pozniej baza danych moze sobie poukladac dane tak zeby byly blisko siebie.

Sugerujesz, że baza danych operuje tak niskopoziomowo, że zagląda w ułożenie bloków na dysku? Nie wierzę. Potrzebne dowody. Musiałaby działać jako root. A inaczej takie układanie nie ma sensu.

Jesli duze ilosci danych beda zapisywane w transakcji to z duzym prawdopodobienstwem z punktu widzenia dysku zapis bedzie w miare sekwencyjny, nawet jesli pojedyncze inserty nie beda do tej samej tabeli po kolei.

Takie zapisy musiałyby iść w gigabajty i być głównym sposobem użytkowania dysku, żeby to realnie odczuć.

dzek69 napisał(a):

Ale nawet jesli jest zapisywane losowo, to pozniej baza danych moze sobie poukladac dane tak zeby byly blisko siebie.

Sugerujesz, że baza danych operuje tak niskopoziomowo, że zagląda w ułożenie bloków na dysku? Nie wierzę. Potrzebne dowody. Musiałaby działać jako root. A inaczej takie układanie nie ma sensu.

Coś z tego było na rzeczy, w l. 199x-200x, ale to by zakres innych ludzi, Informix albo Oracle miało koncepcje Raw File
Taki raw file (mozna przypuszczać) byl pierwszy a pewnie jedynym plikiem na swojej partycjki

Mgliste wspomnienia i domnienanie, ale coś z tego było.

dzek69 napisał(a):

Ale nawet jesli jest zapisywane losowo, to pozniej baza danych moze sobie poukladac dane tak zeby byly blisko siebie.

Sugerujesz, że baza danych operuje tak niskopoziomowo, że zagląda w ułożenie bloków na dysku? Nie wierzę. Potrzebne dowody. Musiałaby działać jako root. A inaczej takie układanie nie ma sensu.

Oracle ma możliwość przeznaczenia osobnej partycji na bazę danych właśnie z tego powodu.

Ale nawet osobna partycja nie jest potrzebna aby do pewnego stopnia kontrolować sekwencyjność zapisu. Wszelkie bazy oparte o drzewa LSM buforują dane w pamięci i zapisują na dysk sekwencyjnie, dużymi plikami (po setki MB na raz), niezależnie od tego jak losowe są same zapisy trafiające z aplikacji do bazy.

dzek69 napisał(a):

Ale nawet jesli jest zapisywane losowo, to pozniej baza danych moze sobie poukladac dane tak zeby byly blisko siebie.

Sugerujesz, że baza danych operuje tak niskopoziomowo, że zagląda w ułożenie bloków na dysku? Nie wierzę. Potrzebne dowody. Musiałaby działać jako root. A inaczej takie układanie nie ma sensu.

Nawet zapominajac o mozliwosci dostepu bezposrednio do dysku z pominieciem filesystemu, to takie podejscie w praktyce mocno przyspiesza - patrz np. VACUUM w SQLite. Zapewne na mocno pofragmentowanym dysku przyspieszy troche mniej, ale rozmiar wiersza w typowej tabeli jest mniejszy niz typowy rozmiar bloku filesystemu, wiec ukladanie obok siebie danych ktore z duzym prawdopodobienstwem beda czytane razem jak najbardziej ma sens.

Jesli duze ilosci danych beda zapisywane w transakcji to z duzym prawdopodobienstwem z punktu widzenia dysku zapis bedzie w miare sekwencyjny, nawet jesli pojedyncze inserty nie beda do tej samej tabeli po kolei.

Takie zapisy musiałyby iść w gigabajty i być głównym sposobem użytkowania dysku, żeby to realnie odczuć.

Gigabyte to nie sa bardzo ogromne dane, ale na nieco mniejszych tez mozna calkiem skutecznie zabic wydajnosc jesli programista bazy danych zignoruje fakt ze dostep losowy jest wyraznie wolniejszy niz sekwencyjny. Ale sam dostep do dysku to nie wszytko. Zwykle operacje CPU moga bardzo wyraznie spowolnic. Np. w SQLite wystarczy zdefiniowac SQLITE_OMIT_QUICKBALANCE zeby skutecznie spowolnic zapisywanie (przyklad nie idealny, bo przy balansowaniu dostep do dysku tez bedzie jesli danych nie ma w cache).

Zapewne na mocno pofragmentowanym dysku przyspieszy troche mniej

Proszę o sprostowanie jeśli się mylę, ale w kontekście dysków SSD (gdzie nie ma talerzy, głowic ani żadnych elementów mechanicznych) nie ma żadnego znaczenia, czy dysk jest zdefragmentowany, gdyż bo ponieważ czas dostępu jest identyczny dla każdego sektora i wynosi z grubsza 0ms.

@Kofcio, przede wszystkim to trzeba się zastanowić nad rzeczami podstawowymi:

1. Jak się ma liczba danych do ilości pamięci jaką posiadasz? Dostęp do danych na dysku jest znacznie wolniejszy niż do RAM, więc idealna to sytuacja "write once, read many". Baza jeśli to możliwe, powinna działać na danych w cache, a nie na dysku.
2. Jaki jest przewidywany schemat działania tej bazy? Dużo zapisów, mało odczytów; mało zapisów, wiele odczytów; bardzo dużo zapisów, sporadyczny odczyt dużej ilości danych, ...?
3. Ilu ma być równoczesnych użytkowników tej bazy? Przy znaczącej liczbie użytkowników każda operacja I/O staje się losową (z punktu widzenia dysku), bo w końcu trzeba kogoś wywłaszczyć, żeby dać dostęp do danych innym sesjom.
4. RAID jak najbardziej przyspieszy pewne operacje, jeśli zastosujesz przeplot danych między dyskami. Natomiast główną rolą jest zabezpieczenie danych, których utrata może być katastrofą dla ich posiadacza (byłego posiadacza ;)).

Ogólnie rzecz biorąc, na wydajność bazy największy wpływ ma jej design i parametry konfiguracyjne, bo jak wspomniałem operacje mają być wykonywane w pamięci, a nie ciągle na dysku. Wiadomo, że pojedyncze operacje łączące duże zbiory danych mogą się nie mieścić w pamięci, ale chodzi o to, żeby jak najwięcej ich tam wcisnąć.

A i jeszcze jedno - wszystkie założenia trafi szlag, jak codziennie będziesz wyłączał tę bazę. ;) To ma działać ciągle, bo jedynie wtedy masz uzysk z operacji na danych w cache bazy. Minimalizacja liczby restartów to podstawa wydajnie funkcjonującej bazy.

@cerrato: Z grubsza to słowo klucz, bo o ile w porównaniu do hdd to prawda, to w praktyce te czasy się kumulują i są różnice, np.system zainstalowany na intel optane, który ma kilkukrotnie mniejsze czasy odpowiedzi niż tradycyjne ssd jest widocznie bardziej responsywny. Level1techs na jutubie mieli filmik o tym, ale nie pamiętam teraz który to. Poza tym więcej fragmentów to więcej metadanych do przetworzenia przez system. Tu ciekawy artykuł https://www.hanselman.com/blog/the-real-and-complete-story-does-windows-defragment-your-ssd