Потрібен хороший огляд алгоритмів структури даних про оперативні дані


14

(вже запитували на головному сайті , але просимо також тут кращого висвітлення, вибачте)

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

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

Ось такі теми, які мене особливо цікавлять:

  1. Ефективне кодування двійкових дерев з ефективними операціями отримання батька, лівої / правої дитини, кількості елементів у піддереві.

    Основне питання тут полягає в наступному: всі підходи, які я знаю, припускають, що вузли дерев перераховуються в першому диханні (як, наприклад, у піонерській роботі в цій області Jacobson, G. J (1988). Вдалі статичні структури даних), що не відповідає здається підходящим для мого завдання. Я маю справу з величезними двійковими деревами, заданими в макеті першої глибини, і індекси вузла глибини першого є ключем до інших властивостей вузла, тому зміна компонування дерева має для мене деяку вартість, яку я хотів би мінімізувати. Звідси зацікавлення отримувати посилання на твори з урахуванням інших, а не макетів BF-дерева.

  2. Великі масиви елементів змінної довжини у зовнішній пам'яті. Масиви незмінні: мені не потрібно додавати / видаляти / редагувати елементи. Єдина вимога - це час доступу до елемента O (1) і якомога менші накладні витрати, краще, ніж прямолінійний зміщення та підхід до розміру. Ось деякі зібрані нами статистичні дані щодо типових даних для мого завдання:

    типова кількість предметів - сотні мільйонів, до десятків мільярдів;

    приблизно 30% предметів мають довжину не більше 1 біта ;

    40% -60% елементів мають довжину менше 8 біт;

    лише кілька відсотків елементів мають довжину між 32 і 255 бітами (255 біт - це межа)

    середня довжина елемента ~ 4 біт +/- 1 біт.

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

Посилання на статті будь-якої складності, підручники будь-якої незрозумілості, більш-менш задокументовані бібліотеки C / C ++, - будь-що, що вам було корисно у подібних завданнях або що виглядає так вашим освіченим здогадком - всі такі речі вдячні.

Оновлення : я забув додати до питання 1: двійкові дерева, з якими я маю справу, незмінні. У мене немає жодних вимог щодо їх зміни, все, що мені потрібно, - це лише проходження їх різними способами, завжди переходячи від вузла до дітей або до батьків, так що середня вартість таких операцій становила O (1).

Також типове дерево має мільярди вузлів і не повинно повністю зберігатися в оперативній пам'яті.

Відповіді:


12

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

Щодо дерев, я б почав з читання Arroyuelo та ін.: Світлі дерева в практиці . У статті розглядаються дерева в основній пам'яті, але більшість методів можна використовувати у зовнішній пам'яті з аналогічним вибором, як показано нижче.

γδББ

нSнS[i]=1ijrанк(j)

Якщо ви хочете, щоб індекс рейтингу був невеликим, вам слід зробити розмір блоку досить великим (можливо, кілобайт або десятки кілобайт), що робить вищезазначене базове рішення процесорним процесом. Це можна вирішити, додавши трохи накладних витрат до блоків, що зберігаються на диску. В основному ви застосовуєте одне і те ж рішення рекурсивно, так що кожен блок диска зберігає ряд невеликих блоків, а також інший індекс рангу. Коли ви знайшли правильний блок диска, ви використовуєте в ньому індекс ранжування, щоб знайти правильний невеликий блок для декодування, замість того, щоб розшифрувати весь блок. З цим вторинним індексом випадкові доступи, ймовірно, стають пов'язаними з входом / виводом навіть при найшвидших наявних твердотільних накопичувачах.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.