Есть таблица типа InnoDB. Есть задачи реализации полнотектового поиска. 2 варианта!

[Гриша К.]

Есть таблица типа InnoDB. Есть задачи реализации полнотектового поиска. 2 варианта!

Здравствуйте.

Есть таблица базы данных, типа InnoDB (таблица товаров интернет-магазина).
Есть задача реализации многотекстового поиска по некоторым данным содержащимся в этой таблице.

Есть 2 варианта решения:
1) Дублировать необходимые данные таблицы, в другой таблицы типа MyISAM.
В принципе минус видется только в том, что увеличивается размер базы данных (дублирование таблицы не очень нравится).
2) При поисковом запросе к таблице, создавать временную таблицу типа MyISAM, с нужными данными. Такой вариан нравится мне тем, что нет необходимости создания постоянной дублирующей таблицы.
Но я незнаю как повлияет на скорость работы БД, какова будет нагрузка (может в таком случае она увеличивается во много раз?). Вот если происходит 10 одновременных запросов к БД, то поидее получается, что будет создавать 10 временных таблиц, последовательно. Т.е. для 10 пользователя скорость запроса будет в 10 раз больше.

Прошу ваших комментариев по приведенным вариантам, советов.

-~{}~ 26.12.06 00:24:

ВОПРОС: При необходимости полнотекстового поиска данных содержащихся в таблице InnoDB, 1) Лучше создавать постоянную дублирующую таблицу MyISAM или 2) временную таблицу MyISAM?[/green]

 

[magic]

Что-то вы, уважаемый, очень мутите. Чем не нравится встроенный полнотекстовый поиск? Тяжело лишний ключ в таблицу добавить?

-~{}~ 26.12.06 13:35:

Только разнесите циферки и текстовые данные по отдельным таблицам.

 

[zerkms]

magic
innodb не умеет полнотекстовый поиск

 

[magic]

zerkms
А это видно?

Только разнесите циферки и текстовые данные по отдельным таблицам.

 

[zerkms]

magic

Что-то вы, уважаемый, очень мутите. Чем не нравится встроенный полнотекстовый поиск

1) Дублировать необходимые данные таблицы, в другой таблицы типа MyISAM.
В принципе минус видется только в том, что увеличивается размер базы данных (дублирование таблицы не очень нравится).

 

[magic]

zerkms
И к чему эта дискуссия? Не нужно дублировать таблицы.

Разнести данные по разным таблицам и использовать встроенный полнотекстовый поиск.

У вас другое мнение, коллега?

 

[zerkms]

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

 

[Krishna]

Гриша К.
У меня сейчас точно такая же проблема. Пока тоже смотрю в сторону дублирующих MyISAM.

По сути вопроса - у Вас наверное какие-то микротаблицы, если Вы собираетесь их динамически дублировать (вариант 2) ) и при этом еще получать ускорение при поиске
У меня форумная таблица на 400 мегабайт (Юникод) и я планирую её дублировать в MyISAM для ФТ поиска.
Проблема места у меня не стоит (свой сервер). Проблема производительности - весьма. Взаимные локи уже поднадоели.

-~{}~ 26.12.06 17:39:

То есть, я придерживаюсь 1) варианта. 2) мне кажется надуманным.

 

[Апельсин]

> У меня сейчас точно такая же проблема. Пока тоже смотрю в сторону дублирующих MyISAM.

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

 

[Krishna]

Bermuda
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

Почитайте. Или Вы нас пытаетесь убедить, что можете не хуже на PHP или хранимых процедурах?

-~{}~ 26.12.06 18:16:

Апельсин
Мне так сложно не нужно. Просто при постинге будет создаваться 2 копии поста - в MyISAM и в InnoDB. Вывод страниц будет работать с InnoDB, с высокой производительностью на параллельных запросах и отсутствием проблем блокировок, а поиск будет идти по MyISAM.

 

[Апельсин]

Krishna, тоже вариант
но тебе тогда надо контролировать, что все изменения идут в обе таблицы

 

[Krishna]

Ну это несложно

 

[Гриша К.]

Спасибо большое всем за ответы.
Буду использовать первый вариант.

 

[alexhemp]

Не надо дублировать - проиндексируй сам сайт.

Пример - таблица товаров хранит описание и ссылку на таблицу брендов, самого бренда нет в базе.

