Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Delphi: Общие вопросы > Алгоритм поискового движка для HTML-страниц

Автор: GrigoriyFomin 16.10.2011, 21:28

Подскажите плз, алгоритм, а может и готовое решение:
Есть куча HTML страниц, сжатых по Zlib и запихнутых в базу.
Необходимо создать быстрый поиск. Как мен видится решение - нужно создать индекс: список слов и встречаемость его в документах. Так вот отсюда вопрос - как составить список слов? - то есть поубирать из индекса предлоги, междометия и проц. ненужный мусор (точнее, где такой перечень слов можно нарулить) - и как наиболее оптимально организовать хранение такого индекса - БД, текстовый файл, бинарный файл или еще как-то.
Думаю, структура БД будет такой 1 таблица ID:integer; Word:String, затем соббсно сам индекс: ID_Word:integer; ID_Doc:integer;PosInDoc:string

Заранее спасибо за наводки, ссылки и проч.

Автор: niteo 17.10.2011, 16:06

Поискового бота пишешь? ;)
Собирай все слова которые найдешь. Сделай табличку вида: id; word; length; PartSpeech; IndexFreq; HTMLName; многа многа полей
Делай все в какой нить MySQL
Проиндексируй ее по полям, которые тебе понадобятся. Потом вот это: http://lmgtfy.com/?q=%D0%91%D0%B0%D0%B7%D0%B0+%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D1%85+%D1%81%D0%BB%D0%BE%D0%B2
Ну и дальше делаешь что тебе надо...

Автор: niteo 18.10.2011, 07:26

Вот тут еще почитай
http://wwwmaster.zx6.ru/view.php?sec=1&id=17

Автор: DYUMON 19.10.2011, 19:10

когда то доводилось делать поиск по базе html страничек с подстветкой найденого в странице. делал через регулярные выражения. а сами старницы хранил в базе в обычном хтмл .

Автор: GrigoriyFomin 19.10.2011, 22:56

Мне нужна концепция организации поиска
Сечас делаю так - в одном массиве
перепробовал движки БД для хранения индекса - очень медленно получается, поэтому храню в тнативных массивах и потоках
1. список типа TStringList -
Задача - типа поисковика для документов предприятия, которые в ХТМЛ, стандартные средства применять нельзя.
список стоп слов, которые будут выбрасываться из поискового запроса и при индексации будут игнорироваться
2. список сло с спривоенными им ID (есть bдея хранить не список слов, а результат вычисляемой на основании слова ХЭЩ-функции
, но функции не нашел подходяещй, да и смысла скорее всего нет
3. собственно индекс слов в виде записи

Код


type
  TWordPos = record
    DocID: UInt32; //номер документа
    DocPos: UInt32; //позиция слова в документе
    WordID: UInt32;//ИД слова из пред. таблицы
  end;

type
  TWodlListItem = record
    ID: UInt32;
    word_: array [0 .. 49] of Char;
  end;

Работа со списками идет в виде банального прогона по элементам массива
Поругайте идею и предложите оптимизацию как для построения индекса, так и для его дальнейшего использования

Автор: DYUMON 20.10.2011, 06:14

хз я хранил данные в таблице sqlite . примерно 10000 записей поиск занимал несколько секунд.

Автор: Akella 20.10.2011, 08:54

это очень долго

Автор: niteo 20.10.2011, 09:15

Создай словарь (список всех возможных словообразований) по всем таблицам (хтмл файлам). Словарь будет конечен (при добовлении новой таблички, обновляй его). Затем к каждой таблице добавь описание (id_word, position_word). Сделаешь все это в MySQL имхо поиск будет доли сенкунды.

Автор: GrigoriyFomin 22.10.2011, 14:41

отказался от движка БД. Статистика такая - слов и словоформ - тыщ 400, позиций в слове35 млн - создание индекса средствами БД - жутко долго, щас занимаюсь максимальной оптимизацией, особенно касаемо копирования памяти, сортировки, сравнения строк.

Вот, хочу предлжить на критику следующую функцию, аналог ansicomparetext .
Регистр всегда верхний, поэтому преобразований в этом месте нет. Параметры такие, потому что на вход удобнее без преобразований типов подавать именно такие.

Код



function mycomparetext(apc: array of char; asst: string): Integer;
var
  asstl,i,aapc: Integer;
  c:char;
begin
  i := 0;
  asstl:=length(asst);
  aapc:=length(apc)-1;
  while ((apc[i]<>#0) or (i<aapc)) do
  begin
    c:=asst[i + 1];
    if apc[i] > c then exit(1);
    if apc[i] < c then exit(-1);
    i := i + 1;
  end;
  if i<asstl then exit(-1);
  if i>asstl then exit(1);

  exit(0);
end;

И ещеникто не поделится опытом работы с морфологией? Как искать без учета падежей и склонений, спряжений?

Автор: niteo 24.10.2011, 07:54

M
MetalFan

Оверквотинг
Правила форума: http://forum.vingrad.ru/index.php?act=boardrules
Зачем цитировать ПОЛНОСТЬЮ сообщение в следующем за ним ответе?

Все же, попробуйте обратить внимание на БД.
Идея такая: Есть у вас допустим набор таблиц, вы сделали как я написал уже выше. А вновь добовляемые данные будете складывать в другую табличку, соответственно индекс будет строиться очень быстро (пока там снова не скопится большое колличество данных), но периодически можно скидывать данные из новой таблички в старую, а новую затем подчищать...

По поводу функции, нет выхода по условию завершения строки asst
Я бы сделал этот кусок кода на asm.

Автор: GrigoriyFomin 24.10.2011, 18:11

Я видел, что глючит иногда функция и отказался от нее в пользу библиотечной функции сравнения двух pchar строк. С асмом не дружу. Помнится, попадалась как-то библа - набор аналогов функций со строками и памятью, оптимизированных под конкретный проц, но скока щас не искал - не могу таких найти - может с ними пошустрее была б работа. По поводу БД - я отказался от БД и разница в скорости возросла в десятки раз!!!!! Думаю, такое ускорение быстродействия стоит того, чтоб все ручками прописывать smile

Автор: niteo 24.10.2011, 19:16

По поводу функции, есть вот такая StrComp
А по поводу БД, вы ее не правильно "готовите".

Автор: MetalFan 26.10.2011, 13:45

Цитата(GrigoriyFomin @ 24.10.2011, 18:11

)

Помнится, попадалась как-то библа

QStrings, но к сожалению только для Ansi строк.

Цитата(niteo @ 24.10.2011, 19:16

)

А по поводу БД, вы ее не правильно "готовите".

Автор: Akella 26.10.2011, 16:18

Цитата(niteo @ 24.10.2011, 07:54

)

Зачем цитировать ПОЛНОСТЬЮ сообщение в следующем за ним ответе?

не раз такое наблюдаю на Винграде.