Является ли концепция кластерного индекса в дизайне базы данных чувствительной при использовании SSD?

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

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

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

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

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

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

41 голос | спросил Matthew 28 12011vEurope/Moscow11bEurope/MoscowMon, 28 Nov 2011 23:36:53 +0400 2011, 23:36:53

3 ответа


31

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

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

Другими словами: просто потому, что дешево читать его с диска в случайном порядке, не означает, что вы можете уничтожить ваши TLB и L2 строки в 64Gb RAM scan bonanza ...

ответил Remus Rusanu 29 22011vEurope/Moscow11bEurope/MoscowTue, 29 Nov 2011 00:09:49 +0400 2011, 00:09:49
22

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

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


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

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

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

ответил Bill Karwin 28 12011vEurope/Moscow11bEurope/MoscowMon, 28 Nov 2011 23:42:23 +0400 2011, 23:42:23
12

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

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

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

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

ответил Thomas Stringer 28 12011vEurope/Moscow11bEurope/MoscowMon, 28 Nov 2011 23:43:08 +0400 2011, 23:43:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132