|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Sergey Tkachuk 2:5040/33.50 13 Feb 2001 21:27:00
To : Artem Chuprina
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
13 Фев 01 13:57, you wrote to me:
AC>>>>> А, у тебя не база данных, а DB. Так бы сразу и сказал. Просто
AC>>>>> сортировку и все необходимые пересечения нормальная СУБД сама
AC>>>>> делает. Она же в лучшем случае умеет OFFSET 40 LIMIT 20, в
AC>>>>> худшем - ну пропустишь ты 40 записей и вынешь следующие 20.
AC>>>>> Hафига еще что-то между запросами хранить?
ST>>>> И каждый раз делать запрос к базе? А если он дорогой (LIKE
ST>>>> '%some%', к примеру)?
AC>>> Там, где это дорого, кеширование уже на порядок дороже. За счет
AC>>> количества кешируемых запросов.
ST>> Честно говоря, не понял :-) Можешь объяснить чуть тщательнее?
AC> При какой загрузке у тебя реально начнет затыкаться база, если она не
AC> совсем по-идиотски спроектирована?
LIKE '%some%' работает долго независимо от нагрузки :-)
AC> Минимум при нескольких десятках в секунду.
AC> Сколько времени надо хранить кеши запросов? Минимум полчаса.
Зачем? Достаточно несколько минут (среднее время просмотра юзером одной
страницы).
AC> Сколько кешей надо одновременно хранить? Правильно, минимум малые
AC> тысячи.
Зависит от числа поисков. Для сайта, не являющегося поисковиком, это число не
так уж и велико.
AC> Операции на каждый кеш? Минимум - записать. Если по нему
AC> обратились - прочесть и сделать более легкий, но все же запрос к
AC> базе.
Он отработает на порядки быстрее. Ты забыл про такой параметр, как время
реакции.
AC> Базе станет легче, но начнет проседать сервер вообще
Серверу тоже станет легче. Причем тем легче, чем чаще юзер будет идти на вторую
и следующие порции.
AC> и хранилище кешей в частности.
Hет.
AC> Кстати, по той же самой причине, только в более
AC> полный рост, на поисковике не рекомендуется хранить открытые курсоры.
Еще раз. Это _не_ поисковик. Это сборище прайс-листов, доска объявлений или
еще что...
AC> Если у тебя запросов столько, что сервер проседает под LIKE '%some%',
AC> значит, задача вышла за те пределы, где можно обойтись таким запросом,
AC> и надо таки сделать по-человечески.
Он может проседать под LIKE '%some%', но вполне себе жить при =$queryID. Мало
того, что во втором поиске сработают индексы, так еще и таблица "кешей" не в
пример меньше.
А про "по-человечески"... Сколько человеко-лет надо на приличную систему
полнотекстного поиска?
Homer
---
* Origin: WWW.LOVEHATE.RU - ВЫСКАЖИСЬ! (2:5040/33.50)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
