Wprowadzanie transakcji Zaloguj się na osobnej objętości [półprzewodnikowej]?


12

Dzienniki transakcji są często izolowane na osobnym woluminie. Uzasadnieniem tej praktyki, jak rozumiem, jest to, że dane dziennika transakcji są zapisywane sekwencyjnie - a dyski twarde mogą wykonywać operacje zapisu z dużo większą szybkością sekwencyjnie, a nie losowo. Wynika to z małej igły wewnątrz napędu, która musi przechodzić znacznie krótszą odległość podczas zapisywania kolejnych bloków danych, w przeciwieństwie do zapisu losowego.

(Przepraszam za naiwną interpretację. Próbuję zrozumieć sens tego, co przeczytałem.)

Mając to na uwadze ... Przyszło mi do głowy, że dyski półprzewodnikowe nie mają w sobie małych igieł, półmisków i innych przedmiotów. Jeśli zarówno moja baza danych, jak i dziennik transakcji znajdują się na jednej macierzy RAID 5 z ośmiu dysków półprzewodnikowych, czy naprawdę jest coś pozytywnego w przeniesieniu dziennika transakcji na osobny wolumin? Jeśli domniemany wzrost wydajności opiera się na założeniu, że sekwencyjne zapisy zmniejszają odległość, którą poruszają się igły i wirują talerze, a napęd półprzewodnikowy nie ma żadnej z tych ruchomych części, co zyskuję, izolując dziennik?


Nadal masz do rozważenia autobusy i bufory. Trzymałbym je osobno z powodu różnic we / wy wzorca. Jeśli Twoje aplikacje nie są zbyt transakcyjne, prawdopodobnie nie znasz różnicy, jeśli problemem jest koszt.
Eric Higgins,

Kiedy używasz terminu „magistrala” ... czy odnosisz się do ścieżki danych z płyty głównej do karty RAID?
Chad Decker,

2
„czy naprawdę jest jakaś korzyść z przeniesienia dziennika transakcji na osobny wolumin?” prawie na pewno nie, ale naprawdę jest przyspieszenie do przeniesienia całej macierzy do RAID10 i zwiększenie niezawodności do nadmiernej alokacji (tj. niepełnego partycjonowania) dysków SSD
mówi Jack, spróbuj wypróbować topanswers.xyz 25'12

Odpowiedzi:


10

Krótka odpowiedź, skorzystaj z pojedynczej tablicy, nie jest prawdopodobne zwiększenie wydajności oddzielania dzienników od danych na 8 dyskach SSD. Zobacz SQL na dyskach SSD: Hot and Crazy Love, aby uzyskać bardziej szczegółowy (i zabawny) komentarz na dyskach SSD. Zwróć szczególną uwagę na uwagi na temat skorelowanych awarii dysków SSD.

Oddzielanie dzienników od danych na dyskach SSD jest bardziej RPO (celem punktu odzyskiwania) niż problemem z wydajnością. Chodzi o to, że można zmniejszyć RPO, oddzielając dzienniki od danych, tak że w przypadku awarii tablicy danych tablica dziennika powinna / powinna pozostać dostępna. Ostrożny rozważyłby inną markę / model napędu w każdej z dwóch tablic, aby złagodzić skorelowany problem awarii, jeśli RPO był krytyczny.

Komentarze dotyczące przepustowości magistrali są nieistotne. Jeśli musisz zmienić tak dużo IO, masz większe problemy do zmartwienia.


-4

Istnieje grupa, która zgadza się, że na HDD korzystne byłoby oddzielenie, nadal twierdzą, że w przypadku dysków SSD nie jest to już potrzebne.

Więc dla nich chcę zapytać: „jeśli nie ma problemu ze sporem, to dlaczego RAID 10? Nie ma już potrzeby usuwania! Tak więc samo lustro wystarczyłoby, i oczywiście nie ma potrzeby 8 dysków, 2x bazy danych rozmiar powinien wystarczyć! ".

Jednak rzeczywistość jest taka, że ​​jeśli coś potrzebuje RAID 10, jest to plik dziennika!

Nie dzieje się tak tylko z powodu problemu sekwencyjnego vs losowego (patrz zasoby poniżej), ale w rzeczywistości jest bardzo ważne, gdy zrozumiesz, jak działają dyski SSD.

Krótko mówiąc (dłuższy opis można znaleźć na stronie http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), dysk SSD jest bardzo skuteczny w odczytywaniu i zapisywaniu zer, jednak w przypadku zapisywania zer nie jest tak wydajny, ponieważ musi skasować całą sekcję, aby zapisać nawet jeden!

