Модуль Apache mod_libpq

>все работы по генерации странички и заголовков HTTP вынесены в PostgreSQL и как следствие возможна работа без внешних скриптов.

а какие в PostgreSQL есть средства генерации, обрабоки и анализа текста?

Звучит очень приятно. В ближайшее время постараюсь попробовать.

>а какие в PostgreSQL есть средства генерации, обрабоки и анализа текста?

Генератор текста в PostgreSQL, звучит...

PL/Perl

это что - типа сквид с постгрес бэкэндем ?

> а какие в PostgreSQL есть средства генерации, обрабоки и анализа текста?

Проще перечислить каких нет. Хранимые процедуры в Postgres можно писать на
1. Любом компилируемом в нативный код языке (C, C++ etc)
2. PL/pgSQL
3. Perl
4. Tcl
5. Python
6. Java

Может что еще забыл из того что в 8.1 появилось.

Напоминает OWA очень сильно :-)

>это что - типа сквид с постгрес бэкэндем ?

хм, нет, допустим крутится у тебя бд танков, увеличителей [CENSORED] :) ну т.д. на PostgreSQL, есть Apache и mod_libpq, все! Для того что-бы выложить это для всеобщего обозрения больше ничего не надо. Не нужна скриптовая часть (PHP, CGI..) Понятно?

>Для того что-бы выложить это для всеобщего обозрения больше ничего не надо. Не нужна скриптовая часть (PHP, CGI..) Понятно?

я тоже так подумал, поэтому спросил: "а какие в PostgreSQL есть средства генерации, обрабоки и анализа текста?"

а народ не в курил и начали мне дружно перечислять эти самые СКРИПТОВЫЕ ЯЗЫКИ - от которых как раз и нужно избавится. Зачем мне Perl, Tcl, Python, Java - если я как раз с помощью mod_libpq пытаюсь от них избавиться?

ТО есть либо автор новости всех запутал, либо mod_libpq совершенно бесполезный элемент.

> а какие в PostgreSQL есть средства генерации, обрабоки и анализа текста?

А какие угодно. Тикль, перл, питон, си...

> Не нужна скриптовая часть (PHP, CGI..)

э нет - просто скриптовая часть переносится внутрь постгреса. в общем стоит приглядеться - это типа postgress on rails
:)

> а народ не в курил и начали мне дружно перечислять эти самые СКРИПТОВЫЕ ЯЗЫКИ - от которых как раз и нужно избавится.

Ты о них избавляешься как от отдельных скриптов. mod_libpq вызывает _хранимую_процедуру_, вот её и можно написать на любом языке.

> Зачем мне Perl, Tcl, Python

Это не чистые перл, питон,... Это PL/Perl, PL/Python, PL/tcl,...

ТО есть получается скрипты всё таки остаються? и вместо apache<->script<->sql, мы получаем apache<->sql<->script

и что в результате? памяти жрется столькоже + глюки mod_libpq, хотя может быстродействие повышается?

Как я понимаю, работа с БД становится прозрачной и нативной.

Объясните мне, идиоту, зачем этот мутант может быть нужен или полезен ?

1) По скорости отдача из БД будет на порядок медленнее чем отдача из закэшированного файла с локального диска 2) По гибкости это не сравнить со скриптовым языком, который точно так же может залезть в postgre 3) По конфигурации - любое ее изменение будет требовать перезапуска apache, хотя бы и gracefull

Нахуа весь этот гемор ?

Экономия коннектов к базе - как вариант

> Экономия коннектов к базе - как вариант

И как же это они экономятся ?

Любой скриптовый язык имеет поддержку persistent connection, т.е. один apache процесс - одно соединение до базы. В случае нашего мутантика, имхо, то же самое

думаю, плюс в том, что не нужно будет переводить структуры из БД в структуры языка. Переводить явно. Сабж это примерно то же, что писать для веб на Oracle DBMS+PL/SQL+Oracle Web Server. Только вместо PL/SQL мы имеем целый набор языков, можно выбирать какой удобнее (тот же питон/перл).

ЗЫ Я ОЧЕНЬ надеюсь, что туда не влепят пых-пых.

от перемены мест слогаемых, сумма не изменяется. Просто увеличивается вероятность неработоспособности сайта из за падения СУБД. ИМХО. Весчь сама в себе и явно не для продуктива.

