Ну вот, старые песни... Масштабируемость, упрощение... Баян...

Странные мысли о 3-звенном приложении

ХерресЯ бы ещё добавил так: главное в том, что трёхзвенка - это способ разменять скорость и простоту разработки (и в итоге - более мощный функционал) на скорость.

Можно по-подробней... Про скорость и простоту... Вместо обработки данных на сервере СУБД (предназначенными специально для этого средствами) - обработка на среднем уровне? Где здесь скорость? Вместо сосредотачивания на разработке только серверного кода - размазывание его между сервером СУБД и апп. сервером. Где здесь простота?

авторИ размен этот очень достойный, ибо железо дёшево, только функционал имеет значение.

Дешево что по сравнению с чем?! Вместо того, чтобы умощнить (сделать кластер) сервер СУБД, мы будем приобретать отдельное железо под апп. сервер?

авторРазмышления технических спецов о кем-то принятых бизнес-решениях - это что-то :-) (без обид, сам грешен)

Как мне казалось, в топике идет обсуждение именно технических вопросов, а не стоимости проектов и % откатов. ;)

2 Сисой

авторРаспараллелить СУБД на нескольких машинах хотя и возможно архитектурно, но гораздо гиморнеее, чем вычисления на нескольких app-серверах. Не надо думать, что в учетных системах не хватает расчетов - простой посменный расчет загрузки в MES-системе обрушит производительность SQL-сервера довольно прилично. СУБД должна заниматься своим делом - транзакциями и выборками, а не ветвлениями и циклами.

Чем (конкретно) гиморнее распарралеливание СУБД (тех, которые имеют такие возможности) гиморрнее распараллеривания нескольких апп. серверов? На счет расчетов... Почему это, тот или иной расчет не обрушит производительность апп. сервера, и, вдруг, обрушит, производительность СУБД, которых часто называют "молотилками данных"? Или В вашем понимании СУБД - это голое хранилище? Так на кой тогда юзать сервера СУБД - dbf + апп. сервер. Только у меня большие сомнения, что Вы сумеете на достаточном уровне реализовать на апп. сервере, то, что сервера СУБД уже умеют делать - кэширование, блокировки и т.п.

авторНа app-серверах зачастую реализуют очень сложную логику взаимодействия параллельных конкурентных процессов. Задают правила вытеснения, блокировки, отработки бизнес-процессов (реально может быть одновременно запущено несколько тысяч процессов). Например, как в виртуальных параллельных серверах OEBS. Нагружать этим СУБД нецелесообразно - подобные механизмы требуют немало ресурсов.

Ага. Т.е. в СУБД (которая как раз и расчитана на "сложную логику взаимодействия параллельных конкурентных процессов") это не реализовать - лучше будем свой велосипед изобретать?! А что, апп. сервера потребуют МЕНЬШЕ ресурсов?!

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

Давайте так. "Приятность взору" интерфейса никак не коррелируется с числом звеньев в архитектуре системы! Если Вы про WEB интерфейс, то, IMHO, его с большой натяжкой можно назвать "приятным взору".

2 iscrafm

В Ваше фразе заменяем "сервер приложений ISCRA" на "сервер СУБД" и получаем:

1. Управляет контентом.
2. Взаимодействует с БД (одной или несколькими) по запросам пользователей
3. Исполняет логику, которая реализована не средствами БД (срипты Object Pascal,JAVA или просто dll которые решают определенные задачи. Например, массовая рассылка корреспонденции)

5. Обрабатывает пакеты данных получаемые от клиента и передаваемые ему (шифрование, сжатие и т.п.)

Если Вы считаете, что современные сервера не умеют этого делать, то Вы не правы.

автор
4. Управляет лицензиями, в том числе и на СУБД

Вот это "управление" мне не совсем понятно - растолкуйте, плиз.

авторНе конектить же клиента к одновременно к нескольким БД. Особенно через интернет. Типичный пример сервера приложений - web сервер. Думаю понятно, что он делает такого, чего нельзя сделать при помощи СУБД.

Я не отношу себя к противникам N-звенок. Я противник использования их там, где достаточно функционала СУБД.

iscrafm авторВот это "управление" мне не совсем понятно - растолкуйте, плиз.
Все просто. СП работает с СУБД в пакетном режиме. Ему (и клиентам) не нужно постоянно сидеть в он-лайне с БД. Поэтому не нужно на 50 пользователей иметь 50 конкурентных лицензий СУБД. Есть возможность регулирования, например на каждых 10 пользователей СП 1 лицензия СУБД. Клиент обратился к СП, СП к СУБД, получил свою порцию и отдал клиенту. Клиент спокойно работает со своим портфелем. Когда созрел - передает данные (вернее инструкции) СП, СП в свою очередь или исполняет инструкции сам и привлекает для этого СУБД. Опять же, повторяюсь, расчеты которые логично должна делать СУБД - делает СУБД.

