Чи розумне поняття кластерного індексу в дизайні БД під час використання SSD?

При розробці схеми даних SQL-сервера та подальших запитів, проростків, представлень тощо має значення поняття кластеризованого індексу та порядку даних на диску розглянути для конструкцій БД, явно розміщених на платформах SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Кластерний індекс визначає фізичний порядок даних у таблиці."

На платформі фізичного диска дизайн для їх розгляду має сенс, оскільки фізичне сканування даних для отримання "послідовних" рядків може бути більш ефективним, ніж пошук через таблицю.
На платформі SSD весь доступ для зчитування даних використовує ідентичний пошук. Не існує поняття "фізичний порядок", і зчитування даних не є "послідовним" в тому сенсі, що біти зберігаються в одному шматочку кремнію.

Отже, у процесі розробки бази даних додатків кластерний розгляд індексу має відношення до цієї платформи?

Моя початкова думка полягає в тому, що це не тому, що ідея "впорядкованих даних" не поширюється на накопичувачі SSD і шукає / оптимізує повторне звернення.

EDIT: Я знаю , що SQL Server буде створити, я просто філософствують про те, чи має сенс думати про це під час проектування / оптимізації.

Задайте собі інше запитання: Якщо вся база даних знаходиться в пам'яті, і мені ніколи не потрібно торкатися до диска, чи потрібно зберігати свої дані в упорядкованому B-дереві чи я хочу зберігати свої дані в невпорядкованій купі?

Відповідь на це питання залежатиме від вашої схеми доступу. У більшості випадків ваш доступ потребує пошуку в одному ряду (тобто пошуку) та сканування діапазону. Для цих моделей доступу потрібне дерево дерева, інакше вони неефективні. Деякі інші шаблони доступу, поширені в DW та OLAP, завжди роблять агрегати по всій таблиці завжди від кінця до кінця, і вони не приносять користі від сканування діапазону. По мірі розгортання з'являються інші вимоги, наприклад, швидкість вставки та розподілу в купу проти B-Tree може зіграти роль для величезних завдань з передачі ETL. Але в більшості випадків відповідь дійсно зводиться до одного питання: ви шукаєте чи скануєте діапазон? Переважна кількість разів відповідь ТАК. І тому переважна кількість разів дизайн вимагає кластерного індексу.

Іншими словами: тільки тому, що їх читати з диска у випадковому порядку не випливає, це не означає, що ви можете смітити ваші TLB та L2-рядки в bonanza сканування оперативної пам'яті 64 Гб ...

Якщо ви використовуєте правильно обраний кластерний індекс, ви більше шансів отримати всі необхідні вам дані за меншою кількістю сторінок даних. Тобто ви можете зберігати потрібні вам дані в меншій кількості пам'яті. Це дає перевагу незалежно від того, використовуєте ви спінінг або SSD.

Але ви правильні, що інша перевага кластерного індексу - читання / запис пов’язаних даних послідовно, а не з багатьма дисками - не є суттєвою перевагою для SSD, де прагнення не настільки великі накладні, ніж вони є зі спінінг-дисками.

Коментар Re @Matthew PK

Звичайно, розташування A в оперативній пам'яті так само швидко, як і місце B в оперативній пам'яті. Це не сенс. Я говорю про випадок, коли всі потрібні вам дані не вмістяться в оперативній пам’яті, якщо дані розкидані по багатьох сторінках. Будь-яка дана сторінка може містити лише невелику кількість даних, які вас цікавлять. Отже, RDBMS повинен тримати завантаження та чищення сторінок під час доступу до A, B та інших рядків. Ось де ви отримуєте штрафний показник.

Було б краще, щоб кожна сторінка була заповнена даними, які вас цікавлять, сподіваючись, що всі наступні запити рядків надсилаються зі сторінок оперативної пам'яті. Використання кластерного індексу - хороший спосіб забезпечити групування ваших даних на меншу кількість сторінок.

Так, це абсолютно все-таки має сенс. Ти занадто низький рівень свого підходу. SQL Server (в дуже дуже зберігає спрощене пояснення) кластерний даних в архітектурі B-дерева. Це дозволяє швидко отримати дані на основі кластерних значень ключових індексів.

Купа (без кластерного індексу) не має послідовного порядку даних. Найважливіше, що тут слід врахувати, - це те, що в купі сторінки даних не пов'язані у пов'язаному списку .

Отже, відповідь "так", все ж є сенс мати кластерні індекси, створені на таблицях, навіть на SSD. Все ґрунтується на тому, скільки даних має просіяти SQL Server, щоб дістатись до отриманих даних. При кластерному пошуку індексу він мінімізується.

Довідка: http://msdn.microsoft.com/en-us/library/ms189051.aspx