Теоретические ответы (типо сейвить в файлы и т д ) конечно же хорошо, но хотелось бы услышать тех кто сталкивался на практике.
Немного поясню - под сервером понимается удалённая машина на котороый расположена база постгрес, под клиентом - сервер на котором крутится сайт.
Спустя 1 час, 40 минут, 46 секунд (18.05.2012 - 18:14) vagrand написал(а):
Конечно возможно и тут без разницы какой у тебя сервер БД постгрес или мускуль или еще что-то.
Спустя 13 минут, 32 секунды (18.05.2012 - 18:27) vital написал(а):
memcached.
В чем проблема то?
Сервер с мемкешм может быть где угодно. В конфиге ип указываете и все..
В чем проблема то?
Сервер с мемкешм может быть где угодно. В конфиге ип указываете и все..
Спустя 1 час, 47 минут, 50 секунд (18.05.2012 - 20:15) sergeiss написал(а):
А в чем вообще задача, почему возник вопрос о кэшировании запросов в постгре?
PS. Я так понимаю, стоит вопрос о производительности запросов. Но что именно надо получить, с чем проблемы?
PS. Я так понимаю, стоит вопрос о производительности запросов. Но что именно надо получить, с чем проблемы?
Спустя 5 часов, 11 минут, 32 секунды (19.05.2012 - 01:26) Guest написал(а):
Есть огромный сервер с озвученной ранее бд. Помимо моего сервера к нему еще цепляются эдак 40 серверов и 1000 клиентских машин. Запросы в эту БД на моем сервере достаточно долго выполняются, но они как правило однообразные, плюс посещаемость ресурса приличная.
Посмотрел в сторону memcached - попробую использовать, но боюсь придется перелопатить львиную долю кода. Хотелось бы минимального вмешательства в текущий функционал, аля как это организованно в pqc - добавлением в SQL запрос комментария что-то вроде "*/cache: enable, 1min/* SELECT * FROM table" но там как я понял нужен работающий демон на бэкэнде, а доступа у меня туда нет.
Посмотрел в сторону memcached - попробую использовать, но боюсь придется перелопатить львиную долю кода. Хотелось бы минимального вмешательства в текущий функционал, аля как это организованно в pqc - добавлением в SQL запрос комментария что-то вроде "*/cache: enable, 1min/* SELECT * FROM table" но там как я понял нужен работающий демон на бэкэнде, а доступа у меня туда нет.
Спустя 8 часов, 41 минута, 30 секунд (19.05.2012 - 10:08) vagrand написал(а):
Все таки вам придется лопатить ваш код. Но если запросов у вас не много то и лопатить много не придется.
Спустя 1 час, 36 минут, 39 секунд (19.05.2012 - 11:45) sergeiss написал(а):
| Цитата (Guest @ 19.05.2012 - 02:26) |
| Запросы в эту БД на моем сервере достаточно долго выполняются, |
"Долго" - это сколько? 0.5 сек, минуту или сколько?
Спустя 37 минут, 13 секунд (19.05.2012 - 12:22) S1lent написал(а):
в среднем 3-5 сек.
Спустя 2 часа, 3 минуты, 22 секунды (19.05.2012 - 14:25) sergeiss написал(а):
| Цитата (S1lent @ 19.05.2012 - 13:22) |
| в среднем 3-5 сек. |
Ты знаешь... За 3-5 секунд у меня в Постгресе выполняется выборка из нескольких многомиллионных (сотни миллионов записей) таблиц, затем еще несколько - всего по 9 параметрам. По каждому параметру - свои критерии. В каждом таком подзапросе несколько уровней вложенности. Затем они джойнтся. На выходе - порядка 50-100 записей. И всё это за 3-5 секунд. И всё это - внутри Постгре, в ПХП передается только готовый результат выборки.
Короче говоря, тебе надо оптимизировать БД. Возможно, использовать partitions. И, однозначно, правильные индексы.
Спустя 8 часов, 6 минут, 6 секунд (19.05.2012 - 22:31) S1lent написал(а):
Постгрес база крупного провайдера которая занимает несколько серверов и на конторой стоит топовое железо причем далеко не 1 железка и которую админят далеко не дураки. Нет, дело не в оптимизации. Да, запросы сложные, 3 уровня вложенности, процедуры и джоины.
Спустя 34 минуты, 4 секунды (19.05.2012 - 23:05) sergeiss написал(а):
| Цитата (S1lent @ 19.05.2012 - 23:31) |
| Нет, дело не в оптимизации. |
Покажи образец запроса, который у тебя выполняется дольше, чем ты считаешь нужным. И покажи структуру таблиц, задействованных в этих выборках, включая индексы, триггеры, view, разбивку на patritions, если она делалась - короче говоря, всё значимое для этих выборок.
| Цитата (S1lent @ 19.05.2012 - 23:31) |
| ...и которую админят далеко не дураки |
Никто и не говорит, что они дураки
Но "админят БД" и "оптимизируют БД" - это разные вещи. Причем очень разные.Я тебе даже вот что скажу. От порядка столбцов в индексе скорость выполнения выборки может изменяться в разы! Проверено самолично. Потратил как-то много времени, пару лет назад, чтобы это проверить. Делал разные индексы, только меняя порядок указания столбцов в индексе. Один индекс удалял, делал другой. И "гонял" многократно один и тот же запрос. Разница была заметна.
Да, и это было как раз с БД Постгре, с коей я работаю уже более 4-х лет. И выборки у меня нередко очень "тяжелые" получаются. Так что с вопросами оптимизации знаком не понаслышке, хотя все равно постоянно нахожу что-то новое.
Спустя 2 дня, 9 часов, 37 минут, 27 секунд (22.05.2012 - 08:43) sergeiss написал(а):
Ну так и чего - где данные для анализа: образец запроса, структура таблиц... Не видно их чегой-то.
Спустя 4 часа, 35 минут, 11 секунд (22.05.2012 - 13:18) S1lent написал(а):
Вы знаете, просто нет желания и времени описывать всю структуру бд, хранимые процедуры и т д, потому как повторюсь, c базой работают знающие люди уже не один год (в т.ч. естественно оптимизирующие её). Для себя я решил чётко - необходимо кэширование на стороне моего сервера, остался вопрос в реализации наименьшими усилиями.
Типовой запрос примерно такой. Естественно из него что-то понять очень сложно т.к. процедуры я тут не привожу т.к. они занимают гораздо больше строк.
Типовой запрос примерно такой. Естественно из него что-то понять очень сложно т.к. процедуры я тут не привожу т.к. они занимают гораздо больше строк.
SELECT *,
get_key_vid(key, value) AS deal, get_str_readable(objkey) AS object,
CASE WHEN GetTypeMem(objtype) = 'region' THEN get_str_readable(objkey) ELSE get_mdep(objkey, GetObTypeID('region'), 2) END AS name,
get_mdep(objkey, GetObTypeID('region'), 1) AS region_id,
'' AS house_key,
CAST (((get_sobject_comment(key)).comment) AS TEXT) AS lst_comment,
COALESCE((get_sobject_comment(key)).cdate, CAST('1970-01-01' AS timestamp)) AS lst_comment_date
FROM
get_sobj_new_filters('$obj', GetObjTypeID('tt'), 10, TRUE, TRUE, '', -1, FALSE, '$get_date'::date, TRUE , '$get_date'::date, FALSE, '', FALSE)
ORDER BY create_date DESC OFFSET 0
Спустя 2 часа, 20 минут, 36 секунд (22.05.2012 - 15:39) sergeiss написал(а):
| Цитата (S1lent @ 22.05.2012 - 14:18) |
| Для себя я решил чётко - необходимо кэширование на стороне моего сервера, остался вопрос в реализации наименьшими усилиями. |
Ну что ж... "Хозяин - барин" (с) - народная мудрость
| Цитата (S1lent @ 22.05.2012 - 14:18) |
| процедуры я тут не привожу т.к. они занимают гораздо больше строк. |
Так, может, тут-то и проблема, что процедуры "тормозят"? Хотя бы одна будет неоптимальна и всё затормозит.
| Цитата (S1lent @ 22.05.2012 - 14:18) |
| повторюсь, c базой работают знающие люди уже не один год (в т.ч. естественно оптимизирующие её) |
На самом деле, в понятие "оптимизация БД" входит и создание таких индексов, про которые спецы этой БД могут просто не знать (не догадываться об их необходимости) (!). Причина - ты пишешь запрос и тебе надо сделать так, чтобы именно этот важный запрос выполнялся быстро. Используя EXPLAIN можно понять, что (возможно) существующие индексы не годятся, т.к. они просто не используются.
Например, мне пришлось для некоторых таблиц создавать "частичные индексы" (вроде так называется), чтобы быстрее выполнять определенные запросы.