|
MySQL.RU - Webboard
 Вернуться
 прикольный ресурс (Dinky) 18/07/2005 - 19:49:38
 Re: LOAD DATA INFILE extended in MySQL 5.0 (Dinky) 18/07/2005 - 19:55:27
Re: LOAD DATA INFILE extended in MySQL 5.0 (walrus) 18/07/2005 - 20:44:30
Re: О "проблеме" LIKE "%bla%" (Dinky) 18/07/2005 - 20:45:06
> Original message text:
> From: Dinky - 18/07/2005 - 19:49:38
> Subject:прикольный ресурс
> -----------------
> http://www.planetmysql.org/
> "This is an aggregation of unofficial blogs from MySQL developers and users."
>
> ща запощу пару заметок в собственном перводе :)
> --
> Dmitry
>
>
From: Dinky - 18/07/2005 - 20:45:06
Subject:О "проблеме" LIKE "%bla%"
-----------------
http://www.livejournal.com/users/arjen_lentz/31195.html
Разбирается пример анализа траффика - многомиллиoнная табличка MyISAM с полем varchar и запросы вида:
SELECT COUNT(*) AS cnt FROM hits WHERE useragent LIKE "%Mac%"
SELECT COUNT(*) AS cnt FROM hits WHERE useragent LIKE "%Linux%"
SELECT COUNT(*) AS cnt FROM hits WHERE useragent LIKE "%Win%"
понятное дело, куча проблем в "консерватории", но попытаемся разобрать жалобу - "запрос выполняется несколько секунд и загружает процессор на 100%".
Конечно же LIKE не использует индексы, поэтому сервер читает всю таблицу. И это не проблема, но факт, который следует учитывать. Возможно ли использование FULLTEXT индекса? Вряд ли, т.к. нет отдельных слов, по которым можно было бы строить словарь.
Раз уж мы читаем всю таблицу, надо попытаться уменьшить работу с диском, а именно:
1) сделать строки как можно короче
2) читать данные как можно бОльшими кусками за раз
Для MyISAM это можно сделать так:
SET SESSION read_buffer_size=26214400 (около 25MB)
Сделаем это только для нашей сессии, иначе такой буффер будет создаваться для каждого соединения и оперативная память закончится очень быстро.
Тут мы подходим к моменту "100% загрузка процессора". При активной работе с диском этого вобщем-то не должно быть - процессор ждет дисковую систему, а не наоборот. Такое правда случается на "плохих сборках" (bad threading libraries), но в нашем случае ответ оказался проще - пользователь установил значение read_buffer_size на GLOBAL уровне. Память быстро закончилась и ОС свопилась как бешенная! Так что прежде чем разбираться с какой-либо проблемой, убедитесь, что сервер не свопится в это время. Кстати, не такая простая задача, если на сервере стоят и mysql и apache.
Как только "проблема" была устранена, запросам заметно полегчало. Но выполнять на каждый параметр по запросу - это уж слишком, почему бы не сделать все сразу:
SELECT SUM(IF(useragent LIKE "%Mac%",1,0)) AS Mac,
SUM(IF(useragent LIKE "%Linux%",1,0)) AS Linux, ....
FROM hits
все равно надо прочитать всю таблицу ;-)
И незачем использовать WHERE - с ним будет даже медленее (WHERE нужно только для _уменьшения_ числа строк, отдаваемых серверу для анализа, а в нашем случае надо проверить все)
Кто-нибудь спросит - a имеет смысл скопировать данные в MEMORY table и там их анализировать?
Ответ - если вам на самом деле не надо выполнять много _разных_ запросов на одни и те же данные, то сервер будет делать больше пересылок данных, так что - нет.
И как это будет на InnoDB? Ну, убедитесь, что innodb_buffer_pool достаточно большой (нет особой нужды подкручивать read_buffer_size), и, опять, надо бы сделать строки как можно короче.
Но! MyISAM гораздо больше подходит для такого рода задач как datawarehousing - он был создан для этого.
Ну и последнее, что остается открытым для обсуждения - не лучше ли делать разбор данных на момент их поступления и записывать в базу уже в удобоваримом для последующего анализа виде. А оригинальные строки записывать в лог-файл.
--
Dmitry
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
23089
|
|