Поиском по базе ты не найдешь сочетание "Бренд товар", при нормальном построении базы у тебя такой строки и не будет. Используя внешний индексатор (mnogosearch, lucene) ты такой поисковый запрос сможешь корректно обработать, ведь при поиске товаров люди перво-наперво вписывают бренд.

 

[Krishna]

alexhemp
Внешний поисковик не контролируется. Нельзя сделать расширенный поиск ("использовать такое-то слово в описании, при этом рубрика товаров - такая-то, дата размещения не позднее такой-то"). Так что это ИМХО от лукавого - только если не получается сделать нормальный поиск. Бренд-то вынести в форму поиска несложно.

 

[Гриша К.]

Спасибо за ответы.
Вот прям сейчас буду реализовывать поиск. Решение №1.

Пример - таблица товаров хранит описание и ссылку на таблицу брендов, самого бренда нет в базе.

В БД у меня есть таблица производителей (логотип, описание, сайт), в таблице товаров стоит ИД производителя (БРЭНДА), товары выводятся по категориям и по производителям (с выводом описания производителя).

alexhemp, по поводу проинедксировать сайт самому, это я не понял, не делал так, попробуюу по приведенным вами ключевым словам найти информацию.

Назрел такой впорос (подскажите пожалуйста советом), таблица товаров у меня содержит (пример):
ИД товара, ИД категории, ИД производителя, Название, Описание.

У меня сомнения между выбором, так скажем, структурой дублирующей таблицы, получается 2 варианта:
1) С учетом выше приведенного примера, дублирую таблицу полностью, и поиск провожу по новой таблице type=MyISAM.
2) В дублирующую таблицу, добавляю ИД товара, Название, Описание, при поиске объединяю ее по ИД товара с основной таблицей.

-~{}~ 28.12.06 18:36:

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

 

[alexhemp]

Krishna

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

И потом - вы посмотрите статистику запросов пользователей! Вы думаете на сайте, где меньше миллиона страниц - кто-то ищет так изощренно? В яндексе то никто практически расширенный синтаксис не использует (сужу по refferer-ам с поисковиков на 10 примерно крупных сайтах).

Зато такой поиск с использованием внешнего индексатора позволяет легко обрабатывать морфологию и словоформы.

В итоге все зависит от задач. Поиск по сайту - лучше внешний индексатор с морфологией. Поиск ТОЛЬКО по каталогу товаров - сделайте обычный фильтр и можно даже по LIKE в текстах искать, если есть дополнительное условие, сильно ограничиващее выборку (правда лучше стеммер еще какой-нить использовать).

Гриша К.

попробуюу по приведенным вами ключевым словам найти информацию

Молодец! Вот это правильный подход.

 

[Гриша К.]

alexhemp, спасибо за ответ.
Сделал много текстовй поиск, в соответсвии с контсрукцией в мануале mYSQL, (SELECT ... MATCH() AGAINST FROM ... WHERE MATCH() AGAINST),
+ попробовал булевский многотекстовый поиск (работает как LIke, если указать *), но нет релевантности. А конструкцию LIKE '%text%' я не хотелбы использовать.

Mnogosearch.ru - если я правильно понял, то для его установки нужны права root, нужно компилировать php, и использовать командную строку для совместимости с MySQL (при указании типа БД). Но как я понял там есть морфология. http://silinio.webhost.ru/mnogosearch-3db.html. На хостинге такого не сделать

Что сейчас получается в поиске:
например по слову "машин", найдутся товары где только содержится "машин".

Попробовал сделать так, сортировать по релевантности в порядке убывания, а выводить (искать) по булевскому полнотекстовому поиску, с условием того, что к словам разделенным пробелами в поисковом запросе, добавляется *.
В таком случае по запросу "машин", найдутся товары содержащие "машин", "машины" и т.д.
Ну я еще подумал о том, чтобы для слов длинной от 6 символов, заменять последние два символа на *.
В итоге запрос "школьный автобус", будет выполнен как "школьн*, автоб*". С релевантностьюю не все хорошо, так как булевский полнотекстовый поиск, ее не выводит, то получится, что в релевантные запросы, могут быть в конце, Но все же будут найдены.
Так что думаю пока сделаю так, чтобы до нового года запустить проект (остался только поиск), а затем уже буду думать. Ну возможно и сейчас, каки-то идеи подскажете.