Вот что Вера в Святого Дельфина с людьми делает... Ни конфигурацию железа ведь не знает, ни настройки мыскля, а туда же --- "не более 3 миллисек". Слов нету, одни междометия.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
nick4
Guest
вообщем ситуация такая - я подумал и мне действительно нужны все эти колонки - любая другая комбинация только усложнит все (я уже и про крон, про отдельные файлы, про отдельную таблицу подумал) как ни крути - это самый оптимальный вариант, но при такой не реальной нагрузке - я не знаю что делать. что не так в индексах?
ONK
Пассивист PHPСluba
Sad Spirit, ты прав, про версию mysql надо было спросить в первую очередь. А упоминание о железе есть.
nick4, ради интереса приведи врямя инсерта типичной записи в таблицу с ~100к записями.
Индексы у тебя вобщем то правильные, но субд реально их почему то не использует. explain второго запроса честно об этом сообщает, а вот explain первого запроса врёт. Возможно дело в том, что индексы hits и uniq повреждены, сделай optimize.
Могу предпроложить что третий запрос выполняется ~ за 1мс.
Попробуй поменять тип столбца `char` на varchar(36).
nick4, ради интереса приведи врямя инсерта типичной записи в таблицу с ~100к записями.
Индексы у тебя вобщем то правильные, но субд реально их почему то не использует. explain второго запроса честно об этом сообщает, а вот explain первого запроса врёт. Возможно дело в том, что индексы hits и uniq повреждены, сделай optimize.
Могу предпроложить что третий запрос выполняется ~ за 1мс.
Попробуй поменять тип столбца `char` на varchar(36).
nick4
Guest
нет, за один запрос я использую комбинации всех трех колонок.
попробую сейчас
во втором explain их быть не должно - потому что по рекомендации Фаната я кильнул индекс на hits временно, но честно-говоря не понял лучше или хуже стало..
Версия MySQL пробовал 4 сейчас 3.23
nick4
Guest
Обратно поставили 4.0.18
поставил индекс на колонку hits
оптимизировал таблицу
итог - совершенно не предсказуемый
жму F5 - скорость запроса
0.5sec (select char) + 0.5sec (update) + 7sec (select by hits limit 20)
еще раз F5 -
6.027sec + 6.247sec + 2.843sec
ничего не понимаю..
поставил индекс на колонку hits
оптимизировал таблицу
итог - совершенно не предсказуемый
жму F5 - скорость запроса
0.5sec (select char) + 0.5sec (update) + 7sec (select by hits limit 20)
еще раз F5 -
6.027sec + 6.247sec + 2.843sec
ничего не понимаю..
SelenIT
IT-лунатик :)
Аргументы за то, чтобы вынести поле char в отдельную таблицу и связывать с существующей таблицей по id (исходя из моих знаний о предмете):
1) в "основной" таблице не будет полей переменной длины, тормозящих поиск;
2) все индексы первой таблицы будут числовыми, т.е. быстрыми;
3) одинаковые слова могут быть запрошены с разных поисковиков - налицо отношение "один ко многим". В старой структуре значения запросов дублировались, в новой не будут (экономия места).
Жду аргументов против (или наводящей отсылки в ман, если в корне неправ
)
1) в "основной" таблице не будет полей переменной длины, тормозящих поиск;
2) все индексы первой таблицы будут числовыми, т.е. быстрыми;
3) одинаковые слова могут быть запрошены с разных поисковиков - налицо отношение "один ко многим". В старой структуре значения запросов дублировались, в новой не будут (экономия места).
Жду аргументов против (или наводящей отсылки в ман, если в корне неправ
)ONK
Пассивист PHPСluba
SelenIT, соотношение запросов на вставку записей и запросов на выборку наверняка ~ 1000 к 1. Поэтому скорость вставки очень критична.
Для того чтобы поддерживать работу со структурой из двух таблиц надо перед добавлением новой записи в таблицу сязей делать дополнительный запрос в таблицу слов, а вероятно ещё и третий запрос на добавление новых слов в эту таблицу. А это многократно затормозит процесс вставки новых данных.
Вполне возможно, что имеет смысл создать дополнительно 2 таблици для длительного хранения данных и раз в день конвертировать данные из таблици накопления в таблицы длительног хранения.
nick4, расскажи что и как ты замеряеш,, подробнее.
Для того чтобы поддерживать работу со структурой из двух таблиц надо перед добавлением новой записи в таблицу сязей делать дополнительный запрос в таблицу слов, а вероятно ещё и третий запрос на добавление новых слов в эту таблицу. А это многократно затормозит процесс вставки новых данных.
Вполне возможно, что имеет смысл создать дополнительно 2 таблици для длительного хранения данных и раз в день конвертировать данные из таблици накопления в таблицы длительног хранения.
nick4, расскажи что и как ты замеряеш,, подробнее.
О, наконец-то начало доходить.
-~{}~ 30.09.04 11:39:
остался невыясниннем только вопрос, такое ли именно соотношение, или, все же, 1 к одному.
уж очень странный ам этот селект с лимитом.
то ли он нужен на странице с хитом, то ли на странице со статистикой.
А автор молчит, как партизан
-~{}~ 30.09.04 11:39:
остался невыясниннем только вопрос, такое ли именно соотношение, или, все же, 1 к одному.
уж очень странный ам этот селект с лимитом.
то ли он нужен на странице с хитом, то ли на странице со статистикой.
А автор молчит, как партизан
nick4
Guest
соотношение запросов на вставку записей и запросов на выборку 1 к 100
-~{}~ 30.09.04 21:44:
я кажется нашел решение:
может каждые 3-4 часа экпортировать всю таблицу (ну или какую-то часть) в текстовый файл и работать уже с ним?
что если брать такой файл ~50k строк, делать при каждом запросе shuffle и выбирать рэндомные первые 20 слов?
насколько я знаю апач кэширует файлы к которым делается частое обращение, не будет ли это сильно напряжным?
именно
да, но какой смысл? выборка то будет идти по таблице длительно хранения, а это также тормознуто как и в основном варианте
на странице с хитом
-~{}~ 30.09.04 21:44:
я кажется нашел решение:
может каждые 3-4 часа экпортировать всю таблицу (ну или какую-то часть) в текстовый файл и работать уже с ним?
что если брать такой файл ~50k строк, делать при каждом запросе shuffle и выбирать рэндомные первые 20 слов?
насколько я знаю апач кэширует файлы к которым делается частое обращение, не будет ли это сильно напряжным?
SelenIT
IT-лунатик :)
ONK
nick4
Вообще, какой у тебя алгоритм обсчета хита? Похоже, можно и нужно оптимизировать его...
Ну и что? Выборка по одному полю, если на нем построен индекс подходящей длины, по-моему, много времени не займет, а вставка в таблицу из одних чисел ускорится в разы. Не исключено, что эти три запроса будут в сумме быстрее, чем один нынешний инсерт. Тем более, что перестройка строкового индекса будет не при каждом хите и по-любому для меньшей таблицы, чем сейчас.
nick4
Именно так? Не наоборот? Тогда, имхо, критична как раз скорость выборки...
Фанат, насколько я понял, советовал в точности наоборот - писать в текстовый файл именно текущие записи (не трогая базу), а время от времени скопом перегонять их в таблицу.
Вообще, какой у тебя алгоритм обсчета хита? Похоже, можно и нужно оптимизировать его...