Нет, я понял по поводу объема базы данных. Средняя страница в 20 Кб, что примерно 3-4 средних HTML странички. То бишь, аналог в 15-20 млн страниц веба. И в среднем чуть меньше секунды на каждый запрос. А что была за железка?
Не очень понял насчет тестирования скорости: 5000 тысяч запросов выполнялись в общей сложности 45 минут, или 45 минут выполнялось 5000 * 40 тысяч запросов?
Дело в том, что RD-дерево в данном случае - это тоже векторная модель, но вектора проиндексированы. В связи с этим возникает два нюанса, разрешение которых требует для каждого найденного документа считывать текст: false positives и ранжирование. Собственно, это самое большое зло, потому что требует множества random disk accesses. Да и сами объемы чтения могут быть большими.
С инвертированными файлами такой проблемы не возникает: нет false positives, ранжирование осуществляется a priori, то есть до формирования сниппетов, а сниппеты нужно формировать только для небольшого количества документов.
Да нет, просто там векторная модель, а она тормозит на больших объемах.
Уууупс, звиняйте.
Апорт купили редкостные долбое"ы, которые, купив Апорт, первым делом уволили большую часть команды. А потом много лет держали Апорт в законсервированном состоянии. Этим людям в белых халатах Яндекс должен земные поклоны бить.
Загнать в MySQL версии не меньше 4.1.16 (не спрашивайте почему, начну ругаться матом) и построить full text индекс. На 100 мб и большом количестве ОЗУ (скажем 512 мб памяти) будет однозначно летать. Не забудьте перед постройкой индекса выставить в my.cnf параметры
ft_min_word_len=1
ft_stopword_file=
Не знаю, насколько адекватно работает full text в mysql 5.x
Дело в том, что Яндекс большой. Директ может и не уметь тему определять, а большой текст, наооборот, может. Хотя я тут начал сомневаться в связи с листом-то. Хотя может быть тривиальной ошибкой классификатора в данном конкретном случае. На одном примере нельзя делать выводы.
Пардон, а откуда такая информация??? При ранжировании может и с низким приоритетом, но речь же ведь шла вроде как об учете ссылок?
Мне тоже кажется, что может уже давно. Я помню, что году в 2001 Саша Садовский, если я ничего не путаю, писал про модное направление "рубрикации на лету".
Pro-maker: мне кажется, что это частный случай классификации. Есть LSI, есть тезаурусы , можно синонимы находить. Это все позволяет преобразовывать документ, или его кусочки в частотные векторы или их аналоги. При этом синонимы отображаются в элементы с одинаковыми номерами. Возможно, что структура HTML, еще какие-то неконтентные характеристики, тоже учитываются и оцифровываются. Как только мы получили вектор, у нас открывается море возможностей для оценки близости документов по теме (а фактически по лексике), а также для их классификации: от байеса до SVM. А Байес можно сделать очень быстро. Кстати, господа, обратите внимание на профессию товарища, когда пойдете по ссылке :-)
