Я не противоречу себе, я дополняю себя. Да ни одна база не потянет. И я за свои слова отвечаю, потому что плавал не раз. Ну если даже и сотни мегабайт там вытягивается, то сколько по времени это занимает? Минуту? 10 секунд? А если параллельно апдейт на таблицу запустить, то надо думать, что MyISAM насмерть заблокируется. Ни одна база с приемлемой производительностью не потянет. Потянет тысяч триста страниц per node с нагрузкой 20-30 запросов в минуту. Сравните со статическим индексом в несколько миллионов записей и то же нагрузкой. А если еще памяти гигов шесть поставить, то потянет и 20-30 запросов в секунду :-) А мускулу эти шесть гигов будут как мертвому припарки, там все равно индекс очень большой получится.
Ну так в каком режиме эта таблица используется? Надо думать, что это точечные запросы по ключу, которые возвращают несколько записей. А в поисковой машине как раз требуются запросы, которые возвращают десятки или даже сотни тысяч записей. Представляете сколько времени требуется любой базе данных, чтобы их считать? А поисковая машина делает это за десятые доли секунды, а если все лежит в кеше, то и за тысячные.
1) Отнюдь не любая база данных - это набор файлов, как это в mysql. Некоторые базы умеют с сырыми дисками работать, так там файлов нет вообще. Возвращаясь к ораклу. У него данные хранятся в экстентах, а экстенты в дата файлах. Дата-файлы составляют табличное пространство. Так вот, когда в таблицу заносятся всякие варчары и инты, то под них выделяется место прям-таки в этих экстентах из табличного пространства. Когда там хранится блоб, то реально вместо блоба хранится только блоб-локатор. А сам блоб хранится в другом месте. Ну может не в отдельном файле, но в отдельном экстенте размером 4 к минимум.
В mysql это не так. Там блобы укладываются прям-таки в табличное пространство. Это означает, что вместо записией постоянного размера, там появляются записи сильно переменного размера. Что по-моему и не только по-моему опыту работы сильно сказывается на производительности. Не в лучшую сторону.
Теперь по-поводу того, какого размера варчар туда положить. Варчар он на то и варчар, что переменного размера. Соответственно максимальный размер берем по максимуму. Позиции храним упакованные, все позиции, которые не влезают выкидываем. Немножечко скажется на релевантности в одном случае из тысячи. Не очень критично.
По поводу держания мускулом террабайта? Это в каком виде он его держит? В виде одной таблицы? Какой тип таблиц? MyISAM не потяент, потому что свалится на блокировках. А, вообще, повторюсь, что SQL решение в 100 раз медленнее, чем статический файл. Особенно печально происходит там индексация.
PS: по моему опыту, у мускульных поисковиков проблемы начинаются отнюдь не с террабайтов, а с десятка гигабайт. то есть на десятке гигабайт полный ПPЕВEД.
1 вариант будет десяток записей
2 можно собрать эти записи в один блоб, но в действительности выигрыш от такого объединения может быть иллюзорным. все от базы зависит. в оракле, например, блобы лежат в отдельных файлах, поэтому на каждую такую запись будет создаваться 4 или 8 килобайтный файл!!! в mysql блобы вроде хранятся в теле таблицы, но если постоянно происходят обновления, удаления, и прочая, то таблица с записью перменного размера может сильно фрагментироваться и производительность опять-таки упадет. то же самое будет, если хранить не блобы, а варчары.
короче, с какой стороны не поглядеть SQL это сакс и производительность такой поисковой машины в сто раз меньше, чем у машины со статическим инвертированным файлом.
А аннотацию Вы тоже с этой главной страницы будете делать?
Не бывает самой релевантной страницы сайта Например, вы вводите, слово, которое на главной странице отсутствует. Более того, оно отсутствует на страницах, ссылающихся на эту страницу. И в эпсилон-окрестности также нет слов, форм-слова и его синонимов. Как эта главная страница может быть вообще релевантной?
не бывает одной, главной страницы.
в смысле она бывает, но она редко бывает релевантной
Ну так основная идея такая, что раскладывание всего этого по реляционным таблицам идея заведомо не очень хорошая, но посмотреть структуру базы можно в mnogosearch.
А в принципе, сложностей быть не должно таблица
words:
word_id
word
таблицы
urls:
url_id
url
таблица связей
url_words
pos
вообще-то все это делают опенсорсные поисковики на базе sql, mnogosearch, dataparksearch, aspseek.
http://www.dcs.gla.ac.uk/Keith/Preface.html
http://citeseer.ist.psu.edu/88449.html
http://www.dialog-21.ru/direction_fulltext.asp?dir_id=15539
http://company.yandex.ru/articles/romip2004.xml
