|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/371.32 13 Feb 2001 14:57:02
To : Sergey Tkachuk
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
В твоём письме от Mon, 12 Feb 2001 15:05:09 +0300 написано:
AC>>>> А, у тебя не база данных, а DB. Так бы сразу и сказал. Просто
AC>>>> сортировку и все необходимые пересечения нормальная СУБД сама
AC>>>> делает. Она же в лучшем случае умеет OFFSET 40 LIMIT 20, в худшем
AC>>>> - ну пропустишь ты 40 записей и вынешь следующие 20. Hафига еще
AC>>>> что-то между запросами хранить?
ST>>> И каждый раз делать запрос к базе? А если он дорогой (LIKE
ST>>> '%some%', к примеру)?
AC>> Там, где это дорого, кеширование уже на порядок дороже. За счет
AC>> количества кешируемых запросов.
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
