Будут ли B-деревья и другие структуры данных устаревать с появлением твердотельных накопителей?

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

Должны ли твердотельные накопители (SSD) полностью вытеснять традиционные жесткие диски (HDD), однако можно ли сказать, что B-деревья и их варианты устареют, предоставляя место для структур данных, которые более эффективно работают с памятью прямого доступа? Если так, то какими будут эти структуры? (например, хеш-таблицы, деревья AVL)

database data-structures

— Даниэль Скокко
источник

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

— Пемдас

С точки зрения базы данных.

— Даниэль Скокко

Ответы:

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

Я использую многоканальную древовидную библиотеку в стиле B + в памяти, которую я довольно много написал на C ++. У него могут быть преимущества в производительности - причина, по которой он был изначально написан, заключался в том, чтобы попытаться использовать кеш лучше, - но я должен признать, что часто это не работает. Проблема заключается в компромиссе, который означает, что элементы должны перемещаться внутри узлов при вставках и удалениях, чего не происходит для двоичных деревьев. Кроме того, некоторые из низкоуровневых хакерских кодов, которые я использовал для его оптимизации - ну, они, вероятно, сбивают с толку и побеждают оптимизатора, по правде говоря.

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

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

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

Макет Ван Эмда Боаса очень важен в структурах данных, не обращающих внимания на кэш.

Курс по алгоритмам MIT OpenCourseware включает в себя некоторый охват структур данных, забывающих о кеше.

— Steve314
источник

Интересный. Вы дали несколько хороших указателей (не каламбур!), Чтобы исследовать эту тему дальше. Благодарю.

— Даниэль Скокко

Этот курс MIT также содержит информацию о структурах данных, не обращающих внимания на кэш.

— dan_waterworth

Привет, Вы имели в виду, что B-дерево устареет из-за независящих от кэша структур данных, а не из-за SSD? Но как насчет других структур данных, таких как управление блоками в СУБД?

— Ян Бо

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

— Steve314

Априори, да, большинство механизмов баз данных придется переписывать, так как B-Tree больше не будет самой эффективной структурой данных для хранения данных, учитывая, что локальность важна для жесткого диска, где диск перемещается медленно и данные извлекаются в блоках, что означает, что любое изменение данных должно:

Переместите головку в нужное место на диске (~ 10 мс).
Дождитесь вращения диска (при 10k об / мин, это означает 167 оборотов в секунду, но в среднем мы ждем только половину оборота, поэтому ~ 3 мс).
Читать блок (~ 3 мс).
Изменить в оперативной памяти. (~ 10ns)
Снова переместите головку в нужное место на диске (снова ~ 10 мс).
Подождите, пока диск снова вращается (снова ~ 3 мс).
Запишите блок (~ 3 мс).

Это 10 + 3 + 3 + 10 + 3 + 3 = 34 мс

В среднем выполнение одного и того же на SSD составляет всего 1 мс, независимо от положения на диске.

А поскольку хеш-таблица намного быстрее, мы могли бы подумать, что она будет лучшей заменой.

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

Видеть:

Почему важно найти следующее и предыдущее? Представьте, что вы получаете все элементы больше x и меньше z, вам нужно использовать индексы с find previous и find next.

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

Так что я бы сказал, что это проблема открытого типа.

— Вильгельм Ван Энде Боас
источник

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

— Steve314

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

— Steve314