Вот чего не могу понять - так это почему-таки pl/pgsql никак не сделают нормальным, если уж тащат идеологию с оракла - перетащили бы синтаксис, а то сплошной кошмар....

> 1) По скорости отдача из БД будет на порядок медленнее чем отдача из закэшированного файла с локального диска

По скорости отдача из БД будет _быстрее_, чем из файла с локального диска (при правильном дизайне базы). За счет кеширования базой. А статический контент никто не мешает отдавать как обычно.

> 2) По гибкости это не сравнить со скриптовым языком, который точно так же может залезть в postgre

Имеется мнение, что отдельному скрипту придется совершить больше телодвижений, чтобы залезть в базу, а хранимой процедуре не надо устанавливать соединение и развлекаться с ним. Не говоря уже о том, насколько сокращается обмен данными: одно дело -- выполнить из скрипта пяток запросов, совсем другое -- сделать все в пределах одной процедуры на сервере.

> 3) По конфигурации - любое ее изменение будет требовать перезапуска apache, хотя бы и gracefull

Это какие "изменения конфигурации"? Адрес сервера? А чем тебе не нравится graceful? Текущие сессии доработают без вопросов.

> Нахуа весь этот гемор ?

Это не "гемор", это просто немного другой подход. Тем, у кого и так бизнес-логика в базе, может быть полезно. Мы хотели писать нечто подобное сами, сейчас смотрим на этот модуль.

>По скорости отдача из БД будет на порядок медленнее чем отдача из закэшированного файла с локального диска

Заблуждение. Если имеется в виду отдача через скрипт, конечно, статика всегда отдаётся быстрее. Точных цифр сейчас не помню, но года два назад, выбирая метод хранения plain-text данных, бенчил под реальными нагрузками. Выдача необработанного текста размером в несколько килобайт из MySQL-базы в несколько раз быстрее, чем выдача из plain-text файла с ext3.

Что-то я недопонял, товарищ хотител скзать, что если я свою 6и гиговую конторскую базу в plain-text переведу, немыслимым для меня способом ее "закешу", то она будет быстрее работать? Прям новый концепт какой-то...

>> 1) По скорости отдача из БД будет на порядок медленнее чем отдача из закэшированного файла с локального диска

>По скорости отдача из БД будет _быстрее_, чем из файла с локального диска (при правильном дизайне базы). За счет кеширования базой. А статический контент никто не мешает отдавать как обычно.

Выпей яду. Или сделай табличку на пару десятков записей, и статический файл на пару килобайт, и проведи benchmark. Я ответственно заявляю, что VFS cache будет быстрее в данном примере.

>> 2) По гибкости это не сравнить со скриптовым языком, который точно так же может залезть в postgre

>Имеется мнение, что отдельному скрипту придется совершить больше телодвижений, чтобы залезть в базу, а хранимой процедуре не надо устанавливать соединение и развлекаться с ним.

Про какие телодвижения речь, не очень понимаю ? Соединение в случае mod_libpq и в случае скрипта можно использовать постоянное. Формирование запроса и чтение ответа нужно делать и там и там. А вот перекладывать логику вывода данных со скриптового web языка на PL/SQL это кхе-кхе.. неудобно, в общем.

>Не говоря уже о том, насколько сокращается обмен данными: одно дело -- выполнить из скрипта пяток запросов, совсем другое -- сделать все в пределах одной процедуры на сервере.

И насколько же он сокращается ? Кто мешает вызвать эту процедуру из скрипта ?

> Что-то я недопонял, товарищ хотител скзать, что если я свою 6и гиговую конторскую базу в plain-text переведу, немыслимым для меня способом ее "закешу", то она будет быстрее работать? Прям новый концепт какой-то...

Не надо передергивать. Я имел ввиду, что все частые выборки подлежат кэшированию. Ведь, с помощью mod_libpq можно производить только выборки, не так ли ?

это цитата с оригинального сайта разработчика, перевести?

http://asmith.id.au/mod_libpq.html
A much faster solution was developed using the Apache 1.3 module API. An Apache module can establish persistent connections with the PostgreSQL databases driving the web application and the database backends. It takes a little more setting up and uses a few more resources than a CGI script, but the results are definitely worth it. Now the server can deliver millions of different dynamic pages at least as fast as if they were stored as static files in an advanced file system.

