Чи стануть B-дерева та інші структури даних застарілими з появою твердотільних дисків?

Сьогодні багато (можливо, більшість?) Баз даних використовують B-Дерева та варіанти для зберігання даних, оскільки ця структура даних оптимізує операції зчитування, запису та пошуку на жорсткому диску (а ці операції, в свою чергу, відіграють важливу роль у загальній ефективності роботи бази даних).

Чи повинні твердотілі накопичувачі (SSD) повністю витіснити традиційні жорсткі диски (жорсткі диски), але чи можна сказати, що B-Дерева та варіанти стануть застарілими, що дає можливість структурам даних, які ефективніше працюють на пам'яті прямого доступу? Якщо так, то якими будуть ці структури? (наприклад, хеш-таблиці, дерева AVL)

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

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

У будь-якому випадку, навіть якщо ваші бази даних зберігаються на SSD, це все-таки блок пам'яті, орієнтований на блок, і все-таки є перевагою використання B-Trees та інших дерев багатоповерхівок.

АЛЕ близько десяти років тому були винайдені кешовані алгоритми та структури даних. Вони не звертають уваги на розмір та структуру кешів тощо - вони дозволяють (асимптотично) найкращим чином використовувати будь-яку герархію пам'яті. Дерева B повинні бути "налаштовані" на певну спадщину пам'яті, щоб найкраще використовувати (хоча вони працюють досить добре для досить широкого кола варіацій).

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

Макет Ван Емде Боаса дуже важливий у структурах даних, що не захищені кешем.

Курс алгоритмів алгоритмів MIT OpenCourseware включає деяке висвітлення структури керованих даних із кешу.

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

1. Перемістіть голову в потрібне місце на диску (~ 10 мс).
2. Зачекайте, коли диск обернеться (при 10 к / хв, це означає 167 обертів в секунду, але в середньому ми чекаємо лише половини обертання, тому ~ 3 мс).
3. Прочитайте блок (~ 3 мс).
4. Змінити в оперативній пам'яті. (~ 10нс)
5. Знову перемістіть голову в потрібне місце на диску (~ знову 10 мс).
6. Зачекайте, поки диск знову обернеться (~ 3ms знову).
7. Запишіть блок (~ 3ms).

Це 10 + 3 + 3 + 10 + 3 + 3 = 34 мс

В середньому, те ж саме на SSD - це лише 1 мс, незалежно від положення на диску.

А оскільки хештел набагато швидший, ми можемо подумати, що хештел стане кращою заміною.

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

Побачити:

1. http://en.wikipedia.org/wiki/Van_Emde_Boas_tree
2. http://bryanpendleton.blogspot.com/2009/06/cache-oblivious-data-structures.html

Чому важливо знайти наступне та попереднє? Уявіть, що для отримання всіх елементів, більших за х та менших, ніж z, вам потрібно використовувати індекси з пошуку попереднього та пошуку наступного.

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

Тому я б сказав, що це проблема відкритого типу.