LINUX.ORG.RU

[БД] application server, нужен ли?

 


0

1

возмем трехзвенку. есть у нас БД, апликэйшен сервер (кстати, как это будет по-русски?) и куча клиентов. что делает эта куча? она дергает апи с серванта: гетТо, гетСё, сетЭто, которое сервант проверяет и преобразует в селекты и инсерты.

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

что можно: в постгресе сделать схему, скажем Dispatcher и добавил туда процу, скажем dispatch. проца будет принимать xml (json, your_name, не суть) скажем вида

<command>
  <body class="commands.гетТо">
    <param>1</param>
  </body>
</command>

скаля это дело конвертнет в объек, рассует по табличкам соберет ответ-объект, конвертнет обратно в xml и вернет в качестве ответа на запрос. получится эдакий сервер приложений, только интегрированный в базу. если же такие команды оформить в виде case классов, то это дело можно будет чудно матчить.

у клиента остается только вызов select Dispatcher.dispatch, ответ которого клиент разберет на объект.

код процы может выглядеть примерно так:

pck.body match {
  case o : commands.гетТо => то
  case o : commands.гетСё => сё
  case _ => "wtf!?"
}

вопрос: имеет ли это право на жизнь? делают ли так? если нет, то почему?

пока из проблем мне видится только то, что я не могу таким макаром отслеживать состояние, но я не вижу где мне это дело может понадобиться.

★★★★

Последнее исправление: Rastafarra (всего исправлений: 2)

т.е. на каждой клиентской тачке вместо простого браузера нужно ставить клиент к СУБД?

aydar ★★★★★
()
Ответ на: комментарий от aydar

апликэйшен сервер - сервер приложений

aydar ★★★★★
()

> получится эдакий сервер приложений, только интегрированный в базу

Нахрена нам сервер приложений в базе данных? Базу больше занять нечем? Нравится обновлять код через одно место? Нравится заниматься отладкой в базе? Нравится делать тесты внутри базы? Какая для этого может быть вообще разумная причина?

имеет ли это право на жизнь?


Нет.

делают ли так?


Нет.

если нет, то почему?


Догадайся сам.

archimag ★★★
()
Ответ на: комментарий от aydar

> т.е. на каждой клиентской тачке вместо простого браузера нужно ставить клиент к СУБД?

браузер, естественно. вот только сервант у тебя будет уметь только один сервлет (применительно к жабе) dispatcher с методом dispatch. ajax будет генерить запрос и получать ответ. в связке с ext.direct мне это видится все более и более интересным.

но опыт подсказыват, что не может быть все так радужно и грабли быть должны. вот, собсно спрашиваю: где?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от archimag

> Нравится обновлять код через одно место?

jar с процами подсосется сам, не?

Нравится заниматься отладкой в базе? Нравится делать тесты внутри базы?

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

Какая для этого может быть вообще разумная причина?

меньше кода, не?

у нативного клиента обычно уже есть способ взаимодействия с базой хотя бы на уровне селектов, у web-а надо будет сделать один сервлет. логины/пароли есть, валидацию можно сделать общей, с оговоркой: нативный клиент тоже жабе. валидацию для web-а можно организовать ajax-овым запросом, а валидаторы, вынесенные в отдельный jar уже собсно есть.

Rastafarra ★★★★
() автор топика

Да можно, о учти - чем больше данных, тем тормознее система будет.
С прослойкой в виде сервера приложений это не так заметно будет, ибо кэширование часто запрашиваемых выборок, отложенные обновления и т.п.

yaws
()
Ответ на: комментарий от yaws

> кэширование часто запрашиваемых выборок

оно меня извлекает и уже даже извлекло. то возвращает не то, то не так, то еще фигня какая...

Rastafarra ★★★★
() автор топика

Просто СУБД не задумывалась изначально как Application Server. Начнутся проблемы с прицепление примочек типо безопасности и т.д.

vertexua ★★★★★
()

>кстати, как это будет по-русски?
сервер приложений

скаля это дело конвертнет в объек, рассует по табличкам соберет ответ-объект, конвертнет обратно в xml и вернет в качестве ответа на запрос. получится эдакий сервер приложений, только интегрированный в базу

привет vahvarh-у, он что-то подобное делал.

если нет, то почему?

потому что непереносимо и вендорнозависимо.
Приложение на java ee 5, например, ты можешь запустить на любом из 10 серверов приложений и на любой из 10 БД и везде будет работать одинаково.

Из-за отстутствия обработки http заголовков не будет сессий, например. Плюс еще о скалабилити подумай.

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

> Приложение на java ee 5, например, ты можешь запустить на любом из 10 серверов приложений и на любой из 10 БД и везде будет работать одинаково.

тогда какая разница между двумя БД, если не пользовать их специфические плюшки?

Из-за отстутствия обработки http заголовков не будет сессий, например.

естественно должна быть прослойка для веба, не вопрос.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от vertexua

> Начнутся проблемы с прицепление примочек типо безопасности

а что с ними? контроль прав все равно делает жабский код, а логин/разлогин уже есть в БД.

