Как лучше организовать базу для текстового поиска?

[Pjanis]

Как лучше организовать базу для текстового поиска?

Задача: Есть таблица с 200 000 записей. В каждой записи есть 3 текстовых поля по которым нужно делать поиск вида "%чтоищем%". Как лучше организовать эту таблицу, какие индексы сделать и чем пользоваться для поиска?

Мое решение: Вариант с LIKE '%что ищем%' сразу отмел ввиду невозможности использования индекса.
Использую MATCH() AGAINST(), но при этом столкнулся с проблемой: Если ищем в одном поле, то индекс должен быть только по нему, если ищем одновременно в двух полях, то индекс - сразу на два поля... Вариации полей могут быть любыми из этих трех... И что, делать индексы на все возможные случаи? А если будет 4 поля? Если этого не сделать, то время поиска сильно удручает. Кто сталкивался с такой хадачей? Хелп!

 

[HraKK]

я бы задал другой вопрос: как спроектировать нормальную базу данных для поиска

 

[Pjanis]

Я непрофессиональный программист. Теорией меня не пичкали и до всего приходится дотумкивать самому. Если подскажите хотя бы что-то буду благодарен. Мне в голову ничего кроме набора полей в одной таблице в этом случае не приходит.

 

[magic]

Во-первых: LIKE '%что ищем%' вот так точно лучше не делать

Во-вторых: "Вариации полей могут быть любыми из этих трех... И что, делать индексы на все возможные случаи?"

Именно.
[sql]ALTER TABLE
ADD FULLTEXT (field1),
ADD FULLTEXT (field2),
ADD FULLTEXT (field3),
ADD FULLTEXT (field1,field2,field3);[/sql]

> А если будет 4 поля?
Пропорциональное число индексов. БД конечно еще нужно смотреть. Может лучше переделать логику.

 

[Pjanis]

Эээ. А если надо искать _только_ в field1 и field3 ?
Пробовал запрос вида:
SELECT * FROM item WHERE MATCH(field1) AGAINST('поиск') OR MATCH(field3) AGAINST('поиск')

Но если в случае индекса сразу на field1 и field3 и поиска c MATCH(field1, field3) времени уходит десятые доли секунды, то вышеприведенный запрос выполняется 5 секунд, что достаточно долго. Хотя индексы при этом видимо все же используются, т. к. тупой перебор для случая LIKE занимает 15 секунд.

Что касаемо использования %чтоищем%, я думаю Вам не понравился первый процент запрещающий использование индекса... Но куда от него деться в LIKE случае, если искать нужно среди текста и пользователь не знает как пишется добуквенно от начала строки то что он ищет?

-~{}~ 29.10.06 00:22:

Сразу в догонку вопрос:
"БД конечно еще нужно смотреть. Может лучше переделать логику." - Вот с этого места чуть попродробнее можно рассказать?
Таблица:
Caption: Varchar 100
Author: Varchar 40
Copyright: Varchar 40
Также другие поля в наличии

Какая еще возможна логика для поиска? БД - MySQL 4.1.21

 

[magic]

> Эээ. А если надо искать _только_ в field1 и field3 ?
Эээ. А вот так слабо сделать?[sql]ADD FULLTEXT (
field1,
field3
);[/sql]

-~{}~ 28.10.06 23:30:

> Сразу в догонку вопрос: бла-бла-бла и прочее.

1. Поиск по автору (1 поле)
2. По названию (1 поле)
3. Искать везде (все поля)

 

[Pjanis]

Автор оригинала: magic
> Эээ. А если надо искать _только_ в field1 и field3 ?
Эээ. А вот так слабо сделать?[sql]ADD FULLTEXT (
field1,
field3
);[/sql]

В том то и дело что не слабо, до этого я вполне смог сам допереть, но метод лавинообразного увеличения количества индексов я считаю тупиковым. Помимо разрастания объемов базы не следует забывать и про растущие временные затраты на добавление новых записей (а это тоже происходит...)
Я сюда и написал в надежде что есть еще какой-то другой путь, не "в лоб".

> Сразу в догонку вопрос: бла-бла-бла и прочее.

1. Поиск по автору (1 поле)
2. По названию (1 поле)
3. Искать везде (все поля) [/QUOTE]
К сожалению не подходит, слишком разноплановая информация:
Автор
Название
ISBN книги
Издательство

А учитывая большое количество информации объединять похожие поля при поиске например MATCH(автор, название) когда человек ищет только в названии - некорректно, может вылезти куча лишней инфы с "подходящим" автором которая юзеру не нужна.

 

[magic]

К сожалению не подходит, слишком разноплановая информация:
Автор
Название
ISBN книги
Издательство

А вот это уже называется анализ и планирование
Кто мешает сделать таблицу авторов/издательств? ISBN - так там вообще одни цифры.

 

[hermit_refined]

Pjanis
Во-первых, по ISBN и издательству логично искать лишь по точному совпадению.
Во-вторых, посмотрите для примера - какова логика поиска у похожих сайтов.
В-третьих, если хотите самый лучший и самый быстрый поиск - разрабатывайте свою поисковую систему.

 

[Pjanis]

В поле ISBN могут содержаться несколько номеров сразу. Издательство каждый называет как угодно, нет однозначности (Питер, ИД Питер, ИД "Питер" и т. п.)

Я так понял, что все варианты решения моей проблемы рассмотрены. Наиболее вероятное решение - плодить индексы =(

Как в таком случае сделать поиск вида:
... WHERE MATCH(автор) AGAINST(верн) OR MATCH(название) AGAINST (под водой)

Запрос проходит 5 секунд, нельзя ли его сделать как-нибудь по другому? Вариант MATCH(автор, название) AGAINST(верн под водой) не очень устраивает.

 

[hermit_refined]

В поле ISBN могут содержаться несколько номеров сразу.

Значит, для ISBN должна быть отдельная таблица.

P.S. Вы можете всё-таки привести пример сайта, на котором такой же супер-поиск, который вы хотите?

 

[magic]

> В поле ISBN могут содержаться несколько номеров сразу. Издательство каждый называет как угодно, нет однозначности (Питер, ИД Питер, ИД "Питер" и т. п.)

Не могут. А если у вас они "могут", значит разруха в умах, а не в клозетах.

> ... WHERE MATCH(автор) AGAINST(верн) OR MATCH(название) AGAINST (под водой)

А теперь на русском.

 

[sawoy]

Привет.

а что мешает организовать таблицу в виде:

book_id | name_of_property | value_of_property

и добавить FULLTEXT на value_of_property ?