B-Tree проти хеш-таблиці

У MySQL тип індексу - це b-дерево, а доступ до елемента в b-дереві відбувається за логарифмічним амортизованим часом O(log(n)).

З іншого боку, доступ до елемента в хеш-таблиці є в O(1).

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

Ви можете отримати доступ до елементів лише за їх первинним ключем у хеш-таблиці. Це швидше, ніж з алгоритмом дерева ( O(1)замістьlog(n) ), але ви не можете вибрати діапазони ( все між xіy ). Дерево алгоритми підтримують це, Log(n)тоді як хеш-індекси можуть призвести до повного сканування таблиці O(n). Крім того, постійні накладні витрати на хеш-індекси зазвичай більші ( що не є фактором у позначенні тета, але воно все ще існує ). Крім того, алгоритми дерев, як правило, простіші в обслуговуванні, зростають разом із даними, масштабом тощо.

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

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

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

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

Його називають РАШ - R eplication U NDER S calable Н озоления, і ці алгоритми, таким чином , називають алгоритми Раша.

Однак може існувати момент, коли ваш індекс перевищує допустимий розмір порівняно з вашими розмірами хешу, і весь ваш індекс потрібно переробити. Зазвичай це не проблема, але для величезних-величезних-величезних баз даних це може зайняти дні.

Компроміс для алгоритмів дерева невеликий, і вони підходять майже для кожного випадку використання, тому є типовими.

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

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

Різниця між використанням b-дерева та хеш-таблиці полягає в тому, що перший дозволяє використовувати порівняння стовпців у виразах, що використовують оператори =,>,> =, <, <= або BETWEEN, тоді як останній використовується лише для порівняння рівності, що використовують оператори = або <=>.

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

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

Pick DB / OS базувався на хешуванні та працював добре. Наразі більше пам’яті для підтримки ефективних розріджених хеш-таблиць та надлишкового хешування для підтримки запитів щодо помірного діапазону, я б сказав, що хешування все-таки може мати своє місце (деякі воліють мати інші форми відповідності схожості, не пов’язані з діапазоном, такі як підстановні символи та регулярні вирази ). Ми також рекомендуємо копіювати, щоб ланцюги зіткнень залишалися суміжними, коли ієрархії пам’яті мають великі різниці швидкості.