Э... А он там нужен? :)
Справочная
Нет, широко используются и сигнатурные файлы, в которых применяются так называемые n-граммы, которые затем каким-то образом хешируются и формируют сигнатуру слов.
Более подробно можно почитать здесь.
Вот и спросите у разработчиков. ;) Насколько я знаю, большинство поисковиков используют.
По инвертированному файлу можно получить только некие координаты каждого слова в текста, сам по себе восстанавливать он ничего не позволяет.
Контент, из которого получаются сниппеты с подсвеченными ключевыми словами, обычно хранится в специальном хранилище, которое и адресуется координатами из инвертированных файлов.
С них все, естественно, начинают, но быстро спрыгивают.
Я бы посоветовал почитать классическую теорию по информационно-поисковым системам касательно инвертированных файлов и алгоритмов ранжирования, и попробовать по их мотивам написать что-нибудь свое.
P.S. Вижу, Вы тоже из Украины? :)
Обновлять частями, конечно. Распределенный индекс, каждая часть которого собирается на своей машине.
Словарь словоформ - это преимущественно статическая структура. Насколько я знаю, у Яндекса и Рамблера в словаре всего-то 100-150 тысяч слов.
А Вы собираетесь запускать второй Google? :)
Да. Зато максимально быстро.
Добавлении куда? При индексации формируется специальный словарь - лексикон, содержащий нормальные формы слов.
В лексиконе для каждого слова хранятся координаты в списке, по которым можно быстро получить документы, где слово встречается. Поэтому список служит только для быстрой выборки идентификаторов документов (и сопутствующей информации о координатах слов в тексте). Обычно в него ничего не добавляется и не удаляется, так как он формируется за один раз на этапе индексации.
Нет, конечно. :) B-деревья - это разновидность деревьев, которые дополнительно в своих узлах содержат какие-то данные, а инвертированные файлы - это списки данных.
Соответственно, отсортированное B-дерево может вырождаться в список. ;)
Необязательно. Чем сильнее сожмете, тем больше можете просадить производительность поиска.
В каком бы формате поисковая база не хранилась, производительность все равно будет относительно невысокой из-за ненужных операций вроде лексического разбора запросов и прочих радостей, из-за которых все проседает.
А не надо ничего придумывать - все уже придумано до нас. :) Любая поисковая система обычно строится на инвертированных файлах , теория хорошо изучена и общедоступна.
На этапе хранения данных и организации поисковой системы никаких вопросов не возникает - принцип у всех один и тот же. Вопросы появляются только тогда, когда нужно ранжировать документы и формировать сниппеты с подсвеченными словами.
Вообще-то СУБД никак не предназначены для использования в качестве поисковых систем - ни mysql, ни Oracle, ни другие базы. Кроме того, они имеют ограничения по объему информации.
Дело даже не в структурах данных и B-деревьях, а в самой организации СУБД - она служит для совершенно других целей. Максимум, что может дать база данных - это просто набор документов, где встретился искомый термин, так как никакой сортировки по релевантности или другим параметрам, подсветки в сниппетах найденных ключевых слов, группировки документов там нет. Конечно, есть отдельные пристройки под поиск, но они не слишком эффективны, чтобы использовать их на гигабайтных объемах.
