поиск по базе статей к кешированием. оцените решение

[simpex]

поиск по базе статей к кешированием. оцените решение

задача
есть база mysql выполненная в виде
datatable Myisam
id(int12) | name (varchar255) | content (text)

search_log
id, keyword,time

необходимо чтобы юзеры могли делать поиск по этой базе

сейчас сделал поиск вот так
пришли параметры в скрипт keyword,

делаем select * from datatable where upper(content) like upper('% keyword %') limit 0, 100
ограничили результаты поиска 100 результатами и нормально


ВОПРОС как можно еще делать поиск чтобы не связываться с UPPER?

делаю fetch all в переменную result
после чего
создаю делаю insert в таблицу search_log кейворда
получаю id записи

пихаю переменную result в файл с id записи с временем жизни час

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

viewsearch.php?sid=id записи


файл viewsearch пробует открыть файл кеша id
если все окей, тогда в зависимости от параметра

$_GET[page] по умлочанию 1

делаем


$max=count($result);
if(($_GET[page]*10+10)>$max){ $to=$max;}else{ $to=$_GET[page]*10+10;}

for ($i=$_GET[page] ; $i<$to; $i++){

выводим $result[$i]['content'];

}


вопрос

как можно еще оптимизировать такой поиск? чтобы выдержало 500 000 записей в data_table
и 50 000 обращений к ним в день
чего я забыл?

 

[HraKK]

У меня только один коментарий.....
ЫЫЫЫЫЫЫЫЫЫЫЫЫЫ, ОСЫПЬ ТРАВЫ!
Извините не сдержался.

 

[simpex]

а что не так?

 

[HraKK]

да мля все. Просто все. Не парься и используй FULLTEXT search.
Для твоего уровня хватит))

 

[Mr_Max]

как можно еще оптимизировать такой поиск?

Открой для себя EXPLAIN и страницы мануала относительно оптимизации SELECT запросов

upper(content)

Мало того, что данная констукция "тормозит" запрос, так она еще и не нужна поскольку
SELECT 'asdf' LIKE 'AsDf' > 1

чтобы выдержало 500 000 записей в data_table

LIKE - в лес к вОлкам.

 

[HraKK]

ВОПРОС как можно еще делать поиск чтобы не связываться с UPPER?

По секрету только тссс... База регистронечуствительная )) Тока тссс..

 

[Mr_Max]

Ы

И мне.

 

[HraKK]

Открой для себя EXPLAIN и страницы мануала относительно оптимизации SELECT запросов

Like начинающийся с % не использует индексов)

 

[Mr_Max]

HraKK
show create table он-же не показывал.

-~{}~ 04.04.08 02:23:

% не использует индексов)

Ага поетому

LIKE - в лес к вОлкам.

)

mysql> use test;
Database changed
mysql> SELECT VERSION();
+---------------------+
| VERSION()           |
+---------------------+
| 5.0.45-community-nt |
+---------------------+
1 row in set (0.01 sec)

mysql> set names cp1251;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW CREATE TABLE t22;
+-------+-----------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------+
| Table | Create Table

                       |
+-------+-----------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------+
| t22   | CREATE TABLE `t22` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `t` tinytext NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=cp1251 |
+-------+-----------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM `t22` WHERE t LIKE 'ASdf';
+----+------+
| id | t    |
+----+------+
|  1 | asdf |
|  2 | ASDF |
+----+------+
2 rows in set (0.00 sec)

 

[simpex]

хорошо

переделал запрос на

SELECT id, body, MATCH (title,body) AGAINST
-> ('кейворд') AS score
-> FROM articles WHERE MATCH (title,body) AGAINST
-> ('кейворд');

и сделал fulltext для этих полей как и прописывали в доке по мускулу

остальная теоритическая часть сделана правильно?



сейчас выходит что если юзер сменил параметр поиска, допустим сортировку вывода, то система делает новый поиск

 

[HraKK]

Не надо вообще ничего хранить в файлах. Работай с базой напрямую.

 

[simpex]

хм
в принципе можно
но я использую разбивку на страницы результата поиска

т.е. каждая страница выборки результаттов пользователю будет запросом?
SELECT id, body, MATCH (title,body) AGAINST
-> ('кейворд') AS score
-> FROM articles WHERE MATCH (title,body) AGAINST
-> ('кейворд') limit $begin,$end

где begin = page*10
eng (page+1)*10


т.е. 10 страниц 10 запросов
чет мне кажется для 50 000 запросов поиска в день по такой базе может не очень хорошо будет =(


а почему не использовать кеш в файлах?

 

[HraKK]

когда перестанет казаться - приходи

 

[simpex]

т.е. забить на кеш и брать данные из базы на лету?

а проблема с кешем связана с опрерацией чтения записи? и её ресурсоемкостью?