Топ k проблем - намиране на употреба за моята академична работа

Top k проблем - търсене на НАЙ-ДОБРИТЕ k (3 или 1000) елемента в DB

Има фундаментален проблем с релационните DB, че за да се намерят top k елемента, има нужда да се обработят ВСИЧКИ редове в таблицата. Което го прави безполезен при големи данни.

Създавам приложение (за университетски изследвания, не всъщност мое изобретение, внедрявам и се опитвам да подобря оригиналната идея), което ви позволява ефективно да намирате top k елемента, като посещавате само 3-5% от съхранените данни. Което го прави наистина бърз.

Има дори потребителски предпочитания, така че в някои домейни можете да посочите функция, която определя най-добрата стойност за потребителя, и функция за агрегиране, която определя най-важните атрибути.


Например DB на автомобили: атрибути: (цена, пробег, възраст на колата, ccm, гориво/миля, тип кола...) и потребителски стойности например 10*цена + 5 *гориво/миля + 4*пробег + възраст на колата, той не се интересува от вида на колата и други. - това е спецификация за обобщаване

След това за всеки атрибут (цена, пробег, ...), може да има напълно различна стойност-функция, която определя най-добрата стойност за потребителя. Така например (цена: по-ниска, толкова по-добра, след това стойността намалява, до $50k, където стойността е 0 (потребителят не иска кола, по-скъпа от 50k). Пробег: друга функция въз основа на неговите/нейните критерии, ans така нататък...


Виждате, че има доста свобода да посочите вашите предпочитания и според това best k елемента в DB ще бъдат намерени бързо.

Прекарах много безсънни нощи, мислейки за реалната използваемост. Кой може да се възползва от тази заявка db? Но не успях да измисля нищо и се придържах само към академична позиция само за писане. :-( Надявам се, че може да има някаква реална употреба за това, но не виждам такова....

....ИМАТЕ ли някаква идея как да използвате това в реалния живот, реален проблем и т.н.


I'd love to hear from You.


person DinGODzilla    schedule 26.11.2009    source източник


Отговори (3)


Разполагайте с база данни с автобиографии на хора и установете критерии за наемане за различни работни места, което позволява динамично показване на най-добрите k кандидати.

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

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

person luvieere    schedule 26.11.2009

Има неограничени възможни сценарии за реална употреба. Получаването на горните n стойности се използва през цялото време.

Но силно се съмнявам, че е възможно да се получат top-n обекти, без да има индекс. Индекс може да бъде изграден само ако свойствата, които ще се търсят, са известни преди търсенето. И ако това е така, един прост индекс в релационна база данни може да осигури същата функционалност.

person Georg Schölly    schedule 26.11.2009
comment
Моето решение няма да използва релационна база данни. Трябва да импортирам данни от релационна DB в моята DB (имплементирана чрез BerkeleyDB като многомерни B+дървета). В релационните DB няма начин как да направите това. По принцип трябва да обработите всички елементи, за да намерите най-доброто k. - person DinGODzilla; 26.11.2009
comment
Има дори много потребителски предпочитания начин за запитване. Колкото по-конкретна е заявката, толкова по-бързо се намира. Единственото ограничение е, че функцията трябва да бъде непрекъсната и линейно разбита. - person DinGODzilla; 26.11.2009

Използва се във финансови организации през цялото време, трябва да видите най-печелившите активи / най-малко печелившите и т.н.

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