>> А статический контент никто не мешает отдавать как обычно.

> Выпей яду.

Читать мы явно не умеем?

> Про какие телодвижения речь, не очень понимаю ?

Лишних.

> перекладывать логику вывода данных со скриптового web языка на PL/SQL это кхе-кхе.. неудобно, в общем.

Где удобно его, там PL/pgSQL, в другом месте удобней окажется PL/Perl или PL/Python , а кому-то может оказаться удобней сделать все на любом компилируемом языке и подключить необходимые функции. Это ведь Postgres, его очень удобно расширять под задачу.

> Кто мешает вызвать эту процедуру из скрипта ?

А зачем нам оверхед на второй скрипт и его интерпретатор? Начали с

> клиент <-(запрос)-> apache <-(запрос)-> скрипт <-(куча запросов)-> база.

прошли через

> клиент <-> apache <-> скрипт <-(один запрос)-> база+процедуры.

логично завершили, выкинув лишнюю сущность на

> клиент <-> apache <-> база+процедуры.

> Ведь, с помощью mod_libpq можно производить только выборки, не так ли ?

Выполнение хранимой процедуры, внутри себя она много что может делать.

>> Ведь, с помощью mod_libpq можно производить только выборки, не так ли ?

>Выполнение хранимой процедуры, внутри себя она много что может делать.

Формирование web страницы на PL/SQL это убожество. Имхо, такой отказ от скриптов в пользу производительности возможен лишь для очень специфических задач.

>Что-то я недопонял, товарищ хотител скзать, что если я свою 6и гиговую конторскую базу в plain-text переведу, немыслимым для меня способом ее "закешу", то она будет быстрее работать? Прям новый концепт какой-то...

Ну, про такое-то в зравом уме, полагаю, никто и сравнивать не будет :D Я думал он про тупую (без запросов) выдачу текстового файла. Т.е. в сравнении файл по имени выдать скриптом, или его же, но простым select'ом из БД.

Так вот, даже в таком случае, БД оказывается быстрее даже на единичном числе файлов.

> Что-то я недопонял

Речь про то, что

---
$arr_ref = selectall_arrayref("select text from table");
print join " ", map { join " ", @$_ } @{arr_ref};
---

будет намного быстрее, чем

---
foreach $name (@fnames) {
    open FILE, $name;
    print <FILE>;
    close FILE;
}
---

>И как же это они экономятся ?

ты бы хоть почитал как хранятся и обрабатывются ф-ции в постгри

>вывода данных со скриптового web языка на PL/SQL это кхе-кхе.. неудобно,

ну так используй свой любимый PL\php долбодятел. кто тебе мешает

В итоге получаем:

1) Гораздо более быстрый доступ к данным из бизнес-логики, формирующей страницу, чем более "мелкие" запросы используются - тем больший прирост в скорости формирования по сравнению с традиционным подходом.

2) Framework lock-in, так как приложение завязывается жестко на постгрес.

PS. Каждый выбирает для себя...

Идея хорошая, но написано из рук вон плохо. 1) Подключение производится из КАЖДОГО Apache child. А это означает, что при N серверах и M процессах Apache получится N * M подключений к серверу.

Проще говоря: при более-менее серьезной посещаемости ляжет все вусмерть. 2) Нельзя задать Content-type (он ВСЕГДА - utf-8) отдаваемого содержимого. Понятно, что utf-8 - наше все :), но не давать возможности указывать тип содержимиго - отвратительно. 3) Модуль никаким образом не связывает вызовы процедур Headers и Content, поэтому при обработке данных из двух параллельных HTTP сессиий Q1 и Q2 возможна ситуация, когда первый пользователь получит не то body, а второй - не тe headers.

В общем, плохо все. Талантливо испортить такую идею - это надо постараться.

> Нельзя задать Content-type (он ВСЕГДА - utf-8)

Кыса, быстренько читать RFC, в темпе! UTF8 - это КОДИРОВКА, charset в просторечье. А Content-type - это text/html, text/plain/image/jpeg и так далее

