Здравствуйте, TK, Вы писали:

TK>>>Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless.
AVK>>Фиговая демонстрация если честно, сплошное передергивание

TK>В чем передергивание?

В том что ты трактуешь мои высказывания как однозначную агитацию за стейтфул. Знаешь, большинство твоих высказываний правильны, я этого не отрицаю. Просто странно выглядит это, как попытка оспорить то чего и не утверждалось. Я не доказывал что стейтфул модель безусловно лучше чем стейтлес, я просто предложил не принимать всегда одну сторону. Например в нашем текущем проекте однозначно определится стейтфул или стейтлес модель сложно. В пределах транзакции она безусловно стейтфул, в общем стейтлес, так как состояния между транзакциями не передаются. Вобщем я за взвешеный подход

Hello, "Геннадий Васильев"

> IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.
>
> Надо, но у тебя не размазано хранение состояния по двум максимально удалённым точкам — серверу БД и клиенту. Следовательно, есть возможность оптимизировать нагрузку на коммуникации. Следовательно, можно даже восстановить состояние клиента в полном объёме при обрыве/восстановлении связи "клиент-сервер", не привлекая к этому сервер БД.
>

Восстановить, не привлекая... В stateless такой проблемы даже в принципе быть не может...
Да и потом — что значит две максимально удаленных точки? База данных для хранения состояния это не самая удаленная точка. Да и потом — как на счет smart клиентов, работы в offline режиме? Вроде как все уже давно согласились с мнением, что коммуникации — это вещь не надежная. Сегодня связь с сервером есть, а завтра нужно поехать в командировку и ее уже нет (например в самолете). А в наше время — подобные простои это уже не позволительная роскошь.

>
> В сущности — да, и как раз клонирование появляется при размещении stateful-App-ядра (эк, термин-то ) на кластере. И клонирование действительно должно реализовываться вместе с синхронизацией, следовательно, его место — сугубо в ядре системы, где можно организовать выделенные связи между серверами, по которым не ездит клиентский трафик. И ещё отчасти поэтому появляется более строгое разделение функциональности клиента и сервера, следовательно — более стройная и удобная для модификаций система.

Любая централизованная система более подвержена сбоям, чем система, в которой каждый из компонент является независимым. А что касается "выделенные связи между серверами" представим себе ситуацию, когда app сервера находятся на достаточном друг от друга расстоянии. В этом случае ни о каком выделенном взаимодействии говорить не получится...
Проектирование-же ситемы на основе stateless модели, когда каждый отдельных серверов более менее не зависим позволит решить массу подобных вопросов — начиная от масштабирования и заканчивая поддержкой offline работы пользователей...

Hello, "Геннадий Васильев"

> TK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стайтфул модели — состояние приходится хранить в памяти на сервере. Если размер такого состояния велик начинаются траблы, кончается ресурсы сервера, память. конечно, IA64 и AMD64 как герои диснея "спешат на помощь", но это все только в краткосрочной перспективе.
>
> Ровно то же самое произойдёт с SQL-сервером. Как в том анекдоте: "Жить-то Win'95 на 4 мегабайтах будет, но и только".

Не совсем. Уже упомянутый Oracle 10g как раз предназначен для того, что-бы работать не на одном большом сервере, а на распределенном сообществе машин. Или тот-же google — вся система поиска является распределенной

> Ты очень и очень спешишь с обобщениями. Кроме того, хранение состояний в памяти это не "недостаток", как ты утверждаешь, а всего лишь черта stateful-модели. Недостатком оно становится в тех или иных случаях, не более того.
>

Скажем так — это плохая черта. А в некоторых случаях она может стать очень плохой.

> TK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий.
>
> Угумс. А ещё мы наблюдаем попытку впарить BizTalk.
>

Ладно BizTalk пока закроем он рассматривался как продукт для реализации процессов длинных транзакций. В любом случае — можно выбрать какой-нибудь еще подобный продукт.

>
> TK>Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
> TK>никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода).
>
> Но никак не пример stateless-объекта. Напоминаю азы ООП: объекты суть состояния и методы, изменяющие состояния. Приведённый тобой пример — пример процедуры, а не метода. Хотя да, такой метод может быть... например, статическим.
>

