Поиск по большой базе

[dimonbes]

Поиск по большой базе

Всем здравствуйте!

Пишу доску объявлений (уже почти написал). На этом Форуме почитал, что поиск по большой БД типа "куплю цветочный горшок" обычным SELECT FROM ... WHERE ... LIKE будет жутко тормозить, и надо юзать модуль mnogosearch. Правда ли это, или достаточно будет помудрить с оптимизацией мускула и запросов? Проблема животрепещущая, т.к. из mnogosearch я знаю только название и что, по отзывам, юзать его полный гимор. Не хотелось бы из-за этого тормозить уже почти готовый проект. Может поможет кто советом? Спасибо!

 

[_RVK_]

dimonbes
Ты попробовал "поиск по большой БД типа "куплю цветочный горшок" обычным SELECT FROM... "? Тормозит?

 

[dimonbes]

Ну. ошибся в русском языке, исправляю - поиск типа "куплю цветочный горшок" по большой БД. Пробовать не пробовал - базы такой - полей тысяч в 20, и все разные - нет. Может, у кого-нить была?

 

[serglt]

Товарищи, я бы сказал что ничего в БД не тормозит а тормозят только руки у программиста, к сожалению
Для данной проблеммы, просто не надо делять запросов типа ... LIKE '%bvcxbv%' Одно вхождение работает быстрее чем поиск по всему тексту.
Во вторых для запросов с условиями OR целесообразнее использовать UNION (объдинение). Jgthwbz ИЛИ тормозит запрос к БД офигеть как . Лучше делать маленикие и объединять. В третих Поля по которому будет осуществляться поиск лучше сделать индексированным. Выборка в этом случае будет быстрее но вставка и обновление будет медленнее.
Создать индекс просто:
CREATE INDEX ix_IndexName ON TableName (TabeField)

 

[_RVK_]

dimonbes
Я не к языку придрался. Прочти мою подпись, и все поймешь.

 

[chira]

serglt

Товарищи, я бы сказал что ничего в БД не тормозит а тормозят только руки у программиста, к сожалению

это ты верно сказал ...

Для данной проблеммы, просто не надо делять запросов типа ... LIKE '%bvcxbv%' Одно вхождение работает быстрее чем поиск по всему тексту.

ничего не понятно, что хотел сказать? какое вхождение?

Во вторых для запросов с условиями OR целесообразнее использовать UNION (объдинение). Jgthwbz ИЛИ тормозит запрос к БД офигеть как . Лучше делать маленикие и объединять.

не факт, если быть точным OR можно заменить на UNION ALL, а не простой UNION, но это не даёт 100 процентрой гарантии увеличения производительности.

В третих Поля по которому будет осуществляться поиск лучше сделать индексированным. Выборка в этом случае будет быстрее но вставка и обновление будет медленнее.
Создать индекс просто:
CREATE INDEX ix_IndexName ON TableName (TabeField)

и как это поможет, если он проиндексирует своё текстовое поле?

-~{}~ 27.12.05 23:13:

dimonbes

у тебя все объявления будут в одной куче и ты хочешь искать во всех объявления сразу?
я бы разбил все объявления на группы или категории или каким-то общим признакам или ещё как-нибудь.
предоставляя поиск, предлагай выбрать в какой группе искать, сразу избавишь MySQL от сканирования всей таблицы.

 

[_RVK_]

chira
Пойми, у автора нет проблеммы. А несуществующую проблемму глупо решать. Не находишь?

 

[serglt]

chira
Почитай мануал , Как думаешь зачем одной таблице на физическом уровне 3 файла!!! По индексу запросы работают по скорости почти как по PRIMARY KEY. А товарищ OR в таблицах с записями более 100000 работает около 3 мин и это факт!!!

 

[chira]

_RVK_

хорошо то, что он уже задумывается об возможных узких местах ...

serglt

По индексу запросы работают по скорости почти как по PRIMARY KEY

не нужно громких фраз, не всегда запросы по индексу работаю быстрее, бестолковые индексы могут тормозить ...

А товарищ OR в таблицах с записями более 100000 работает около 3 мин и это факт!!!

голое утверждение ничем не подкреплённое ...
если выполнить SELECT * FROM mytable WHERE id IN (20000,1000000)
где id - PRIMARY KEY
то он будет 3 минуты выполняться?

 

[_RVK_]

chira
Молодец что задумывается. Умнитца просто! Но вместо того, что бы написать простенький скриптик и сгенерировать таблицу с 20000 записями (гы, и это много?) и посмотреть, есть ли проблемма на самом деле, оценить её размер и прийти сюда с существующей проблемой, автор занимается гаданием на кофейной гуще.

 

[Роберт]

dimonbes
1) Забудь про LIKE и используй "полнотекстовый поиск" - это иделаьное решение твоей проблемы!!!
2) Если будешь использовать LIKE на базе в которой пол миллиона обьявлений - твой запрос на однопроцессорной машине будет обрабатываться менее чем за 5 секунд. Но такого количества обьявлений у тебя никогда не будет - ты ведь не будешь искать информацию за 5 лет (актуальность обьявлений не более двух недель). Так кто забудь о проблемах со скоростью!

 

[dimonbes]

_RVK_
Да, сейчас напишу, только больше 20000

Роберт
Буду надеятся!

Всем спасибо, буду тестировать.

 

[_RVK_]

Да, сейчас напишу, только больше 20000

Расскажешь потом на каком объеме у тебя появились проблеммы со скоростью?

 

[dimonbes]

_RVK_
А для чего же я тогда буду тестить?
Тут алгоритмы инсерта нужны, чтобы было поближе к действительности. Я выложу скрипты инсерта для критики. Только не раньше субботы, на работе зашился ******.