Чувствительна ли концепция кластерного индекса в структуре БД при использовании твердотельных накопителей?

При разработке схемы данных сервера SQL и последующих запросов, sprocs, представлений и т. Д. Имеет ли смысл учитывать понятие кластеризованного индекса и порядка данных на диске для конструкций БД, созданных явно для развертывания на платформах SSD?

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

На платформе с физическими дисками для меня имеет смысл учитывать их, так как физическое сканирование данных для извлечения «последовательных» строк может быть более производительным, чем поиск по таблице.
На платформе SSD весь доступ для чтения данных использует одинаковый поиск. Не существует понятия «физического порядка», и чтение данных не является «последовательным» в том смысле, что биты хранятся на одном и том же куске кремния.

Итак, в процессе разработки базы данных приложения рассмотрение кластерного индекса имеет отношение к этой платформе?

Первоначально я думал, что это не потому, что идея «упорядоченных данных» не относится к хранению SSD и оптимизации поиска / восстановления.

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

Задайте себе другой вопрос: если вся база данных находится в памяти, и мне никогда не нужно прикасаться к диску, хочу ли я хранить свои данные в упорядоченном B-дереве или я хочу сохранить свои данные в неупорядоченной куче?

Ответ на этот вопрос будет зависеть от вашей схемы доступа. В большинстве случаев ваш доступ требует поиска в одной строке (т.е. поиска) и сканирования диапазона. Эти шаблоны доступа требуют B-дерева, иначе они неэффективны. Некоторые другие шаблоны доступа, распространенные в DW и OLAP, всегда выполняют агрегации по всей таблице, и они не получают выгоды от сканирования диапазона. По мере дальнейшего изучения выявляются другие требования, например, скорость вставки и выделения в кучу по сравнению с B-Tree может сыграть роль для огромных заданий передачи ETL. Но в большинстве случаев ответ на самом деле сводится к одному вопросу: вы ищете или сканирование диапазона? Подавляющее количество раз ответ - ДА. И, следовательно, подавляющее число раз, когда дизайн требует кластеризованного индекса.

Другими словами: только потому, что считывание данных с диска в случайном порядке обходится дешево, не означает, что вы можете испачкать свои TLB и линии L2 в объеме сканирования ОЗУ 64 ГБ ...

Если вы используете правильно подобранный кластерный индекс, вы с большей вероятностью получите все необходимые данные на меньшем количестве страниц данных. То есть вы можете хранить нужные данные в меньшем объеме памяти. Это дает преимущество независимо от того, используете ли вы вращающиеся диски или SSD.

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

Re @Matthew PK комментарий.

Конечно, местоположение A в RAM так же быстро, как и местоположение B в RAM. Не в этом дело. Я говорю о случае, когда все данные, которые вам нужны, не помещаются в ОЗУ, если данные разбросаны по многим страницам. Любая данная страница может содержать только небольшой объем данных, которые вас интересуют. Поэтому СУБД должна продолжать загружать и очищать страницы при доступе к A, B и другим строкам. Вот где вы получаете штраф за производительность.

Было бы лучше, если бы каждая страница была заполнена данными, которые вас интересуют, в надежде, что все последующие запросы строк поступают со страниц в ОЗУ. Использование кластерного индекса - это хороший способ убедиться, что ваши данные сгруппированы на меньшем количестве страниц.

Да, это все еще имеет смысл. Вы думаете, слишком низкий уровень в вашем подходе. SQL Server (в очень очень упрощенном объяснении) хранит кластерные данные в архитектуре B-дерева. Это позволяет быстро получать данные на основе значений ключа кластеризованного индекса.

Куча (без кластеризованного индекса) не имеет последовательного порядка данных. Здесь важно учитывать, что в куче страницы данных не связаны в связанном списке .

Таким образом, ответ - да, все же имеет смысл создавать кластерные индексы для таблиц, даже на SSD. Все зависит от того, сколько данных SQL Server должен просеять, чтобы получить полученные данные. При поиске в кластеризованном индексе оно сводится к минимуму.

Ссылка: http://msdn.microsoft.com/en-us/library/ms189051.aspx