Поиск в базе

немножечко не так, в среднем веб-документе немножечко побольше чистого текста: так где-то около 3-4 килобайт.

по собственному сайту, который на анлийском языке. тут пару человек посоветовало решения, сижу разбираюсь :)

akor, Тогда ясно! Удачи :)

У меня 3 вопроса по теме:

1) При создании индекса (id_word, id_obj, weight) размер индекса становится больше, чем индексируемый текст, на 300 кб упакованного текста приходится 1.5Мб индекса , где id_word - уникальное 8 байтное число, являющееся результатом хеширования слова. Как можно уменьшить это число, например, до 4 байт или даже меньше? Кажется, где-то на форуме itman писал, что у него идентификаторы слов размером 4 байта. Какую для этих целей выбрать хеш-функцию? Я делаю с помощью CRC32.

2) База Mysql. Можно ли создать в ней индекс такого типа:

id_word, {id_obj,weight}{id_obj,weight}...

где {}{}... - одно поле, где данные представлены в бинарном виде (blob-поле).

Вернее, вопрос не в том как создать, а как это можно использовать средствами MySQL и PHP при выборке и группировке.

В PHP Inside #7 2004 упоминалось, что в MnoGOSearch есть blob-режим, и что в нем используется именно такая схема, если я правильно понял. Как там это реализуется?

3)Где лучше хранить заархивированные тектсы в БД или на жестком? В упакованном виде они весят ~50b - 1kb. Поисковик локальный.

1) Про хеширование слов - не боитесь, что при совпадении хэшей может возникнуть путаница? Как-то мы тут обсуждали хэши (не упомню, кажется, я же тему и начинала): совпадаемость довольно серьезная...

2) мое мнение - можно. пока не разглядишь...

3) если поиск локальный - все можно хранить в БД, как мне кажется. Не думаю, что вам не хватит размера блоба или произойдет перенагрузка БД (если у вас не супер-пупер мегапосещаемый портал с уймой аккаунтов на той же СУБД, которая просто уже трещит по швам).

В 4-е байта можно уложить список из 4'294'967'296 ID слов - вполне достаточно. ID слова(auto_increment) и само слово - хранить в отдельной таблице.

Не совсем понятно что пишется в поле "weight".

Много мелких документов лучше хранить в БД. Получаете много удобств: проще делать бекап, проще доступ, проще сервис, проще функции запроса. До 10 млн. документов - можно хранить без проблем, проверено электроникой :) И больше уверен можно, только не проверял лично.

weight - это вес слова в документе.

А как насчет вопроса №2?

Не совсем понятно, пока не разглядишь чего?

Ratwist,

Э-э... я смотрела невнимательно, и не вдумывалась, куда какие поля в индексе, то есть не разглядывала.

но, в общем, думаю, вы алгоритм будете еще усложнять.

Можно более конкретно, вы же люди с опытом. То что я описал на php сделать реально или лучше перейти на C++? Так как я понимаю группировать и сортировать подобные индексы придется средствами языка, а не средствами самой Mysql. Или может лучше не заморачиваться и делать простой индекс

word1, id1, w1

word1, id2, w2

word1, id3, w1

word2, id1, w3

...

Получается избыточный индекс, к тому же еще и не отсортированный.

Ratwist, Я сторонница сей. PHP - сам по себе язык более высокого уровня, и, соответственно, юзает больше ресурсов.

Но - если вы, опять же, внимательно почитаете некоторые треды данного раздела, можно найти дискуссии, на чем вообще писать поисковики.

И, собственно, не чувствуйте ограничений - отдельные модули можно писать на разных языках. Почему бы и нет, если с++ имеет множество API Mysql, и вы собираетесь сливать все в блобы?

Если поиск локальный - пусть ваш индексатор будет на сях, а поиск - в виде php-скриптов.

Кроме того, окончательный алгоритм придумываете в конечном счете вы, и мы... хе-хе, "люди с опытом", в детали не посвящены, а телепаты - большая редкость.

Что такое у вас w1, w2....?