и т.д.

?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

Я сам уже понял. У вас stateless. Вообще обычно коннект к БД очень медленный, потому юзают всякие пулы в тех же трехзвенках. Как с этим?

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

> Вообще обычно коннект к БД очень медленный, потому юзают всякие пулы в тех же трехзвенках. Как с этим?

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

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

Суть наверное в том, что к БД соединение создается долго, потому трехзвенка создает несколько штук, потом ними обрабатывает тысячи запросов не закрывая. Ну так еще и проблема с многозадачностью решается, так как соединения к БД нельзя шарить без синхронизации, они не thread safe. По крайней мере в JDBC. Если ты дашь доступ к БД, то к нему на клиентах нужен будет пул, иначе неэффективно. Наверное «подключился-выполнил один запрос-отключился» применительно к БД дает недопустимый оверхед

vertexua ★★★★★
()
Ответ на: комментарий от Rastafarra

>тогда какая разница между двумя БД, если не пользовать их специфические плюшки?
скорость.
Во вторых, есть внешние плюшки, такие например, как бекап, VACUUM и так далее, что в конечном итоге все равно ведет к скорости и поддерживаемости.

JFreeM ★★★☆
()

Если бы клиенты были приложениями в локальной сети с обеспечением должной безопасности, то да, так делать можно. В интет свестить коннект от СУБД совсем плохо. Что, например, будешь делать от простого DoSа на СУБД? Навряд ли сможешь эффективно с этим бороться без промежуточного сервера приложений.

mashina ★★★★★
()
Ответ на: комментарий от vertexua

Ну так еще и проблема с многозадачностью решается, так как соединения к БД нельзя шарить без синхронизации, они не thread safe.

Это уже СУБД зависимо. Свободные СУБД типа pgsql и mysql такие. Некоторые коммерческие СУБД могут через одно соединение шарить множество сессий.

mashina ★★★★★
()
Ответ на: комментарий от vertexua

> Суть наверное в том, что к БД соединение создается долго, потому трехзвенка создает несколько штук, потом ними обрабатывает тысячи запросов не закрывая.

ну так ровно так же. нативный клиент держит коннект, веб через тот же томкат. как обычно все, не?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

Ну тогда каждому клиенту по коннекту... Может быть слишком много. А кому может быть надо много операций параллельно? Если бы это был бы веб-сервис, то пул был бы на сервере, прозрачно для клиента, по очереди на каких нибуть 100 соединениях все гонялос бы. Ну заточены БД мне кажется на 1000 перманентных соединений

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

> Ну тогда каждому клиенту по коннекту... Может быть слишком много.

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

а что будет с БД с ростом подключений? чем она в этом плане лучше отдельного серванта?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от mashina

> Что, например, будешь делать от простого DoSа на СУБД?

ровно тоже: закрываться фаерволом либо ждать. есть другие варианты?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от vertexua

бред....

max_connections = 10000 
# Note:  Increasing max_connections costs ~400 bytes of shared memory per connection slot, plus lock space (see max_locks_per_transaction).
хоть и 1000000 потянет, все упирается в память! Вы вообще с чем то больше MySQL работали?

xspirit
()

Ваше решение плохо масштабируется. Например: 1. при классической схеме можно сервер приложений и БД установить на разные компьютеры, 2. один сервер приложений может работать с несколькими БД на разных компьютерах и т.д. Опять же, вы пытаетесь телескопом гвозди забивать, БД - она для хранения и управления данными, а не для генерации ХТМЛ страниц.

gandjubas
()

Решение фиговое и не масштабируемое. Я так делал именно с постгресом и plJava stored procedure. В итоге все равно пришлось мигрировать на App Server. Грабли с которыми столкнулся:

1. Количество соединений > 100 начинаются траблы с блокировками. Так как каждый вызов хранимой процедуры - выполняется в одной транзакции. Соответственно вместо кучи мелких запросов к БД ты получишь одну длинную транзакцию, что не есть гуд при большом количестве активно делающих что то пользователей.

2. Нестабильность самой библиотеки plJava (не знаю как про другие языки). Иногда падает с сегфолтом и постгрес закрывает все процессы во избежания повреждения БД. Для продакшен сервера негодно.

3. Как уже сказали кэширование и отложенная запись в БД в случае с App Server это значительный плюс при масштабировании.

4. С AppServer у тебя больше возможностей мониторинга процесса при долгих вычислениях. Из хранимой процедуры ты только можешь послать notify клиенту о процессе. Клиент может только сделать Cancel Query.

Ну и еще много всяких проблем, которые сейчас и не вспомню уже.

grassmeister
()
Ответ на: комментарий от grassmeister

> Нестабильность самой библиотеки plJava

какую использовал? где брал? под какую платформу?

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от archimag

Нахрена нам сервер приложений в базе данных? Базу больше занять нечем? Нравится обновлять код через одно место? Нравится заниматься отладкой в базе? Нравится делать тесты внутри базы? Какая для этого может быть вообще разумная причина?

Много $$$$$$, потраченных на oracle и соответствующих специалистов? =)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.