Ну это больше похоже на (всем уже здесь любимую) подмену понятий. Естественно, что в случае тех-же веб сервисов никакой речи о полноценных объектах не идет ?

> На самом деле вопрос несколько шире, чем просто хранение сотояний. Вопрос ещё и в методах обработки этих самых состояний. И кстати, тот ещё вопросик...
>

Вот именно.

> TK>А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта.
>
> Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной. Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
>

А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи?

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

Например списывание денег с дебетовых счетов. Компания MTC до сих пор не может отмазаться "воруют" и "куда делись мои деньги" — вот они последствия "обновления с задержкой". Хотя, идея интересная Главное только не запускать, а то конкуренты глумиться начнут.

> Здесь есть очень интересная деталь, про которую обычно принято забывать. Те же самые заказы, отгрузки прочая шелупонь прежде чем достичь места хранения сначала всегда создаются на одном из промежуточных или клиентском уровне. Исключение составляют случаи прямой связи клиента с сервером БД, но мы же не о них говорим, верно? Так вот, использование stateful даже здесь позволит получить некоторый выигрыш.

Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу...
тут может пригодится и локальное хранилище данных и так-же то, что приложение уже само ориентировано на отправку более/менее законченных результатов.

> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то.

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

> Опять-таки, можно, конечно, прокрутить ещё одну транзакцию в БД, она же у нас гибкая как змея и современная как космический корабль, но есть идея лучше: задержать накладную в памяти App-сервера на 180-300 секунд, тем самым освободив сервер БД от обязательных для него, но совершенно не нужных в контексте приложения транзакций.

Отложенная запись — это очень опасная операция. Любой сбой, любая потеря данных — все это может серьезно подорвать доверие к такой системе. Данные нужно хранить в месте которе более устойчиво, чем оперативная память (прочь соблазны).

> Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.
>

SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает...

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

+1

> TK>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
>
> Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
>

Ну на счет дисковой подсистемы — это больше заблуждение. Всегда эффективнее держать кеш на локальном диске, чем доставать его по сети... Так-же кеш в оперативной памяти — хранение объектов в памяти это не оптимально. Да, это удобно для программиста — он освобождается от ненужных деталей и т.п. Но, с точки зрения эффективности — это совершенно не оптимально. Все эти отложенные загрузки, интеллектуальные кеши обеспечение конкуррентности своими руками производительности не прибавляют. С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям.

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

"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения...

> TK>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
>
> Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
>

Триггеры это не только контроль целостности данных, но и еще один дополнительный уровень абстракции данных. А если учесть, что пишут их специальные люди которые о БД знают больше, чем абстрактный App сервер. то эффективность от использования триггера и того, что там насоздает абстрактный app сервер еще надо детально оценивать для каждого конкретного случая.

