Главная проблема k - найти применение в моей академической работе

Top k проблема - поиск ЛУЧШИХ k (3 или 1000) элементов в БД

Существует фундаментальная проблема с реляционной БД: чтобы найти top k элемента, необходимо обработать ВСЕ строки в таблице. Что делает его бесполезным при работе с большими данными.

Я делаю приложение (для университетских исследований, не совсем мое изобретение, я реализую и пытаюсь улучшить исходную идею), которое позволяет эффективно находить top k элементов, посещая только 3-5% сохраненных данных . Что делает его действительно быстрым.

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

Например, БД автомобилей: атрибуты: (цена, пробег, возраст автомобиля, куб.см, топливо / миля, тип автомобиля ...) и пользовательские значения, например 10 * цена + 5 * топливо / миля + 4 * пробег + возраст автомобиля, (s) ему все равно, тип автомобиля и прочее. - это совокупная спецификация

Затем для каждого атрибута (цена, пробег, ...) может быть совершенно другая функция-значение, которая определяет наилучшее значение для пользователя. Так, например (цена: ниже, тем лучше, затем значение снижается до 50 тыс. Долларов, где значение равно 0 (пользователь не хочет, чтобы машина дороже 50 тыс.). Пробег: другая функция, основанная на его / ее критериях, и так далее ...

Как видите, вы можете свободно указать свои предпочтения, и в соответствии с ними best k элементы в БД будут найдены быстро.

Я провел много бессонных ночей в размышлениях о реальной жизни юзабилити. Кому может быть полезен этот запрос db? Но мне не удалось что-либо придумать и придерживаться только академической позиции только для письма. :-( Я надеюсь, что может найти какое-то реальное применение для этого, но я не вижу ...

.... ты хоть представляешь, как использовать это в реальной жизни, в реальной проблеме и т. д.

I'd love to hear from You.


usability
person DinGODzilla    schedule 26.11.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

Новая идея: возможно, ваше исследование может иметь приложения для кластеризации, где вы могли бы использовать его для реализации быстрой кластеризации k - Nearest Neighbor по сложным критериям без необходимости каждый раз сканировать весь набор данных. Это привело бы к более быстрой кластеризации больших наборов данных с учетом более сложных критериев при выборе K-NN для каждого узла данных.

person luvieere    schedule 26.11.2009

arrow_upward
1
arrow_downward

Существует неограниченное количество возможных сценариев реального использования. Получение первых n значений используется постоянно.

Но я очень сомневаюсь, что можно получить топ-n объектов без индекса. Индекс может быть построен только в том случае, если свойства, в которых будет выполняться поиск, известны до поиска. И в этом случае простой индекс в реляционной базе данных может обеспечить те же функции.

person Georg Schölly    schedule 26.11.2009
comment
Мое решение не будет использовать реляционную базу данных. Мне нужно импортировать данные из реляционной БД в мою БД (реализованную через BerkeleyDB как многомерные деревья B +). В реляционной БД нет способа, как это сделать, вам в основном нужно обработать все элементы, чтобы найти лучший k. - person DinGODzilla; 26.11.2009
comment
Существует даже многопользовательский способ запроса. Чем конкретнее запрос, тем быстрее он будет найден. Единственное ограничение - функция должна быть непрерывной и линейно-прерывистой. - person DinGODzilla; 26.11.2009

arrow_upward
0
arrow_downward

Его постоянно используют в финансовых организациях, нужно видеть самые прибыльные / наименее прибыльные активы и т. Д.

person Max Galkin    schedule 26.11.2009
comment
да. Но эти очень специфические характеристики могут быть вычислены перед поиском, потому что они, вероятно, не сильно (или вообще не изменятся), и можно было бы использовать лучший подход. Наше решение предназначено для неограниченного (и многопользовательского) разнообразия топ-k запросов. - person DinGODzilla; 26.11.2009
comment
Если это торговля на FOREX или управление портфелем, когда цены в реальном времени появляются каждые N секунд, я бы сказал, что не так много. У разных трейдеров / портфельных менеджеров также могут быть свои пользовательские предпочтения. - person Max Galkin; 26.11.2009