|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Sergey Tkachuk 2:5040/33.50 14 Feb 2001 14:45:00
To : Artem Chuprina
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
13 Фев 01 20:16, you wrote to me:
AC>>> При какой загрузке у тебя реально начнет затыкаться база, если
AC>>> она не совсем по-идиотски спроектирована?
ST>> LIKE '%some%' работает долго независимо от нагрузки :-)
mysql>> select email from reader where email like '%ran.pp%';
AC> ...
AC> 13 rows in set (19.02 sec)
mysql>> select count(*) from reader;
AC> +----------+
AC> | count(*) |
AC> +----------+
AC> | 596044 |
AC> +----------+
AC> Hе так уж долго для такой базы.
Ты готов заставить юзера ждать по 20 секунд на каждое обращение в следующей
порции?
AC> Особенно если учесть, что подобный запрос задается раз в неделю
AC> самое частое.
См. ниже.
AC>>> Минимум при нескольких десятках в секунду.
Ты как-то сам себе противоречишь...
AC>>> Сколько времени надо хранить кеши запросов? Минимум полчаса.
ST>> Зачем? Достаточно несколько минут (среднее время просмотра юзером
ST>> одной страницы).
AC> Hу вот я и говорю "полчаса".
Процент таких тормозных юзеров невелик. И как раз им-то подождать лишние 20
секунд (если их кеш проэкспайрился) совсем не страшно :-)
AC>>> Сколько кешей надо одновременно хранить? Правильно, минимум малые
AC>>> тысячи.
ST>> Зависит от числа поисков. Для сайта, не являющегося поисковиком,
ST>> это число не так уж и велико.
AC> А для сайта, не являющегося поисковиком, обсуждаемый интерфейс вообще
AC> нафиг не нужен.
Hу не знаю. Меня почти всегда просят, чтобы был поиск. По прайсу, к примеру,
или в объявлениях...
AC>>> Кстати, по той же самой причине, только в более
AC>>> полный рост, на поисковике не рекомендуется хранить открытые
AC>>> курсоры.
ST>> Еще раз. Это _не_ поисковик. Это сборище прайс-листов, доска
ST>> объявлений или еще что...
AC> Hу и нафига ему интерфейс поисковика, если он не поисковик? Под
AC> поисковиком я понимаю не альту с вистой, а нечто, обеспечивающее
AC> информативный поиск. Хотя LIKE '%some%' на информативный поиск тянет с
AC> трудом, конечно...
С поиском "Celeron 300" такая вещь справляется на ура.
AC>>> Если у тебя запросов столько, что сервер проседает под LIKE
AC>>> '%some%', значит, задача вышла за те пределы, где можно обойтись
AC>>> таким запросом, и надо таки сделать по-человечески.
ST>> Он может проседать под LIKE '%some%', но вполне себе жить при
ST>> =$queryID. Мало того, что во втором поиске сработают индексы, так
ST>> еще и таблица "кешей" не в пример меньше.
ST>> А про "по-человечески"... Сколько человеко-лет надо на приличную
ST>> систему полнотекстного поиска?
AC> То, что эквивалентно по функциональности LIKE '%some%', но работает на
AC> порядок быстрее, пишется за день, кабы не за полдня.
Общий принцип опиши, плиз. Вот и будет от спора польза.
AC> Приличную, со словоформами - дольше.
_Значительно_ дольше.
Homer
---
* Origin: WWW.LOVEHATE.RU - ВЫСКАЖИСЬ! (2:5040/33.50)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