> Кыса, быстренько читать RFC, в темпе! UTF8 - это КОДИРОВКА, charset в просторечье. А Content-type - это text/html, text/plain/image/jpeg и так далее

Кодировка задается в строке Content-type :) Результирующая строка, которая отдается броузеру, выглядит примерно так:

Content-type: text/html; charset=KOI8-R

Эт всё технические проблемы. Можно использовать проксирование соединений через pgpool. В конце концов легковесный сервлет-контейнер (или что-там еще) перенесут в сам Постгрес. Мне кажется, это правильный путь развития - иметь возможность глубокой интеграции сервера БД и сервера приложений. Одно из самых "узких" мест Hibernate/EJB-решений как раз в том и состоит, то СУБД получается как бы разорвана на две части -- данные отдельно, бизнес-логика отдельно, а между ними сетевой интерфейс с громоздким преобразованием типов.

> Кодировка задается в строке Content-type :-)

Кодировка и тип данных - ортогональные разные вещи

Понятно, что автор исходного сообщения имел ввиду кодировку, а не тип, но говорить "Нельзя задать Content-type (он ВСЕГДА - utf-8) отдаваемого содержимого" как минимум некорректно, и как правило означает тотальное "плавание" в понимании сути происходящего :-(

> 1) Подключение производится из КАЖДОГО Apache child.

Так они же разные процессы, и в каждом своя копия модуля. Нафига городить еще какой-то огород? Если очень хочется, поставь прокси, но смысла никакого нет.

> А это означает, что при N серверах и M процессах Apache получится N * M подключений к серверу.

И что? Это _перманентные_ коннекты.

> Проще говоря: при более-менее серьезной посещаемости ляжет все вусмерть.

Зачем ляжет?

В любом варианте со скриптами под апачем в _лучшем_ случае будет то же самое, часто будет по коннекту на _сессию_ (даже этот вариант многим только снится), а в худшем по коннекту на каждый запрос.

> 2) Нельзя задать Content-type (он ВСЕГДА - utf-8)

Ты, вероятно, хотел сказать text/html с кодировкой utf-8? Ну так перепиши чуть-чуть, и пусть хранимая процедура Headers возвращает необходимые _тебе_ значения. Пусть хоть вообще что хочет возвращает помимо идетификатора, а ты это "что-то" отдавай клиенту.

3) Модуль никаким образом не связывает вызовы процедур Headers и Content

Это еще с каких щей? Headers возвращает идентификатор, который затем передается в Content.

> В общем, плохо все.

Ага. Плохо у тебя с пониманием (знанием?).

Моё прочтение оригинальной реплики было другим, что ни content type, ни charset нельзя конфигурировать. Ну, может моё прочтение неверно. А ты можешь задать image/gif используя этот модуль?

С точки зрения программиста, первична программа. А ввод (база данных) и вывод (отгенерированный html) вторичны. Любые способы вынести логику программы в ввод или в вывод вносят полнейший бардак.

К сожалению найдутся сторонники и у такого бардака (вынесение ввода на первый план), в основном со стороны DBA. Так же и как нашлись сторонники у бардака типа php со стороны веб дезайнеров (где html перичен, а программа вкрапливается где-то между строк).

Не там оптимизируете, товарищи. :) Оптимизируйте алгоритмы и схемы данных.

> Не там оптимизируете, товарищи. :) Оптимизируйте алгоритмы и схемы
> данных.

вот например про оптимизацию - берешь эту штуку и делаешь то что тебе надо причем в качестве языка используя скажем pl/python. после отработки решения потихоньку переводишь логику на C, причем по частям.
можно ли такое в рамках обычного вэб-приложения ? с трудом себе представляю, если только приложение не набор cgi. а этот модуль позволяет быстро накидать логику приложения, а затем постепенно перевести логику на использование другого языка - более эффективного, но менее удобного в разработке.

в точку.

а самый правильный подход - золотая середина: жава-скрипт раскидывающий данные вываливаемые в массивах и оверридящий дезигноровские дефолтовые вары.
дезигнеры креэйтят в параллельном треде и счастливы так как только WYSIWYG должен быть у них в руках.
путь xml темплейтов (равно как и других не-хтмльных тагов) должен умереть. Даёшь ясное разделение на дезигнеров и кодеров и будет всем щастье! Нет - хтмлю в коде!