> TK>(все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные...
>
> А вот это, кстати, косвенно подтверждает тезис о снижении производительности OLTP в stateless-модели. Второе аналогичное подтверждение состоит в том, что в тестах TPC-C MS использовала COM+ только для чтения данных, а обновление запускались через обычный ODBC. Что, в принципе, логично, если рассматривать stateless-модель в её естественной ипостаси — как удобной модели для трансформации представления данных.
>

Что значит чтение данных через COM+? Из SQL Server можно читать данные используя ODBC или OLE DB. COM+ это уже внешний сервис который к БД не так уж и много отношения имеет. Может они просто для записи в COM+ транзакции отключали?

>
> TK>И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.
>
> Ухх... в итоге получается нечто, достойное рекламной статьи на сайте Microsoft, уж извини. Ты утверждаешь, что нельзя обеспечить согласование кэшей? А на основании чего ты так говоришь? Уж не основании ли того, что у тебя в распоряжении нету компонента "StatefulCacheSyncronizer"?
>

Я не спорю, можно обеспечить соглосование кешей, и прочих замечательных вещей. Возможно, что компоненту "StatefulCacheSyncronizer" можно купить в каком нибудь электронном магазине. Разговор о том, что насколько эффективно писать подобные компоненты в своем подразделении, или насколько велик бюджет проекта для покупких сервера (не только ПО, но и железо. Не будем забывать, что при увеличении производительности стоимость сервера растет не пропорционально) приложений с нужной функциональностью.

> TK>В противоположность ей стайтлесс модель на таких данных ведет себя хорошо, поскольку гибкие возможности современных быз ранных, обладающих большей информацией о механизмах хранения данных (все основано на серьезном математическом аппарате), эффективных средствах кеширования и распределения информации — не вносит практически никакого оверхеда, но предоставляет поистинне фантастические возможности для масштабирования. Редко меняющиеся данные спокойно могут реплицировать на десяток не особо мощных машин, и когда будут идти обращения к БД, они не будут испытывать практически никаких блокировок — поскольку вся архитектура является распределенной и выполнять эту работу будет наименее загруженный участник.
>
> 1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.

Надо ораклу с гуглом сказать

> 2. Оверхед таки вносится.
> 3. Математический аппарат в хинтах... ммм... это даже не смешно.

Хиты это больше прероготива апп серверов. Надо-же на чем-то производительность поднимать

> 4. Читается конечно, на одном дыхании, в этом не откажешь.
>

Распределенным может быть хранение данных.
1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер.
2. Редко изменяемые данные реплицируются на локальные базы ближе к frontend серверам. Учитывая, что репликация происходит только измененной информации — нагрузки будут минимальными. И практически мгновенное отображение изменений.

> TK>Было одно преимущество стейтфул модели — считается, что программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, правда обращение к объекту требует потокобезопасности (кого это сейчас пугает?). Но, современные средства такие, как BizTalk сервер не только предоставляют удобные стредства для программирования бизнес логики, но и имеют массу шлюзов в уже имеющиеся системы.
>
> Угу, продажа BizTalk уже началась.
>

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

Здравствуйте, AndrewVK, Вы писали:

TK>>В чем передергивание?

AVK>В том что ты трактуешь мои высказывания как однозначную агитацию за стейтфул.

Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем. Зачем тогда эти инсинуации.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной. Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".

Но пока это "неверное" утверждение никто не опровергнул на практике.

ГВ>Здесь есть очень интересная деталь, про которую обычно принято забывать. Те же самые заказы, отгрузки прочая шелупонь прежде чем достичь места хранения сначала всегда создаются на одном из промежуточных или клиентском уровне. Исключение составляют случаи прямой связи клиента с сервером БД, но мы же не о них говорим, верно? Так вот, использование stateful даже здесь позволит получить некоторый выигрыш. Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. Опять-таки, можно, конечно, прокрутить ещё одну транзакцию в БД, она же у нас гибкая как змея и современная как космический корабль, но есть идея лучше: задержать накладную в памяти App-сервера на 180-300 секунд, тем самым освободив сервер БД от обязательных для него, но совершенно не нужных в контексте приложения транзакций. Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.

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

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

Ну да. Только что ты нам это продемонстрировал

TK>>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.

ГВ>Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.

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

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

ГВ>Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД.

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

ГВ>Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется. Конкретный App-сервер может ни шиша не знать о прикладной специфике.

Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

TK>>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции

ГВ>Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.

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

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

Это так в случае stateful

ГВ>2. Оверхед таки вносится.

Всегда.

ГВ>3. Математический аппарат в хинтах... ммм... это даже не смешно.

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

Здравствуйте, AndrewVK, Вы писали:

IT>>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.

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

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

IT>>Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова.

AVK>А зачем делать два вызова одного и того же?

Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.

AVK>Как я ниже писал — стейтфул модель себя оправдывает на редко изменяющихся данных, а для них такое просто бессмысленно.

Т.е. ты всё же клонируешь объект?

AVK>>>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

IT>>Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

AVK>Когда сложные, разветвленные и непредсказуемые действия клиента на относительно длинном интервале времени должны иметь возможность быть откачеными в любой момент. Например документс большим количеством подчиненной информации, при том что эта информация может быть создана только с участием сервера. Альтернатива длинным транзакциям в этом случае одна — реализация механики транзакций и отката на клиенте с серьезными проблемами синхронизации и надежности.

Для таких задач лучше подходят всевозможные системы data/business flow, которые как раз и обеспечивают то, что ты называешь длинными транзакциями. TK уже предлагал для этого задействовать BizTalk, в принципе я с ним согласен. Подобные задачи представляются достаточно простыми при наличии соответствующего софта и осилисть их может человек, являющийся специалистом в предметной области. Высококвалифицированным программистом для этого быть не надо. Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

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

С ними всегда бяка. Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

IT>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

AVK>Счего бы это? Стейтфул модель как правило характеризуется еще и тем что у нее имеются расширенные метаданные бизнес-логики, т.е. значительно больше информации о предметной области, нежели у sql-серверов.

Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

AVK>Кроме того серверу приложений нет необходимости быть универсальным, его как правило задачивают под узкий круг задач. Отсюда механика управления на сервере приложений более оптимальна. Оптимизацией запросов при помощи сервера приложений можно добится эффективности кеша на не очень часто меняемых данных в районе 99% и практически полного отсутствия блокировок в БД. Это результаты реальной системы. Сервер же БД в такой схеме периодически получает интенсивные и кратковременные плевки.

Чудес не бывает. Снимая нагрузку с сервера БД ты её просто переносишь на сервер приложений, вот и всё. Насчёт более оптимальных запросов, обеспечиваемых сервером приложений. Это справедливо только для примитивных запросов, и то же самое можно закешировать и в stateless. Для сложных запросов на практике это не реально. Пять строчек на SQL с парой вложенных джоинов обычно выливаются в десятки, если не в сотни строк на C++/C#/whatever, реализующих поиск, фильтрацию и сортировку в объектной модели и отнюдь не отличаются быстродействием доморощенных алгоритмов.

IT>>Ерунда.

AVK>Может и ерунда но именно так оно выходит на реальных серверах.

На разных реальных серверах обычно всё по разному.

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

AVK>Самой стейтлес блокировки не нужны, о том и речь. Вся тяжесть изоляции в этом случае ложится на сервер БД. А вот ему то как раз и приходится несладко.

Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться. Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.

IT>>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.

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

При помощи кеширования.

AVK>Я не писал о задачках вроде нашего сайта. Я ж говорю что ты там совсем отвык от нашей действительности . Основные задачи, для которых применяется трехзвенка это управление предприятиями. Причем "лоскутная автоматизация", ввиде кучи слабо зависимых клочков, использующих разные технологии обычно никого не устраивает, благо в России багажа старых систем пока еще практически нет. ВОт о таких системах и речь. Что же касается нашего сайта то можешь заметить что я первый же был против превращения нашего сайта в полномасштабную трехзвенку. У всех технологий есть границы применимости.

Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию , давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются. Что там управление предприятиями, что тут, что там лоскутная автоматизация никого не устраивает, что здесь. Тем не менее все латали, латают и будут латать. И (отвелекаясь от темы топика) нужно с этим не бороться, а уметь организованно управлять. Стройная, гибкая система без сучка и задоринки — это миф. Написать её конечно можно, но к тому времени либо требования изменяться, либо ишак умрёт.

IT>>И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.

AVK>Пока не понадобится хранить состояния .

Не так. Ты путаешь понятия cache и storage. Да, они оба как бы типа хранят состояние. Но наличие данных в первом совсем не обязательно и предназначено только для одной функции — снятие нагрузки с базы данных постредством реиспользования ранее произведённых запросов. Для второго — наличие данных это часть логики. Например, через кэш можно получить два разных экземпляра одной и той же записи БД. Для stateless в этом нет ничего страшного. Но, если твоё хранилище в stateful вернёт два экземпляра одного и того же объкта, то это уже не stateful, а либо глючный stateful, либо stateless

AVK>Смею повторится — задачки бывают разные. Если данные по большей части быстро устаревают стетфул модель будет неэффективна, если наоборот неэффективной будеть стейтлес модель. Рулит, как всегда, помимо тактического ядерного заряда конечно, золотая серидина. Т.е. грамотное, с учетом предметной области, распределение между стейтфул и стейтлес, причем желательно без явной границы, т.е. чтобы каждый объект в определенной пропорции был и стейтлес и стейтфул.

Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.

IT>>То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.

AVK>Веб-приложения как правило никто и не стремится сделать стейтфул.

Да уже и GUI не очень-то стремяться. Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

IT>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.

AVK>Не все так однозначно. Ровно так же резко усложняется проблема со стейтлес при больших нагрузках из-за лавинообразного нарастания блокировок в БД и ровно такой же геморой начинается при оптимизации этой самой БД и запросов к ней.

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

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

Возможно. Насочинять можно много чего.

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

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

IT>>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой.

AVK>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndrewVK, Вы писали:

AVK>>Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом

IT>Ok. Но все видели, это не я начал

Вот еще б статейку почитать какую-нить, чтоб лучше понимать суть спора...
А если б ее и еще кто-нить из вас написал...

Здравствуйте, Аноним, Вы писали:

А>Вот еще б статейку почитать какую-нить, чтоб лучше понимать суть спора...
А>А если б ее и еще кто-нить из вас написал...

А вообще-то идея неплохая...

Здравствуйте, IT, Вы писали:

ГВ>>[...] Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
IT>Но пока это "неверное" утверждение никто не опровергнул на практике.

Ну, Игорь, чтобы такое утверждать, нужно как минимум владеть достаточно репрезентативной выборкой. Она у тебя есть?

ГВ>>Здесь есть очень интересная деталь, про которую обычно принято забывать. [skip детали, оставим только общее ]
IT>Вот видишь как ты всё невероятно усложняешь. Для стэйтлес всё описанное тобой сводится к следующему. Сервер создаёт, инициализирует объект и отдаёт его клиенту. В базу данных ничего не пишется. Клиент заполняет объект и либо отдаёт его серверу для сохранения в БД (здесь база данных действительно задействуется), либо нажимает escape и документ умирает без всякого обращения не то что к БД, ...

Дык итить в том-то и дело, что юзер удаляет/меняет документ почти сразу после того, как нажал Save, т.е., отправил его серверу.

IT>...но даже к серверу приложений. В крайнем случае придётся повозиться с номером накладной, если требования подразумевают его генерацию до заполнения документа.

Ну и получается катание туда-сюда полного состояния объекта. А если ещё учесть, что там справочники всяческие...

ГВ>>Правда, справедливости ради, следует заметить, что реализация такого подхода требует достаточной квалификации и самостоятельности программистов, что, увы, может стать проблемой в современных условиях.
IT>Ну да. Только что ты нам это продемонстрировал

Ну... я надеюсь.

TK>>>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
ГВ>>Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
IT>Для сложных отчётов нужно делать отдельный сервер и специально проектировать под это базу данных. Тот же OLAP предполагает недетское дублирование данных для эффективной работы и все нормальные формы вплоть до 2-й идут лесом.

Аналитика бывает разной и онлайновая в том числе. Как и отчёты. Кстати, часть онлайн-аналитики как раз и может выполнять App-сервер: данные-то все через него проходят.

TK>>>А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша.
ГВ>>Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД.
IT>БД не надо вовлекать в то с чем она непосредственно не взаимодейтствует. Для этого пишутся агенты, которые могут работать по тем же принципам stateless. Т.е. взял данные, отдал данные. Либо получил данные, передал данные.

Согласен.

ГВ>>Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется. Конкретный App-сервер может ни шиша не знать о прикладной специфике.
IT>Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

Да, конечно. Я имею ввиду критерии, по которым определяется, например:

— необходимость кеширования тех или иных данных;
— время задержки записи;
— распределение обработки между App-сервером и СУБД.

Справедливости ради — не очень удачно я выразился.

TK>>>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
ГВ>>Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
IT>БД обязана контролировать целостность данных. Если она этого не делает, то всегда найдётся какой-нибудь чудак на букву 'м', который запишет туда какой-нибудь бред. После этого твой сервер просто ляжет, если всецело полагается на целостность данных.

Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть. Противостоять всем чудакам никакя софтина не сможет. Потом, определяет правила целостности всё-таки приложение, одной из подсистем которого как раз и является БД.

ГВ>>1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.
IT>Это так в случае stateful

Это так в случае распределенности где надо и не надо.

ГВ>>2. Оверхед таки вносится.
IT>Всегда.

Истинно так.

ГВ>>3. Математический аппарат в хинтах... ммм... это даже не смешно.
IT>Не только в хинтах. Оптимизация запросов, кеширование, целостность и пр. В общем, всё то, что тебе так или иначе нужно будет переизобрести.

Здравствуйте, IT, Вы писали:

хъ

IT>Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем. Зачем тогда эти инсинуации.

Уже не раз говорилось о том, что отдельные личности могут очень много принять на свой счет.

Здравствуйте, IT, Вы писали:

AVK>>В том что ты трактуешь мои высказывания как однозначную агитацию за стейтфул.

IT>Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем.

Вот и я о том же. И непонятно зачем было мои слова при этом выворачивать наизнанку.

IT>Зачем тогда эти инсинуации.

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

Hello, "AndrewVK"

> IT>Зачем тогда эти инсинуации.
> Вот и мне хотелось бы знать. Неужели нельзя было сказать тоже самое в менее издевательской манере?

Никто над тобой не издевался. Просто относись к этому с большим чувством юмора

Здравствуйте, Геннадий Васильев, Вы писали:

хъ

ГВ>Дык итить в том-то и дело, что юзер удаляет/меняет документ почти сразу после того, как нажал Save, т.е., отправил его серверу.

Как уже правильно тут говорили, важно не смещать акценты от одного к другому и использовать по-возможности, оба подхода. В частности, в твоем случае, сделать кеш на стейтлесс модели намного проще (rowversion). Т.е. алгоритм несколько усложняется:
1. Сервер смотрит в кеше объект и по rowversion проверяет насколько он соответствует дейтсивтельному состоянию объекта в БД. Если все ок, го то 3.
2. Сервер создаёт, инициализирует объект и
3. отдаёт его клиенту...

IT>>...но даже к серверу приложений. В крайнем случае придётся повозиться с номером накладной, если требования подразумевают его генерацию до заполнения документа.

ГВ>Ну и получается катание туда-сюда полного состояния объекта. А если ещё учесть, что там справочники всяческие...

Катание куда?

хъ

IT>>Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

ГВ>Да, конечно. Я имею ввиду критерии, по которым определяется, например:

ГВ>- необходимость кеширования тех или иных данных;

Это не зависит от модели сохранения состояния.

ГВ>- время задержки записи;

Отложенная запись? Ну не знаю...

ГВ>- распределение обработки между App-сервером и СУБД.

Как-то слишком абстрактно.

хъ

ГВ>Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть.

А это уже административные проблемы.

ГВ>Противостоять всем чудакам никакя софтина не сможет. Потом, определяет правила целостности всё-таки приложение, одной из подсистем которого как раз и является БД.

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

Здравствуйте, IT, Вы писали:

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

IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.

А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП. Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.
Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?

AVK>>А зачем делать два вызова одного и того же?

IT>Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.

У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.

AVK>>Как я ниже писал — стейтфул модель себя оправдывает на редко изменяющихся данных, а для них такое просто бессмысленно.

IT>Т.е. ты всё же клонируешь объект?

В бизнес-коде нет, на клиента во многих случаях да.

IT>Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

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

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

IT>С ними всегда бяка.

Тем не менее в стейтфул модели бяка поменьше.

IT>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

AVK>>Счего бы это? Стейтфул модель как правило характеризуется еще и тем что у нее имеются расширенные метаданные бизнес-логики, т.е. значительно больше информации о предметной области, нежели у sql-серверов.

IT>Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

Разумеется. Только у стейтлес эту осведомленность проявить куда меньше возможностей. Сам же призаешь что в стейтлес модели основная тяжесть разруливания состояний ложится на sql сервер. С одной стороны это очень хорошо, особенно в малобюджетных проектах. Но с другой стороны это же ограничивает простор для оптимизации на основе метаданных бизнес-логики. Как всегда надо выбирать золотую середину.

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

Безусловно.

IT>Насчёт более оптимальных запросов, обеспечиваемых сервером приложений. Это справедливо только для примитивных запросов, и то же самое можно закешировать и в stateless. Для сложных запросов на практике это не реально. Пять строчек на SQL с парой вложенных джоинов обычно выливаются в десятки, если не в сотни строк на C++/C#/whatever, реализующих поиск, фильтрацию и сортировку в объектной модели и отнюдь не отличаются быстродействием доморощенных алгоритмов.

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

AVK>>Может и ерунда но именно так оно выходит на реальных серверах.

IT>На разных реальных серверах обычно всё по разному.

Разумеется. Потому я особо оговорился — речь идет об управлении предприятием. Т.е. наш сайт под это уже не попадает.

IT>Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться.

Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.

IT> Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.

Хороши усилия — после каждого запроса скидывать состояние в БД

IT>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию , давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.

Зря.

IT> Что там управление предприятиями, что тут,

Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.

IT>что там лоскутная автоматизация никого не устраивает, что здесь. Тем не менее все латали, латают и будут латать.

В России чаще всего и латать то нечего. Либо автоматизации нет совсем, либо она на примитивном уровне самопальных однопользовательских программулек. Лет через 15-20 у нас наверное и законы устаканяться и на каждом предприятии будут легаси-системы, но это все нескоро.

IT>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.

Слова Стива Шварца помнишь?

AVK>>Веб-приложения как правило никто и не стремится сделать стейтфул.

IT>Да уже и GUI не очень-то стремяться. Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

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

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

IT>Возможно. Насочинять можно много чего.

Ну он вроде как говорил где именно та или иная схемка реализована на практике.

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

IT>Самое фиговое в stateful — это когда понимаешь что чтобы сделать следующий шаг, нужно пройти в два раза больше чем пройдено, что столько усилий потрачено, а результат получился хреновый.

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

AVK>>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

Здравствуйте, Alexey Shirshov, Вы писали:

ГВ>>Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть.

AS>А это уже административные проблемы.

Точно так же предоставление прав доступа к серверу БД не только серверу приложений но и всяким чудакам тоже административная проблема.

AS>Понятное дело, что бизнес-логика должна что-то валидейтить, но проверять на уникальность поле или группу полей и соблюдать ссылочную целостность на сервере приложений — как бы по мягче выразиться, просто глупо и неэффективно.

Это ты зря. Не все можно провалидировать в sql сервере, тем более не все можно провалидировать там эффективно. Юкон правда позволяет эту задачку таки решить.

Здравствуйте, TK, Вы писали:

TK>Никто над тобой не издевался. Просто относись к этому с большим чувством юмора

Наверное, но я в данном случае не смог.

Здравствуйте, AndrewVK, Вы писали:

хъ

AVK>Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Не вижу проблем (если база верно спроектирована). У меня как раз такая ситуация и я прекрасно обхожусь стейтлесс моделью.

хъ

AVK>У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.

Дык это стейтфул управляет всей тяжестью состояний, а не стейтлес! О потом, я вот уже много раз слышал про тяжесть отката, но никак не могу понять, в чем она выражается?

хъ

IT>>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

AVK>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

Блин! Ты хочешь сказать, что в стейтфул модели проблемы перекладываються на машину и она код лабает? Что ты подрузомеваешь под проблемами? Реализация бизнес-логики всегда лежит на программере, а вот реализация правил ссылочной целостности — нет.

хъ

AVK>Разумеется. Только у стейтлес эту осведомленность проявить куда меньше возможностей. Сам же призаешь что в стейтлес модели основная тяжесть разруливания состояний ложится на sql сервер. С одной стороны это очень хорошо, особенно в малобюджетных проектах. Но с другой стороны это же ограничивает простор для оптимизации на основе метаданных бизнес-логики. Как всегда надо выбирать золотую середину.

А можно по подробнее на счет этой оптимизации. Оптимизацию SQL сервера я знаю, оптимизацию софта тоже, но оптимизацию логики на основе метаданных...

хъ

AVK>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

А именно?

хъ

AVK>Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.

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

хъ

AVK>Хороши усилия — после каждого запроса скидывать состояние в БД

Не обязательно. Кеш еще никто не отменял.

хъ

IT>>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

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

С помощью железа можно расшарять до бесконечности.

AVK>Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

А что, изолирование локиги является отличительной чертой только стейтфул модели? И потом, зачем загонять SQL-сервер в кластер, если у тебя все лопатиться вне его.

Здравствуйте, AndrewVK, Вы писали:

хъ

AVK>Это ты зря. Не все можно провалидировать в sql сервере, тем более не все можно провалидировать там эффективно.

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

AVK> Юкон правда позволяет эту задачку таки решить.

Если ты на счет триггеров, то они всегда являлись "последним средством". И то, что они теперь будут доступны в манажд режиме — мало что меняет.

Здравствуйте, IT, Вы писали:

IT>БД обязана контролировать целостность данных. Если она этого не делает, то всегда найдётся какой-нибудь чудак на букву 'м', который запишет туда какой-нибудь бред. После этого твой сервер просто ляжет, если всецело полагается на целостность данных.

Фигня. В современных приложениях большинство интересующих нас ограничений целостности невыразимы в декларативных терминах СУБД. Исторически триггеры, и прочие сторед процедуры вводились не в последнюю очередь для обхода этих декларативных ограничений и поддержки процедурной функциональности.
В N-tier архитектуре все процедурные аспекты лучше перемещать на сторону апп-сервера, для better maintainability. А вот декларативные аспекты надо всенепременно на уровне storage оставлять. Не столько для того, чтобы проверить целостность всякую, а для semantic query optimization. По любому, генерацию уникального номера документа в соответствии с правилами, принятыми в компании, должен выполнять app-server еще до обращения к базе. В свете этого введение unique constraint на уровне RDBMS кажется избыточным, но на практике его наличие означает немедленный хинт оптимизатору, что селективность запроса на точное совпадение по данному полю максимальна. А вот процедурные правила ничего серверу не дают.

Защита от прямого доступа к базе должна все же осуществляться более цивилизованными методами. Дали ручки у апп-сервера подергать — и дергайте. А в n-tier приложении руками в базу лазить — это спорт для экстремалов.

Hello, "AndrewVK"

> IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.
>
> А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.

С каких это пор — получение объекта целиком это не ООП? Объектность как таковая не зависит от того, в каком месте находятся данные.

> Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.

Замечательно. Эти документы порождаются в какой-то БД и там остаются.

> Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.
>

Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные, и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

> Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?
>

Вести лог соединений. При отправке пакета сообщений ему присваивается уникальный номер. После этого клиенту остается только проверять — в каком состоянии находится обработка данного пакета. Из сразу очевидных плюсов — все пакеты можно складывать в очередь и добавлять не все сообщения за раз — нагружая тем самым сервер, а делать это в фоне, по расписанию.

>
> У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.
>

Бизнес код это логика, работы и к сосотоянию она имеет очень мало отношения. С тем-же успехом, можно написать достаточно универсальное хранилище, для управления состояними и откатом. И, если посмотреть на развитие индустрии ПО — именно к этому все и движется. Smart приложения набирают все большую популярность — даже возможности сегодняшней ноты могут превосхидить недавние сервера, не говоря уже о десктоп системах. В этой ситуации использование stateless технологий упрощает создание распределенных приложений.

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

А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

> IT>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).
>
> Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.
>

Не обязательно. Главное это создание устойчивой инфраструктуры — тогда бизнес программист просто не будет задумываться об этом. Хотя, да. в короткой перспективе stateful это удобно.

> IT>Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться.
> Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.
>

Тоже самое и в stateful. Необходимость постоянно держать состояние в app сервере увеличивает суммарную на него нагрузку и размазывает ее по времени. Только в случае со stateless проще переложить часть нагрузки на клиента / другой сервер.

> IT> Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.
>
> Хороши усилия — после каждого запроса скидывать состояние в БД
>

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

> IT>Да уже и GUI не очень-то стремяться. Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы
>
> Отстал от жизни Увлечение веб интерфейсами начинает имхо потихонечку спадать. Теперича, опять же помимо тактического ядерного заряда, рулит XAML, который не пойми что
>

XAML это типичный пример дальнейшего развития веб интерфейса. На настоящий момент уже понятно, что не смотря на то, что веб интерфейс это хороший и удобный выбор — многих возможностей он не предоставляет, а отсутствие нормальной объектной модели при разработке приложений с веб интерфейсом только обостряет проблему. В этой ситуации появление XAML, как своеобразного гибрида веб технологий и возможностей .NET выглядит очень естественным продолжением.

> IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.
>
> Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.