Czy koncepcja klastrowanego indeksu w projekcie DB ma sens w przypadku korzystania z dysków SSD?

Czy podczas projektowania schematu danych serwera SQL i kolejnych zapytań, sprocków, widoków itp. Pojęcie indeks klastrowy i kolejność danych na dysku ma sens w przypadku projektów DB jawnie wdrażanych na platformach SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
„Indeks klastrowy określa fizyczną kolejność danych w tabeli”.

Na fizycznej platformie dyskowej projekt, aby je uwzględnić, ma dla mnie sens, ponieważ fizyczny skan danych w celu pobrania „sekwencyjnych” wierszy może być bardziej wydajny niż wyszukiwanie w tabeli.
Na platformie SSD wszystkie prawa do odczytu danych korzystają z identycznego wyszukiwania. Nie ma pojęcia „porządku fizycznego”, a odczyty danych nie są „sekwencyjne” w tym sensie, że bity są przechowywane na tym samym kawałku krzemu.

Czy w procesie projektowania bazy danych aplikacji uwzględnienie indeksu klastrowego ma znaczenie dla tej platformy?

Początkowo sądzę, że nie dlatego, że idea „uporządkowanych danych” nie dotyczy przechowywania dysków SSD i optymalizacji przeszukiwania / odzyskiwania danych.

EDIT: Wiem, że SQL Server będą tworzyć jedną, ja tylko filozofowania na temat tego, czy ma to sens, aby myśleć o tym podczas projektowania / optymalizacji.

Zadaj sobie kolejne pytanie: Jeśli cała baza danych znajduje się w pamięci i nigdy nie muszę dotykać dysku, czy chcę przechowywać moje dane w uporządkowanym drzewie B, czy też chcę przechowywać dane na nieuporządkowanym stosie?

Odpowiedź na to pytanie zależy od wzorca dostępu. W większości przypadków dostęp wymaga wyszukiwania w jednym wierszu (tj. Wyszukiwania) i skanowania zakresu. Te wzorce dostępu wymagają B-drzewa, w przeciwnym razie są nieefektywne. Niektóre inne wzorce dostępu, wspólne w DW i OLAP, zawsze wykonują agregacje w całej tabeli od końca do końca i nie korzystają ze skanów zakresu. Podczas drążenia kolejnych prac ujawniają się inne wymagania, takie jak szybkość wstawiania i alokacji do sterty w porównaniu z B-drzewem, które mogą odgrywać rolę w przypadku dużych zadań przesyłania ETL. Ale w większości przypadków odpowiedź sprowadza się do jednego pytania: czy poszukujesz czy skanujesz zakres? Przytłaczająca liczba odpowiedzi brzmi TAK. Dlatego przytłaczająca liczba przypadków, w których projekt wymaga indeksu klastrowego.

Innymi słowy: tylko dlatego, że tanie jest odczytanie go z dysku w losowej kolejności, nie oznacza, że ​​możesz niszczyć swoje TLB i linie L2 w bonanzie skanowania pamięci RAM 64 GB ...

W przypadku korzystania z dobrze wybranego indeksu klastrowego istnieje większe prawdopodobieństwo, że wszystkie powiązane dane będą potrzebne na mniejszej liczbie stron danych. Oznacza to, że możesz przechowywać potrzebne dane w mniejszej ilości pamięci. Daje to korzyść niezależnie od tego, czy korzystasz z wirujących dysków, czy SSD.

Ale masz rację, że inna korzyść z indeksu klastrowego - sekwencyjne odczytywanie / zapisywanie powiązanych danych zamiast wielu operacji na dysku - nie jest znaczącą korzyścią dla dysków SSD, w których próby nie są tak dużym obciążeniem wydajnościowym, ponieważ są z wirującymi dyskami.

Re komentarz Mateusza PK.

Oczywiście lokalizacja A w pamięci RAM jest równie szybka jak lokalizacja B w pamięci RAM. Nie o to chodzi. Mówię o przypadku, gdy wszystkie potrzebne dane nie zmieszczą się w pamięci RAM, jeśli dane są rozproszone na wielu stronach. Każda podana strona może zawierać tylko niewielką ilość danych, którymi jesteś zainteresowany. RDBMS musi więc nadal ładować i czyścić strony podczas uzyskiwania dostępu do A, B i innych wierszy. Tam dostajesz karę za wydajność.

Byłoby lepiej, gdyby każda strona była pełna danych, którymi jesteś zainteresowany, w nadziei, że wszystkie kolejne żądania wierszy będą obsługiwane ze stron w pamięci RAM. Korzystanie z indeksu klastrowego to dobry sposób na zgrupowanie danych na mniejszej liczbie stron.

Tak, to absolutnie ma sens. W swoim podejściu myślisz o zbyt niskim poziomie. SQL Server (w bardzo bardzo uproszczonej wyjaśnienia) przechowuje dane skupione w architekturze B-drzewa. Umożliwia to szybkie wyszukiwanie danych na podstawie wartości klucza indeksu klastrowanego.

Sterta (bez indeksu klastrowego) nie ma kolejności danych. Najważniejszą rzeczą do rozważenia w tym przypadku jest to, że strony danych nie są połączone na połączonej liście .

Tak więc odpowiedź brzmi tak, nadal sensowne jest tworzenie indeksów klastrowych w tabelach, nawet na dysku SSD. Wszystko opiera się na tym, ile danych musi przesiać SQL Server, aby uzyskać dostęp do danych wynikowych. Dzięki wyszukiwaniu indeksu klastrowego jest ono minimalizowane.

Odniesienie: http://msdn.microsoft.com/en-us/library/ms189051.aspx