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

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

Ага.

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

IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо. Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова. Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.

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

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

Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности. Например, ЦПУ может работать с памятью без кэшей L0-L2? Без конвейеров? Может! Только общая скорость обработки упадёт.

[...]

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

В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.

[хрум]

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

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

Ты о чём? Откуда обобщения?

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

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

Блокировки автоматом реализуются SQL-сервером. Ну не dirty-read же, в самом деле!

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

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

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

Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.

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

Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.

---

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

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

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

Правда, и потребности в масштабировании уменьшаются. Кстати, такую же необходимость в синхронизации ты получишь, когда будешь определять "намёк" на изменение данных, чтобы сбросить stateless-кэши.

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

Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.