Представлены (http://www.postgresql.org/about/news.1296) два новых полезных приложения для PostgreSQL:- Pqc (http://code.google.com/p/pqc/) (PostgreSQL Query Cache) - система кэширования запросов к PostgreSQL, позволяющая увеличить производительность СУБД при большом объеме типовых запросов в десятки и даже сотни раз. Pqc работает (http://www.slideshare.net/uptimeforce/postgresql-query-cache...) в виде прокси, принимающего запросы от клиентов и транслирующего их к PostggreSQL, результат определенных SELECT-запросов при этом сохраняется в памяти и в случае поступления повторного запроса, если не истек таймаут, данные выдаются из локального кэша.
Поддерживается задание правил, какие запросы можно кэшировать, а какие нет. Также возможна настройка политики кэширования на основании длительности выполнения запроса или использовании в теле запроса специальных флаговых значений (команды передаются внутри комментария, например, "/* cache: refrash */ SELECT..." или "/* cache: on */...URL: http://www.postgresql.org/about/news.1296
Новость: http://www.opennet.me/opennews/art.shtml?num=29761
>результат определенных SELECT-запросов при этом сохраняется в памяти и в случае поступления повторного запроса, если не истек таймаут, данные выдаются из локального кэша.А если данные были изменены другим пользователем, - ждать таймаута?
Юзай оракле 11g, там есть result cache, который автоматом инвалидирует кеш запроса, если данные изменились.
Вопрос о Pqc а не Оракле.
Oracle под дулом пистолета не буду использовать, спасибо - намучался уже.
> Oracle под дулом пистолета не буду использовать, спасибо - намучался уже.Может, просто учил матчасть плохо? На курсы-то ходил? Доки курил?
сертификат мастера получил ?
>Поддерживается задание правил, какие запросы можно кэшировать, а какие нет. Также возможна настройка политики кэширования на основании длительности выполнения запроса или использовании в теле запроса специальных флаговых значений (команды передаются внутри комментария, например, "/* cache: refrash */ SELECT..." или "/* cache: on */ SELECT...").
>>Поддерживается задание правил, какие запросы можно кэшировать, а какие нет. Также возможна настройка политики кэширования на основании длительности выполнения запроса или использовании в теле запроса специальных флаговых значений (команды передаются внутри комментария, например, "/* cache: refrash */ SELECT..." или "/* cache: on */ SELECT...").В Оракле это существует более 20 лет и называется хинтами оптимизатора. Которые тоже являются псевдокомментариями. Вот и дошло за 20 лет до постгреса "нововведение", которое так давно сгнило, что даже не воняет уже.
> Вот и дошло за 20 лет до постгреса "нововведение", которое так давно сгнило, что даже не воняет уже.внешний кэш результатов не имеет к постгресу никакого отношения.
> В Оракле это существует более 20 лет [...] и дошло до постгреса
> "нововведение", которое так давно сгнило, что даже не воняет уже.Умеют же некоторые в одном предложении похвалиться чем-то, и тут же это обосрать до неузнаваемости - так "тонко" протроллить сразу обе стороны.
>> В Оракле это существует более 20 лет [...] и дошло до постгреса
>> "нововведение", которое так давно сгнило, что даже не воняет уже.
> Умеют же некоторые в одном предложении похвалиться чем-то, и тут же это
> обосрать до неузнаваемости - так "тонко" протроллить сразу обе стороны.Тут хвалиться нечем, собственно. Это действительно более 20 лет существует в Оракле. Но мы же в сторону проприетарщиков пилюем, у нас свой путь, особый. Велосипедами усыпанный густо.
> Тут хвалиться нечем, собственно. Это действительно более 20 лет существует в Оракле.
> Но мы же в сторону проприетарщиков пилюем, у нас свой путь,
> особый. Велосипедами усыпанный густо.Существует и что? Появление или отсутствие определённых инструментов само по себе ещё не характеризует систему в целом. А без примеров почему плохо/хорошо, в каких обстоятельствах и с какой целью - разговор бессмысленный.
>результат определенных SELECT-запросов при этом сохраняется в памяти и в случае поступления повторного запроса, если не истек таймаут, данные выдаются из локального кэша.Если честно бред какой то,
А кэширующий сквид - не бред? "Используй голову, Люк."
Товарищ не понял. Слово "бред" обычно используют, чтобы отмести идею, которая для произносящего это слово слишком сложна.
> Товарищ не понял. Слово "бред" обычно используют, чтобы отмести идею, которая для
> произносящего это слово слишком сложна.Тут предлагают заведомо писать кривое приложение для использования костыля.
И это БРЕД
> Тут предлагают заведомо писать кривое приложение для использования костыля.
> И это БРЕД"Заведомо" - требует аргументации. Ибо неочевидна заведомость.
> наглядные и интерактивные Flash-графикиИ неработающие, лол.
PostgreSQL Query Cache.Приветсвуем, ибо для многих небольших вебпроектов станет хорошей заменой мемкеша.
Pgwatch. Надо бы пощупать, что за зверь.
> Приветсвуем, ибо для многих небольших вебпроектов станет хорошей заменой мемкеша.каким образом ? по желанию клиента pqc внезапно перестанет хранить данные в мемкэше ?
> PostgreSQL Query Cache.
> Приветсвуем, ибо для многих небольших вебпроектов станет хорошей заменой мемкеша.Скорее не замена, а наоборот, простой способ внедрения, вместо написания соответсвующего расширения в слое абстракции работы с данными, которого может и не быть.
> Скорее не замена, а наоборот, простой способ внедрения, вместо написания соответсвующего расширения в слое абстракции работы с данными, которого может и не быть."соответствующее расширение" всё равно придётся написать, поскольку без него не будет инвалидации кэша. да, оно будет управлять поведением pqc, а не memcached, но это не значит "упрощение".
> "соответствующее расширение" всё равно придётся написать, поскольку без него не будет инвалидации
> кэша. да, оно будет управлять поведением pqc, а не memcached, но
> это не значит "упрощение".Не всегда есть доступ в логику приложения. По очень разным причинам. Ситуация к сожалению распространённая
Посмотрел внимательней.Первое - они сами хранят данные в мемкеше.
Второе - нельзя сбросить все кеши для одной таблицы таблицы.Короче не прокатывает... ((
> Короче не прокатывает... ((Тут изначально понятно, что оно для узкого применения.
Ну и проект, думаю, будет развиваться, если он кому-то нужен - можно им запрос отправить на фичу.
В смысле, а раньше БД этого не умели? Т.е. если я 50000 раз сделаю запрос "SELECT мне вон ту фиговину", то оно 50000 раз сделает одинаковый запрос к базе?
Это умеет не всякая БД. Только промышленные, имеющие SQL-кэш и кэш БД в розницу.
> Это умеет не всякая БД. Только промышленные, имеющие SQL-кэш и кэш БД
> в розницу.Интересно, вы не считаете постгрю промышленной БД ? имхо это зря ... Вполне работоспособное и качественная СУБД, наступающая на пятки "собственности Ларри" по возможностям. К счастью для народа купить её и положить под сукно нельзя - тут же выйдут форки
-
Я вот тоже использую оракле, но с потрохами очередной "империи зла" не продался, и там где возможно использую постгрю. Подумайте о том, что одна СУБД имеет перспективы, а используя другую - вы просто становитесь высокооплачиваемым и заточенным под определённую "мотыгу" рабом. И когда "такое" начинает ещё и превозносить свои цепи, это напоминает историю иудушки
-
Всё это конечно ИМХО, но думаю, что Оракл - хорошая СУБД - должно быть постепенно переработано, преодолено до появления достойных свободных альтернатив. Таков вектор, и именно такой альтернативой является постгря
> В смысле, а раньше БД этого не умели? Т.е. если я 50000
> раз сделаю запрос "SELECT мне вон ту фиговину", то оно 50000
> раз сделает одинаковый запрос к базе?У PostgreSQL очень развитый механизм кеширования. Но фишка кеширования в стороннем продукте через мемкеш - расширение кеша на кластер машин.
Для различных поисковых систем с поиском обновляющимся не в рилтайм очень удобная вещь