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

>> Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности.
TK>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

Это зависит от топологии сети. Межсерверный трафик может быть физически отделён от клиент-серверного, а сам по себе он отнюдь не велик, можешь посчитать. Особенно, если учесть, что между серверами нужно гонять только изменения состояний и кое-какую управляющую информацию. Если, конечно, это не SOAP-вызовы.

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

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

Это — да.

TK>Для statefull это окажется достаточно не тривиальной задачей и рано или поздно — приложение упрется в физические возможности конкретной машины.

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

TK>Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п.

Откуда такое утверждение? Это совершенно необязательно.

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

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



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

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

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

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

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

Сейчас навскидку не скажу, помотри где-то cetus-links был документ из серии "XX мифов об объектных базах данных".

>> IT>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
>>
>> Т.е., по сути — превращение stateless в stateful? Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.
>>
TK>Наличие кеша — это еще не признак наличия состояния. Преимущество stateless это в аттомарности операций и в том, что никакого промежуточного состояния не сохраняется памяти сервера. т.е. после того, как была выполнена stateless опарация — мы можем забыть о конкретном frontend сервере и следующий запрос может быть с тем-же успехом обслужен любым другим.

Ну вот, кстати, как раз та самая подмена понятий, о которой упоминал AVK. Как ты реализуешь атомарную операцию, если она растянута, к примеру, на 30 минут? На все 30 минут блокируешь данные? Нет, конечно. Ты разбиваешь её на серию более мелких, отмечающих промежуточные, т.е., недолговременные состояния системы. Таким образом, реализуется в десяток раз больше обращений к БД, чем в случае, когда промежуточное состояние хранится в памяти App-сервера и записывается только одно — последнее изменение. А в случае stateless, мы получим по сути, тот же stateful, но "под микроскопом", где из-за каждого чиха появляется серьёзная програмисткая задача.

>> AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
>> IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
>>
>> Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.
>>
TK>Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.

Вот и плохо, что они хранятся только в БД. ИМХО, разумеется. Если бы они выстраивались в памяти, то общая вычислительная нагрузка на сервер была бы меньше. И не надо говорить, что это потребовало бы очень много памяти. Даже если у нас миллион сообщений, то для того, чтобы затолкать в память все соответствующие деревья сообщений нужно ~16 * 10^6 байт — т.е., всего-то около 16 мегабайт.

И с другой стороны — дерево сообщений это и есть один из типов объектов.

>> AVK>>[...] не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
>> IT>Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
>>
>> Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.
>>

TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

Угу, только с привлечением БД всё это работает намного медленнее, чем в памяти App-сервера, хотя бы как минимум в силу того, что для обращения к этому объекту задействуются драйверы БД, паковка/распаковка SQL и т.п. Не говоря уже о том, что в пределе вся бизнес-логика улетает в ХП+триггеры...

TK>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.

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

>> Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.
TK>Кеш и внутреннее состояние — это несколько разные вещи.

Всё зависит от того, что именно в этом кэше лежит. Если это просто записи БД, то — да, если предварительно созданные объекты, то нет.


PS. 2 Moderator, извините за оверквотинг.