|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/371.32 13 Feb 2001 21:16:00
To : Sergey Tkachuk
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
В твоём письме от Tue, 13 Feb 2001 18:05:13 +0300 написано:
AC>> При какой загрузке у тебя реально начнет затыкаться база, если она не
AC>> совсем по-идиотски спроектирована?
ST> LIKE '%some%' работает долго независимо от нагрузки :-)
mysql> select email from reader where email like '%ran.pp%';
...
13 rows in set (19.02 sec)
mysql> select count(*) from reader;
+----------+
| count(*) |
+----------+
| 596044 |
+----------+
Hе так уж долго для такой базы. Особенно если учесть, что подобный запрос
задается раз в неделю самое частое.
AC>> Минимум при нескольких десятках в секунду.
AC>> Сколько времени надо хранить кеши запросов? Минимум полчаса.
ST> Зачем? Достаточно несколько минут (среднее время просмотра юзером одной
ST> страницы).
Hу вот я и говорю "полчаса".
AC>> Сколько кешей надо одновременно хранить? Правильно, минимум малые
AC>> тысячи.
ST> Зависит от числа поисков. Для сайта, не являющегося поисковиком, это
ST> число не так уж и велико.
А для сайта, не являющегося поисковиком, обсуждаемый интерфейс вообще нафиг не
нужен.
AC>> Операции на каждый кеш? Минимум - записать. Если по нему
AC>> обратились - прочесть и сделать более легкий, но все же запрос к
AC>> базе.
ST> Он отработает на порядки быстрее. Ты забыл про такой параметр, как время
ST> реакции.
AC>> Базе станет легче, но начнет проседать сервер вообще
ST> Серверу тоже станет легче. Причем тем легче, чем чаще юзер будет идти на
ST> вторую и следующие порции.
AC>> и хранилище кешей в частности.
ST> Hет.
AC>> Кстати, по той же самой причине, только в более
AC>> полный рост, на поисковике не рекомендуется хранить открытые курсоры.
ST> Еще раз. Это _не_ поисковик. Это сборище прайс-листов, доска объявлений
ST> или еще что...
Hу и нафига ему интерфейс поисковика, если он не поисковик? Под поисковиком я
понимаю не альту с вистой, а нечто, обеспечивающее информативный поиск. Хотя
LIKE '%some%' на информативный поиск тянет с трудом, конечно...
AC>> Если у тебя запросов столько, что сервер проседает под LIKE '%some%',
AC>> значит, задача вышла за те пределы, где можно обойтись таким запросом,
AC>> и надо таки сделать по-человечески.
ST> Он может проседать под LIKE '%some%', но вполне себе жить при =$queryID.
ST> Мало того, что во втором поиске сработают индексы, так еще и таблица
ST> "кешей" не в пример меньше.
ST> А про "по-человечески"... Сколько человеко-лет надо на приличную систему
ST> полнотекстного поиска?
То, что эквивалентно по функциональности LIKE '%some%', но работает на порядок
быстрее, пишется за день, кабы не за полдня. Приличную, со словоформами -
дольше.
--
Artem Chuprina E-mail: ran@ran.pp.ru
Programmer FIDO: 2:5020/371.32
Memonet Ltd. Phone: +7-095-284-1356
--- slrn/0.9.6.3-as (Linux)
* Origin: AKA с подствольным плюсомётом (2:5020/371.32)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
