Насколько твердотельные накопители сокращают разрыв в производительности между кластерными и некластеризованными индексами?

Question

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

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

В большинстве ресурсов баз данных, которые я видел в Переполнении стека и в других местах, этот дополнительный поиск на диске рассматривается как существенное снижение производительности. Мой вопрос: как изменится этот анализ, если предположить, что все файлы базы данных хранятся на твердотельном диске (SSD)?

На странице Википедии для твердотельных накопителей время произвольного доступа для твердотельных накопителей составляет менее 0,1 мс, а время произвольного доступа для механических жестких дисков обычно в 10-100 раз медленнее.

Сужают ли твердотельные накопители разрыв между кластеризованными и некластеризованными индексами, так что первые становятся менее важными для общей производительности?

Answer 1

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

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

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

По моему опыту (которому несколько лет), производительность при использовании SSD была сопоставима с базой данных в памяти для большинства операций.

Другое дело, делает ли это кластерные индексы избыточными. Ключевое место, где они используются, - это когда вы хотите отделить связанное небольшое количество строк (скажем, «неосуществленное») от большего количества. Помещая их на одни и те же страницы данных, кластеризованный индекс уменьшает общее количество читаемых строк - он не просто ускоряет чтение.

Answer 2

Прежде всего, кластеризованный индекс не гарантирует, что строки физически хранятся в порядке индекса. Например, InnoDB может хранить кластеризованный индекс непоследовательным образом. То есть две страницы базы данных, содержащие последовательные строки таблицы, могут храниться физически близко друг к другу или далеко друг от друга в табличном пространстве и в любом порядке. Структура данных B-дерева для кластеризованного индекса имеет указатели на конечные страницы, но их не нужно хранить в любом порядке.

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

Номера 2018 года :

• Поиск диска: 3 000 000 нс
• Случайное чтение SSD: 16 000 нс
• Ссылка на основную память: 100 нс

ОЗУ по-прежнему превосходит длительное хранение с большим отрывом. Если ваш набор данных (или, по крайней мере, активный поднабор вашего набора данных) помещается в ОЗУ, вам не нужно беспокоиться о разнице между хранилищем на магнитном диске и накопителем SSD.

---

Ваш комментарий:

Кластерный индекс помогает, потому что, когда поиск первичного ключа просматривает B-дерево и находит листовой узел, сразу же появляются все остальные поля строки, связанные с этим значением первичного ключа.

Сравните с MyISAM, где индекс первичного ключа отделен от строк таблицы. Запрос выполняет поиск в B-дереве индекса первичного ключа и на конечном узле находит указатель на местоположение в файле данных, где хранится соответствующая строка. Поэтому он должен выполнить второй поиск в файле данных.

Это не обязательно означает, что кластерный индекс в InnoDB хранится последовательно. Возможно, потребуется немного пропустить, чтобы прочитать все страницы табличного пространства. Вот почему так полезно иметь страницы в оперативной памяти в пуле буферов.

Answer 3

Просто некоторые предложения (для широкого для простого комментария)

с учетом того, что все зависит от распределения ключей в некластеризованном индексе и в соответствующих узлах (что является полностью причинно-следственной и может оцениваться только в средних терминах), остается тот факт, что любой доступ выигрывает от производительности диска SSD. В этом случае увеличение предлогов не является линейным, но тем не менее является существенным. Следовательно, в среднем он должен быть не в 1–100 раз именно для вопросов, связанных со случайностью распределения, а для всех обстоятельств, в которых это проявляется. доступ в 100 раз быстрее .. в этом случае он тем эффективнее, чем более причинно .. возникает ситуация. Однако в основе лежит факт ... каждое действие на диске гораздо более эффективно, и поэтому в целом поведение некластеризованного индекса становится явным в оптимальном контексте.

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