Chociaż nie jest to problem w przypadku ogólnych zapisów, ponieważ i tak są one buforowane w pamięci i zapisywane w granicach stron, jest to poważny problem dla pliku dziennika, ponieważ plik dziennika omija cache i zamiast tego blokuje serwer SQL, dopóki logi zapisywane są na dysk !, co oznacza, że ​​przy każdym zapisie prawdopodobnie nastąpi pełne kasowanie sekcji.

Dlatego, aby go zoptymalizować, proponuję poświęcić każdy dodatkowy dysk (oprócz 2x rozmiaru bazy danych, nie trzeba go usuwać!) Dla pliku dziennika, w ten sposób będzie mógł przetworzyć jak najwięcej w krótszym czasie.

STARSZA ODPOWIEDŹ

Odpowiedź brzmi tak, z trzech powodów. 1) Random vs Sequential - Chociaż jest oczywiste, że SSD dramatycznie zwiększyło wydajność losowych zapisów, nadal pozostaje kwestia random vs sekwencyjna, co można zobaczyć z następujących białych list i linków:

2) Niezawodność - istnieje duża szansa, że ​​wszystkie dyski SSD ulegną awarii jednocześnie, w którym to przypadku RAID nie stanowi ochrony, jednak ponieważ dysk SSD używany wyłącznie do pracy sekwencyjnej ma inną żywotność, może to być twój ratownik

3) Zapisywanie niezgodności - Przyczyną umieszczania logów na własnym wrzecionie jest nie tylko przypadkowa vs sekwencyjna, ale także z powodu niezgodności zapisu, jak widać z faktu, że zaleca się również tempdb na osobnym woluminie, który wskazuje że tutaj chodzi również o zapisywanie niezgody.

I to powinno mieć zastosowanie jeszcze bardziej do pliku dziennika, ponieważ zapisuje w blokach dziennika transakcje od uznania za zatwierdzone, dopóki nie zostaną zapisane na powierzchni dysku.

W rzeczywistości w przypadku dzienników można użyć zwykłych dysków HDD jako białej księgi firmy Dell pod adresem http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf

EDYTOWAĆ

Microsoft zaleca umieszczanie tempdb na własnej tablicy dla wirujących dysków, patrz

i wiele innych i jest to ogólnie przyjęte pojęcie w Sql Server, podczas gdy nikt nie wyraził problemu z podziałem tablicy.

Co więcej, zespół SQL Server opracował koncepcje partycjonowania grup plików i partioiningu, mając na celu wyłącznie przeniesienie ich do osobnej tablicy.

W rzeczywistości MSDN pod adresem http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) zaleca zwiększenie wydajności oddzielenia indeksu nieklastrowanego na jego własnej tablicy (chociaż nie należy tego traktować jako ogólnej porady w każdej sytuacji, tylko w przypadku określonych obciążeń, więcej informacji na http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).

Jako takie jest tylko logicznym rozszerzeniem, aby powiedzieć, że przyczyna separacji na obracających się dyskach jest nie tylko związana z kwestią odczytu sekwencyjnego i losowego, ale z ogólną sprzecznością zapisu, co dotyczy również dysków SSD.

Chociaż może się zdarzyć, że niektórzy ludzie nie zgadzają się z tą radą i uważają, że nie ma korzyści z umieszczenia tempdb i własnego wolumenu (jako Jack Douglas), a nawet można twierdzić, że oddzielenie plików dziennika (jako Mark Storey) -Smith) i zamiast tego twierdzić, że dzielenie tablicy jest znacznie gorsze, wciąż nie zapominaj, że jest to nowe podejście sprzeczne z ogólnie przyjętym podejściem sugerowanym przez Microsoft i społeczność, a jak dotąd nikt nie podał linków do żadnego testy porównawcze, aby to wesprzeć.

Więc moje słowo do wszystkich downvoters brzmi: uważam, że bardzo nieetyczne jest głosowanie za postem tylko dlatego, że ma on inne zdanie niż twoje, zwłaszcza gdy 1) twoja opinia jest sprzeczna z ogólnie przyjętą teorią 2) i jest przeciwko sprzedawcom (Microsoft ) własna dokumentacja 3) i nie przedstawiłeś żadnego dowodu tylko opinię.

Ale w tym przypadku jest to jeszcze bardziej śmieszne, ponieważ mój post jest niczym innym jak logicznym rozszerzeniem tej teorii, więc osoba, która uważa ten post za poradę do łóżka, musi oczywiście wrócić do wszystkich postów, które zalecają tę teorię i zanotować je .

Powiedz, że ktoś decyduje, że RAID jest teorią starej szkoły, i zanegował wszystkie posty, które ją zalecają. Jak to ma sens?


Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
Paul White 9
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.