Структура даних, що дозволяє ефективно шукати теги


11

Я шукаю високоефективну структуру даних для зберігання даних, подібних до наступних.

Ідентифікаційні теги Order1 Order2 
--------------------------
1 1,2 1 1
2 2,5 2 3
3 1,7 4 7
4 6 3 0

Мені потрібно , щоб мати можливість запросити цю структуру таким чином , що це дало б мені список всіх ідентифікаторів , що містять вираз тегів - підтримка ANDі ORта NOTоперації. Напр. ((1 або 2), а не 7)

Мені також потрібно мати змогу вказати впорядкування результатів (Order1 або Order2) та бути в змозі вказати максимальні рядки, що повертаються з необов'язковим зміщенням. Ефективність для перших 30-100 результатів є ключовою.

Нарешті, мені потрібен дешевий спосіб пошуку "відносин тегів", наприклад, я хочу знати, які теги "відносяться" до тегів (1 АБО 2) і з якою частотою. Значення, які теги відображаються в тому ж наборі, що і 1 АБО 2 ... упорядковано за частотою.

Будь-яке уявлення про те, яка структура даних (або набір структур) була б високоефективною для такого роду робіт?

(Я хотів би використати це як доказ концепції для перероблення тегів сторінок сімейства сайтів SE)


1
Просто коментар (можливо, тривіальний). Чому ви не покладаєтесь на реляційну систему управління базами даних? Ви можете визначити таблицю з парами <id, tag> та додати індекс у стовпчик тегів. Тоді ви можете використовувати стандартні запити SQL для вилучення даних. RDBMS ефективно виконає "брудну" роботу з оптимізації запитів та сортування вихідних даних.
Marzio De Biasi

@ Або, вирази неймовірно неефективні при високому масштабі, самоз'єднання стає кошмарними запитами.
Сем Шафрон

@Sam: гаразд. Ваше завдання досить поширене, тому я подумав, що хороша RDBMS (з інструментом обміну даними) може зробити цю роботу. Я залишаю слово експерту з структури даних. :-)
Марціо Де Біасі

Я вважаю, що якщо дозволити всі комбінації І, АБО, НЕ буде ускладнювати створення структури даних, яка не перераховується через усі елементи (можливо, це може бути обмежено 3-CNF?). Якщо такого обмеження не існує, можливо, просто запустіть записи (у визначеному порядку), поки не знайдете 30-100, які передають ваші вимоги до тегів. Хоча, загалом, я згоден із пропозицією Vor використовувати базу даних, щоб зробити важкий підйом для вас.
bbejot

Не експерт, але я думаю, що якщо ви не поставите обмежень щодо того, як ви можете запитати про теги, це буде важко. Обмеження їх до CNF (як запропонував bbejot) - це один із способів, інший - обмеження кількості різних тегів, про які запит може запитувати невеликою кількістю (скажімо, 6).
Каве

Відповіді:


6

Це не зовсім відповідь на ефективну структуру даних, а скоріше розробка коментарів @bbejot та @Kaveh, що дає аргумент рукою, чому, враховуючи поточне запитання, ми не повинні сподіватися на те, що робить набагато краще, ніж пошук ціла база даних. Аргумент ґрунтується на зменшенні від SAT, експоненціальній гіпотезі часу та великій маханні рукою.

nx|x|=nxj=1jxj=012nккАNDОRNОТн2н

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

н1


Гарне спостереження. Кожне питання містить не більше 5 тегів, тому запит про теги еквівалентний 5-CNF.
Каве

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

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

@SamSaffron - Де MSO-пост із деталізацією цієї функції? Ми отримали повідомлення про помилку тут .
Кевін Вермер

5

Це досить відверта відповідь, але я вважаю ефективною:

Map Tag ([Id],[Id])О(лог(н))

Map Id (Set Tag)IdO(nlog(m))


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