>Понятно, что автор исходного сообщения имел ввиду кодировку, а не тип, но говорить "Нельзя задать Content-type (он ВСЕГДА - utf-8) отдаваемого содержимого" как минимум некорректно, и как правило означает тотальное "плавание" в понимании сути происходящего :-(

ОписАлся, разумеется кодировка И content-type. Но это неважно, потому как все равно сконфигурить сие ни директивами Apache, ни выводом даных из CУБД не получится.

>И что? Это _перманентные_ коннекты.

Дело в том, что коннектов *к одной и той же* базе будет ровно по количеству чайлдов Apache. Это *очень* криво -- вместо того, чтобы написать в Постгресе макс-коннекшенз по количеству серверов, писать их в N раз больше.

>В любом варианте со скриптами под апачем в _лучшем_ случае будет то же самое, часто будет по коннекту на _сессию_ (даже этот вариант многим только снится), а в худшем по коннекту на каждый запрос.

Это если руки кривые. А если прямые, то на один сервер - один или несколько коннектов (в зависимости от нагрузки) + отдельный процесс-шедулер. При этом транзакции, разумеется, должны либо COMMIT при выполнении, либо автоматически ROLLBACK при окончании HTTP-сессии.

>Это еще с каких щей? Headers возвращает идентификатор, который затем передается в Content.

Да, ступил. Посмотрел в код, там есть CookieP = ap_pstrdup(RequestP->pool,PQgetvalue(ResultP,0,0)); которое потом передается в запрос.

Темне менее, все все равно плохо потому, что в процедуру передается и обратно получается ограниченный набор непонятно каких заголовков, вместо того, чтобы передавать сериализованный объект со *всей* информацией о запросе.

> ОписАлся, разумеется кодировка И content-type. Но это неважно, потому как все равно сконфигурить сие ни директивами Apache, ни выводом даных из CУБД не получится.

Ну так поправь чуть-чуть модуль, там ведь мелочь -- заставить вывод Headers отдаваться клиенту не только куками.

> Дело в том, что коннектов *к одной и той же* базе будет ровно по количеству чайлдов Apache.

Ну да, по количеству процессов. Как шарить сокет между разными процессами без множества лишних телодвижений -- ещё та задача. Но есть способы...

> Это если руки кривые. А если прямые, то на один сервер - один или несколько коннектов (в зависимости от нагрузки)

Покажи _готовое_ решение, кроме указанного мной.

> + отдельный процесс-шедулер.

А зачем ради этого огород городить, когда есть готовый pgpool? Ну и натрави на него апач с mod_libpq. Вот тебе, непутёвому, и решение. "Юникс вей", однако ;)

> Да, ступил.

Бесспорно.

> Темне менее, все все равно плохо потому, что в процедуру передается и обратно получается ограниченный набор непонятно каких заголовков

Почему это "непонятно каких"? Какие передашь, такие и будут. "Теперь всё только от меня зависить" (с). Вот и передавай строкой что хочешь, хоть сериализованную базу целиком, лишь бы памяти хватило ;)

Знаю солидные конторы которые, переходили на связку апач + скрипт + база (Оракл) со связки апач + база (Оракл). Как раз из-за 1) трудности отслеживания, трассировки и локализации ошибок 2) огранниченности бизнезлогики при кодировании на уровне базе 3) разности оплаты труда ДБ-програмиста и CGI-кодера 4) трудности апгрейда "на живую"

Обратных примеров не знаю.

Остров

>Как раз из-за 1) трудности отслеживания, трассировки и локализации ошибок

поскупились на грамотных кодеров. бедняги

>2) огранниченности бизнезлогики при кодировании на уровне базе

надо было им на постгри переходить. тут тебе и перл тут и си

>3) разности оплаты труда ДБ-програмиста и CGI-кодера

аааа! любители экономить на качестве! :))

>4) трудности апгрейда "на живую"

см. каммент к 1) s/кодеров/дба

Ананимусы пишут код в десятки тысяч строк без единой ошибки :)

>Ананимусы пишут код в десятки тысяч строк без единой ошибки

ты тут сам недавно зарегался, и тебя еще не нацчили что такое декомпозиция?