Допустим любой распространенный язык. Лучше формулами и ссылками Мне надо изучить методы построения поисковых машин, сейчас делаю нечто похожее на DesktopSearch-поисковик. К сожалению, нашел мало дельной информации. Один сайт: itman.narod.ru, а вот зеркало: zaotzs.ru/admin/itman.tar.gz (15 МБ) и еще несколько ссылок с него. Все остальное на уровне: делаем таблицу хешей, документов и кроссировучную хеш_документ в обычной БД типа xxx. Индексируйте свои 100 МБ и радуйтесь. Не понял, по какому принципу строить хранение индекса. В обычной базе данных типа ACCESS с одним полем уже после 10000 слов (хешей, правильней) начинается видимое замедление работы. А ведь там должны быть и многие другие поля. Вообщем, тормозит на обычных БД с b-деревьями Кратко делаю так: С помощью IFilter или регулярных выражений (зависит от типа документа) получаю хеш-таблицу слов документа. Убираю повторяющиеся, оставляю приставку и основу, узнаю, что за часть речи (пока абстрактные: существо, действие, описание). Добавляю в индекс только новые слова, которых в индексе еще нет. Пишу в кросс-таблицу соответствие слово-документ. Вот на добавлении в базу новых слов все тормозит. Это неудивительно, поскольку это делается обычным SQL-запросом. Вообщем, если знаете, подскажите, как организовать хранение и бысрую перестройку индекса. Или другой способ организации поиска. Лучше подкреплять ответ ссылками. Заранее спасибо.
Полнотекстный поиск по большому массиву файлов (html, текстовые, doc, rtf и др.) 1. Берем документ. Создаем хеш-таблицу слов в документе. 2. От всех слов оставляем только основу. 3. Сравниваем со словарем и добавляем только новые. При поисковом запросе делаем п.п. 1-2. Далее сравниваем со словарем по вхождению слова и выводим результаты. Вот простенький алгоритм. Проблема в том, что скорость сильно понижается при размере словаря в ~20000 слов. А планируется там хранить около 20 млн. Так что обычные базы данных здесь не подходят. Тот же DesktopGoogle, например, со своей файловой БД коим-то образом индексирует очень быстро.
Может быть есть смысл группировать слова в группы и группы тоже маркировать хешами? Здесь, мне кажется, очень подходит принцип: "разделяй и властвуй" (как в методе Фурье ) )
Можно сделать деревья так, что за один спуск можно будет найти слово. В Яндексе написано, что такой словарь на 300 тыс. слов занимает около 300 кБ. Только как его сделали большой вопрос. А слова на группы я разбивал. Быстродействие не прибавилось. Из той информации, которую удалось найти, узнал, что "обычные" базы данных здесь не помогут. Вопрос в том, что использовать, чтобы достичь хорошей скорости (хотя бы как у "игрушечных" Desktop-поисковиков)
>>>А слова на группы я разбивал. Быстродействие не прибавилось. Этого быть не может. Скорость при грамотном разбиении ДОЛЖНА вырасти (хотя бы незначительно). Фактически, разбиение на группы и есть в некотором смысле построение дерева. Естественно, что одним уровнем разбиения тут не обойтись, надо делать многоуровневое разбиение. Поясню. Первое разбиение на ~30 групп: по первой букве слова. Второе разбиение: каждую группу опять разбиваем на группы, уже по второй букве. Третье разбиение по третьей букве etc. Таким образом, получаем небинарное дерево. При достаточной глубине разбиения поиск слова будет сводиться к проходу по веткам дерева.
Наилучший вариант для строковых данных - TST. Ссылок - как грязи ... Начать можно отсюда: http://www.ddj.com/documents/s=921/ddj9804a/9804a.htm
Я в этом мало, что понял. Но наверно использовал бы частотный анализ по частоте использования\запросов. Частотных подходов очень много, в частности и внутри процессора много частотных алгоритмов (и в кешировании и в предугадывании переходов). Вобще тема серьёзная, я бы не стал спешить с предложениями. Если на работе бы что-то подобное предложили, моей бестолковке понадобилось бы ~ месяц, чтоб проанализировать и как-то систематизировать то, что к этому может иметь отношение. Вот такой неказистый ответ. Стареющий и глупеющий Свин...