Вам бы стоило внимательно ознакомится с Лицензионными Соглашениями СУБД. Их производители и маркетологи не дураки и эта "дырка" уже давно закрыта! Если у Вас 50 активных пользователей, то скока бы вы промежуточных звеньев не поставили на их пути к СУБД, Вам нужно иметь 50 лицензий. Да и для серьезных систем покупают процессорные, а не пользовательские лицензии.

модСервер БД - ОДИН (даже если это кластер) а апп. серверов можно поставить скока хошь - абсолютная масштабируемость. (И чего здесь не понятного ?)

Мне то все понятно. :) Если бы апп. сервера могли бы жить своей жизнь, а не использовать ОДИН сервер СУБД, то тогда можно было бы говорить о масшатабируемости. А так, скока мы бы апп. серверов не поставили рядом с одним сервером СУБД узкое место все равно останется в последнем, ибо данные на нем.

СисойВ СУБД (как правило) НЕТ ОТКРЫТЫХ ИНТЕРФЕЙСОВ ИСПОЛЬЗОВАНИЯ всех возможностей параллельных конкурентных процессов расчетами (не транзакциями). М.б. я ошибаюсь, но приведите мне контрпример. Чтобы можно было извне программно управлять приоритетами, блокировками, сообщениями да еще и гарантированно не подвесить при этом сервер БД.

Эээ... Не совсем понятно, о каких "ОТКРЫТЫХ ИНТЕРФЕЙСАХ ИСПОЛЬЗОВАНИЯ" Вы ведете речь? Блокировками, сообщениями и "подвещиваниями" можно управлять, например, в MS SQL. Если речь дополнительно заходит о приоритетах отдельных процессов, реализуемых на уровне движка - смотрим в сторону СУБД, которые это поддерживают (например, Oracle).

СисойIscraFM верно привел пример с гетерогенными системами. Я тоже видел в работе систему, работающую с единой бизнес-логикой одновременно с СУБД 2-ех типов.

И какие проблемы построить гетерогенную систему в классической двузвенке с использованием СУБД, которая в своем функционале имеет возможность работать с гетерогенными данными (например, MS SQL)?! Для конечного пользователя обращение к гетерогенным данным будет ПРОЗРАЧНО, ибо он будет обращаться к ОДНОЙ СУБД, при этом не имея понятия, где и в каком хранилище находятся данные, к которым он обращается. Более того, смена гетерогенного источника (например, с Access на другой источник, поддерживающий стандарт ODBC или OLE DB) может даже и быть не замечена клиентом.

СисойДа и сами по себе мультиСУБД-шные ERP (когда в один момент времени БД одна, но возможна "холодная" замена) появляются от потребностей производителя как можно с наименьшими затратами обслужить максимальный объем рынка.

Вам часто приходилось менять в ERP системе с апп. сервер, скажем MS SQL на Oracle? О то ж... Применимость таких систем с возможность работы на разных СУБД - выбор типа СУБД только на этапе приобретения\внедрения, но никак не во время работы продакшена. Но, опять всплывают маркетинговые аргументы в чисто техническом обсуждении.

СисойЕще один нюанс - лицензии на сервера приложений во многих системах дешевле, чем на сервера БД (при массовой закупке). Вот и думайте, где распараллеливать.

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

мод pkarklinА так, скока мы бы апп. серверов не поставили рядом с одним сервером СУБД узкое место все равно останется в последнем, ибо данные на нем.
так и я об том же - это узкое место надо разгружать, т.е. вычисления циклы и прочее относить на аппс. большие системы так и устроены.

Следуя Вашей логике разгрузить ОДИН СЕРВЕР можно только установкой ВТОРОГО СЕРВЕРА. Вам не приходило в голову, что дешевле\проще\технологичнее иметь ОДИН БОЛЬШОЙ И МОЩНЫЙ СЕРВЕР или КЛАСТЕР?

СисойЯ дважды в реальных внедрениях на предприятиях переходил от MS SQL к Oracle. Ситуация простая: лицензии MS SQL уже были (местная АСУ), поэтому пилотный проект и продуктивный старт делались на этой СУБД. А тиражирование на холдинг выполнялось уже с использованием Oracle. Обычный метод опционов: минимизация затрат до получения ощутимых результатов.

И где же здесь именно ПЕРЕХОД?! Вы в одном месте использовали одну СУБД, а в остальных другую. Теперь этой организации, надо держать специалистов по двум СУБД? Или все-таки MS SQL был полностью исключен? Т.е. вложенные в него средства были похерены? Задлянафига?

СисойНе совсем понятна привязка серверов приложений к СУБД. Пусть у нас есть 1 процессорная лицензия на SQL или 50 пользовательских. Какая разница - использую я их с одним сервером приложений или с несколькими? Важно лишь соотношение цены лицензий.

Я Вас не про привязку спрашивал. А про сравнение стоимости лицензий только на СУБД (для 2х звенок) по сравнению со стоимостью лицензий на СУБД + стоимость лицензий апп. сервера (для 3х звенки). Разницу чувствуете?!

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

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

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

А разве мои ответы на приписываемые N-звенкам "фичи", не являются аргументацией классической двузвенки?!