Здравствуйте, TK, Вы писали:
TK>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.
Но если состояние не гонять по сети, а оставлять на сервере то получается стейтфул модель. Отсюда вывод — "все возможности масштабирования приложения просто упрутся в толщину канала". Что и требовалось доказать.
TK>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.
Мода еще не означает технической целесообразности. Веб сервисы вон тоже модны, только на практике толку от них немного.
TK>Причем — все это понимают и именно по этому становится популярной SOA
Здравствуйте, 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, извините за оверквотинг.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
TK>>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.
AVK>Но если состояние не гонять по сети, а оставлять на сервере то получается стейтфул модель. Отсюда вывод — "все возможности масштабирования приложения просто упрутся в толщину канала". Что и требовалось доказать.
ты-же не различаешь statefull / stateless только местом хранения данных? Рано или поздно все данные попадают в какое централизованное хранилище. stateless приложение не обязательно должно хранить свои данные "в канале". Никто не мешает организовать отдельное хранилище — главное, что сами stateless методы являются аттомарными — именно по этому данная архитектура лучше масштабируется.
TK>>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы. AVK>Мода еще не означает технической целесообразности. Веб сервисы вон тоже модны, только на практике толку от них немного.
Ну не скажи... веб сервис — это просто развитие уже существующих технологий. Были обычные веб сервера. В начале они предоставляли просто статичные данных, потом к данным добавилась динамика. потом, их стали использовать для коммуникации двух / трех приложений. Сейчас-же это самый удобный и рельно функционирующий способ связи между гетерогенными системами.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
AVK>>Можно процитировать по нормальному, а то прочесть не смог?
TK>Это не цитата
Да я понял, но уж больно много там прямого цитирования, разобрать очень тяжело. Вкратце замечу что я отнюдь не являюсь апологетом чисто-стейтлес или чисто стейтфул подхода. И считаю что делать стейтлес всегда, даже если это вызывает море гемороя ничуть не лучше безусловного же применения стейтфул.
Здравствуйте, TK, Вы писали:
TK>ты-же не различаешь statefull / stateless только местом хранения данных?
Я различаю очень просто — есть состояние вне клиента — стейтфул, иначе стейтлес.
TK>Рано или поздно все данные попадают в какое централизованное хранилище. stateless приложение не обязательно должно хранить свои данные "в канале". Никто не мешает организовать отдельное хранилище — главное, что сами stateless методы являются аттомарными — именно по этому данная архитектура лучше масштабируется.
Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.
TK>Ну не скажи... веб сервис — это просто развитие уже существующих технологий. Были обычные веб сервера. В начале они предоставляли просто статичные данных, потом к данным добавилась динамика. потом, их стали использовать для коммуникации двух / трех приложений. Сейчас-же это самый удобный и рельно функционирующий способ связи между гетерогенными системами.
Говоришь словами маркетологов. На практике область применения этих самых сервисов узенькая совсем.
Здравствуйте, AndrewVK, Вы писали:
TK>>Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless. AVK>Фиговая демонстрация если честно, сплошное передергивание
В чем передергивание?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, AndrewVK, Вы писали:
TK>>ты-же не различаешь statefull / stateless только местом хранения данных? AVK>Я различаю очень просто — есть состояние вне клиента — стейтфул, иначе стейтлес.
Нет состояния только у reference реализации. В остальных случаях — это больше подход к тому, как это состояние хранить — можно в памяти сервера, а можно делать каждый метод максимально независимым.
AVK>Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.
Какие неприятности? Если не делать сохранение данных "в лоб" то проблем никаких не возникнет.
AVK>Говоришь словами маркетологов. На практике область применения этих самых сервисов узенькая совсем.
Ага. Примерно как и у остального web.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Геннадий Васильев, Вы писали:
TK>>Все зависит от того, как реализации stateless модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.
ГВ>Это зависит от топологии сети. Межсерверный трафик может быть физически отделён от клиент-серверного, а сам по себе он отнюдь не велик, можешь посчитать. Особенно, если учесть, что между серверами нужно гонять только изменения состояний и кое-какую управляющую информацию. Если, конечно, это не SOAP-вызовы.
это я слово перепутал — stateless разговор был про реализацию хранения состояния на клиенте.
ГВ>Главная причина потери эффективности в stateless-модели состоит в том, что почти всегда в обработку вовлекается сервер базы данных, то есть этот "пирог" из клиента, app-сервера и сервера БД всегда "прорезается насквозь", и очень хочется этого избежать.
Не обязательно делать простой, трехслойный пирог. Слоев может быть несколько и в итоге каждое конкретное разрезание может и не доходить да самого последнего слоя.
ГВ>Это тоже в принципе верно, но для того в stateful-систему и добавляются механизмы синхронизации кэшей, хитрый арбитраж блокировок и т.п. Естественно, что мощности одной машины может и не хватить.
Вот именно — хитрые механизмы синхронизации, хитрые арбитражи. т.е. можно сказать, что синоним слова statefull это хитрый. В итоге сложность и стоимость системы растет слишком не пропорционально.
TK>>Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п. ГВ>Откуда такое утверждение? Это совершенно необязательно.
Ну, либо у нас один сервер, либо их несколько (тут конечно надежност и т.п.), но тогда как быть с аргументами о том, что в случае со стайтфул — очень просто организовать кеширование данных (несколько машин, общий кеш в памяти и т.п.)...
ГВ>Всё зависит от того, что именно и как сопровождается. Stateful-модель никак нас по сути не ограничивает в таком способе освобождения одного из серверов кластера, как перенос контекста пользователя на другой сервер. А это уже не полная и безоговорочная остановка работы системы а просто небольшая заминка.
Перенос контекста пользователя? Это уже достаточно интересная и не тривиальная операция, которая требует отдельной поддержки со стороны app сервера. Какие из них (+ цены) умеют подобное?
ГВ>Хммм... Про репликацию в данном контексте не согласен ни разу. Если её использовать для обеспечения зеркальности параллельно используемых данных, то всегда есть вероятность влететь строго в промежуток между репликациями. Ну уж не-е-ет...
Тогда, чем отличаются редко изменяемые данные, от не редко изменяемых? Разумным риском. Для редко изменяемой информации (например названия городов) мы можем закрыть глаза на то, что какое-то изменение в названии произойдет не одновременно на всех app серверах, а только после того, как будет обновлена информация в кеше — благодаря этому мы можем съекономить на обращениях к БД.
TK>>Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?
ГВ>Сейчас навскидку не скажу, помотри где-то cetus-links был документ из серии "XX мифов об объектных базах данных".
вот и результат, единственное, что можно уверенно сказать про объектные базы данных — "навскидку не скажу и помотри где-то". Нормальной реализации нет (конечно — тут для велосипедов простор открыт)
ГВ>Ну вот, кстати, как раз та самая подмена понятий, о которой упоминал AVK. Как ты реализуешь атомарную операцию, если она растянута, к примеру, на 30 минут? На все 30 минут блокируешь данные? Нет, конечно. Ты разбиваешь её на серию более мелких, отмечающих промежуточные, т.е., недолговременные состояния системы. Таким образом, реализуется в десяток раз больше обращений к БД, чем в случае, когда промежуточное состояние хранится в памяти App-сервера и записывается только одно — последнее изменение. А в случае stateless, мы получим по сути, тот же stateful, но "под микроскопом", где из-за каждого чиха появляется серьёзная програмисткая задача.
Это ты про использование BizTalk Server? Согласен, в случае со statefull стратегией — легко сорваться и начать все делать руками.
TK>>Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.
ГВ>Вот и плохо, что они хранятся только в БД. ИМХО, разумеется. Если бы они выстраивались в памяти, то общая вычислительная нагрузка на сервер была бы меньше. И не надо говорить, что это потребовало бы очень много памяти. Даже если у нас миллион сообщений, то для того, чтобы затолкать в память все соответствующие деревья сообщений нужно ~16 * 10^6 байт — т.е., всего-то около 16 мегабайт.
Скажи честно — зачем, нужно дерево сообщений в памяти? На клиента достаточно отдать топик — дерево он построит самостоятельно.
ГВ>И с другой стороны — дерево сообщений это и есть один из типов объектов.
А он точно нужен?
TK>>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.
ГВ>Угу, только с привлечением БД всё это работает намного медленнее, чем в памяти App-сервера, хотя бы как минимум в силу того, что для обращения к этому объекту задействуются драйверы БД, паковка/распаковка SQL и т.п. Не говоря уже о том, что в пределе вся бизнес-логика улетает в ХП+триггеры...
В триггерах данные тоже можно кешировать. да и прослойка получается не такая уж и большая — особенно в свете возможного масштабирования.
ГВ>Да хоть груздь чешуйчатый. Суть-то проблемы не меняется: необходимо организовать согласованную работу нескольких компьютеров.
Oracle 10g. Не нужно никаких мощных серверов... просто ставим кучу машин уровня рабочей станции под линуксом.
ГВ>Всё зависит от того, что именно в этом кэше лежит. Если это просто записи БД, то — да, если предварительно созданные объекты, то нет.
Какая-то неувязочка... есть y = f(x) x — это записи, y это объект. f какое-то фиксированное преобразование. получается, что фиксированное преобразование + сырые данные это есть состояние? А если преобразование отложить?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>В остальных случаях — это больше подход к тому, как это состояние хранить — можно в памяти сервера, а можно делать каждый метод максимально независимым.
Вот о том и речь что на практике никуда от стейтфул не деться, только приходится это делать при помощи нетривиальных http-сессий.
AVK>>Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.
TK>Какие неприятности? Если не делать сохранение данных "в лоб" то проблем никаких не возникнет.
При чем тут в лоб? Ручная организация отката в бизнес-коде это совсем фиговая идея. Рассказать типичному бизнес-программисту что такое транзакция уже серьезная проблема, а заставить его реализовывать ролбеки совсем задница.
AVK>>Говоришь словами маркетологов. На практике область применения этих самых сервисов узенькая совсем.
TK>Ага. Примерно как и у остального web.
Что то пока не заметно этого остального, кроме сервисов, рассказывающих погоду по индексу на конверте. Круто конечно, но это все игрушки. Без транзакцию это все несерьезно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности. Например, ЦПУ может работать с памятью без кэшей L0-L2? Без конвейеров? Может! Только общая скорость обработки упадёт.
Может упадёт, а может и нет, всё зависит от задачи. Так в стэйтфул ты пытаешься решать проблему даже ещё не зная, существует ли она на самом деле. Оптимизацию запросов и кеширование в стэйтлес никто не отменял. Но делать это можно не только на этапе разработки, но и во время эксплуатации, наблюдая за поведением системы. А это означает прежде всего сокращение сроков разработки.
IT>>Что касается хранения состояния в БД, так где же ему ещё храниться как не в БД. Точно так же можно сказать, что делая стэйтфул модель, ты всего лишь изобретаешь ещё один велосипед и создаёшь ту же самую БД, только в памяти и со своим API
ГВ>В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.
Кто тебе сказал, что более эффективно
Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.
AVK>>>Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь показано то что что обычно обзывают стейтлес моделью. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных вся мощная логика поддержки блокировок/версий и изоляции в sql серверах работает по сути в холостую.
IT>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.
ГВ>Ты о чём? Откуда обобщения?
Оттуда, откуда и у АВК. От балды.
IT>>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
ГВ>Т.е., по сути — превращение stateless в stateful?
Кешь и стэйтфул — это далеко не одно и тоже. Мне не нужно синхронизировать каждый объект и мне не нужно сложных механизмов для этого. Кеширование справочников и сброс кеша при изменении в БД пишется на коленке. А если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту, то те же механизмы можно использовать для выноса кеша на сами клиенты. Вынос же стэйтфул на клиента — это брет.
ГВ>Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.
Синхронизация кешей по своей сложности — это амёба в сравнении с тем каких монстров приходится писать для синхронизации полноценных стэйтфул моделей.
IT>>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
ГВ>Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.
Ничего не кешируется. Не эффективно.
ГВ>Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.
Т.к. у нас SQL сервер и сайт на одной машине и они делят ресурсы, то такая оптимизация только повредит.
IT>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.
ГВ>Правда, и потребности в масштабировании уменьшаются.
Я как раз думаю что наоборот.
ГВ>Кстати, такую же необходимость в синхронизации ты получишь, когда будешь определять "намёк" на изменение данных, чтобы сбросить stateless-кэши.
Я же говорю — это делается на коленке. Могу привести пример дубового, но вполне эффективного и в то же время элементарного в имплементации решения. Хотя, я думаю, у тебя у самого таких предостаточно
IT>>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой. Если можно просчитать, что ресурсов одного компьютера хватит с учётом роста нагрузки и будущих апгрейтов, то вперёд. Но как только одна сущность оказывается одновременно в двух местах, то всё... туши свет, кидай гранату.
ГВ>Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.
И это наводит на серьёзные размышления
Если нам не помогут, то мы тоже никого не пощадим.
Ну ты силён, бродяга.
TK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стайтфул модели — состояние приходится хранить в памяти на сервере. Если размер такого состояния велик начинаются траблы, кончается ресурсы сервера, память. конечно, IA64 и AMD64 как герои диснея "спешат на помощь", но это все только в краткосрочной перспективе.
Ровно то же самое произойдёт с SQL-сервером. Как в том анекдоте: "Жить-то Win'95 на 4 мегабайтах будет, но и только". Ты очень и очень спешишь с обобщениями. Кроме того, хранение состояний в памяти это не "недостаток", как ты утверждаешь, а всего лишь черта stateful-модели. Недостатком оно становится в тех или иных случаях, не более того.
TK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий.
Угумс. А ещё мы наблюдаем попытку впарить BizTalk.
TK>Если мы скидываем данные в БД, то какой же это, к черту, стейтфул? Это самый натуральный стейтлесс — только в данном случае его реализация напоминает поведение стейтфул модели. А так, типичный стейтлесс — вызвали метод, он отработал, сбросил результаты и все — мы про него забыли. Реализация — же подобной функциональности через стейтфул — напоминает доставание гланд через неожиданное отверстие.
TK>Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее: TK>никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода).
Но никак не пример stateless-объекта. Напоминаю азы ООП: объекты суть состояния и методы, изменяющие состояния. Приведённый тобой пример — пример процедуры, а не метода. Хотя да, такой метод может быть... например, статическим.
TK>В остальном, стайтфул, стайтлесс — это одно и тоже. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".
На самом деле вопрос несколько шире, чем просто хранение сотояний. Вопрос ещё и в методах обработки этих самых состояний. И кстати, тот ещё вопросик...
TK>А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта.
Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной. Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
TK>Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д. что в общем-то не открытие америки.
TK>Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее.
А вот это утверждение, кстати, спорно. Часто обновляемые данные можно обновлять в БД с некоторой задержкой, что уже само себе может дать некоторый выигрыш в общей производительности.
Здесь есть очень интересная деталь, про которую обычно принято забывать. Те же самые заказы, отгрузки прочая шелупонь прежде чем достичь места хранения сначала всегда создаются на одном из промежуточных или клиентском уровне. Исключение составляют случаи прямой связи клиента с сервером БД, но мы же не о них говорим, верно? Так вот, использование stateful даже здесь позволит получить некоторый выигрыш. Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. Опять-таки, можно, конечно, прокрутить ещё одну транзакцию в БД, она же у нас гибкая как змея и современная как космический корабль, но есть идея лучше: задержать накладную в памяти App-сервера на 180-300 секунд, тем самым освободив сервер БД от обязательных для него, но совершенно не нужных в контексте приложения транзакций. Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.
Правда, справедливости ради, следует заметить, что реализация такого подхода требует достаточной квалификации и самостоятельности программистов, что, увы, может стать проблемой в современных условиях.
TK>Собственно здесь стейтлес моделью — проявляется во всей своей красе — получили данные, чуть-чуть обработали и забыли. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных есть большой соблаз запишхуть их в кеш и получить мощную отдачу от хорошего, современного сервера.
Кстати, подойдёт и не такой уж "мощный и современный". Несовременного вообще ничего нет. "Не бойся быть несовременным, это единственное, чего тебе не удастся." — (c) Сальвадор Дали.
TK>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
TK>А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша.
Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД. Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется. Конкретный App-сервер может ни шиша не знать о прикладной специфике.
TK>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
TK>(все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные...
А вот это, кстати, косвенно подтверждает тезис о снижении производительности OLTP в stateless-модели. Второе аналогичное подтверждение состоит в том, что в тестах TPC-C MS использовала COM+ только для чтения данных, а обновление запускались через обычный ODBC. Что, в принципе, логично, если рассматривать stateless-модель в её естественной ипостаси — как удобной модели для трансформации представления данных.
TK>И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.
Ухх... в итоге получается нечто, достойное рекламной статьи на сайте Microsoft, уж извини. Ты утверждаешь, что нельзя обеспечить согласование кэшей? А на основании чего ты так говоришь? Уж не основании ли того, что у тебя в распоряжении нету компонента "StatefulCacheSyncronizer"?
TK>В противоположность ей стайтлесс модель на таких данных ведет себя хорошо, поскольку гибкие возможности современных быз ранных, обладающих большей информацией о механизмах хранения данных (все основано на серьезном математическом аппарате), эффективных средствах кеширования и распределения информации — не вносит практически никакого оверхеда, но предоставляет поистинне фантастические возможности для масштабирования. Редко меняющиеся данные спокойно могут реплицировать на десяток не особо мощных машин, и когда будут идти обращения к БД, они не будут испытывать практически никаких блокировок — поскольку вся архитектура является распределенной и выполнять эту работу будет наименее загруженный участник.
1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.
2. Оверхед таки вносится.
3. Математический аппарат в хинтах... ммм... это даже не смешно.
4. Читается конечно, на одном дыхании, в этом не откажешь.
TK>Было одно преимущество стейтфул модели — считается, что программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, правда обращение к объекту требует потокобезопасности (кого это сейчас пугает?). Но, современные средства такие, как BizTalk сервер не только предоставляют удобные стредства для программирования бизнес логики, но и имеют массу шлюзов в уже имеющиеся системы.
Угу, продажа BizTalk уже началась.
TK>Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от AVK в защиту стейтфул модели и неделя будет завершена достойно целым философским трактатом
Мда, неплохое воскресенье выдалось.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Hello, "AndrewVK"
> > Что то пока не заметно этого остального, кроме сервисов, рассказывающих погоду по индексу на конверте. Круто конечно, но это все игрушки. Без транзакцию это все несерьезно.
Можно использовать BizTalk — он поддерживает и веб методы и транзакции.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IT, Вы писали:
iT>>Мнения двух сторон — лучшая пища для размышлений.
IT>Причём, что самое интересное, я во многом разделяю любовь АВК к стэйтфул,
Разве это следует из моих размышлений? По моему я ясно сказал что предпочитаю взвешеный подход, просто в защиту стейтлес и без меня уже много сказано, а вот стейтфул клеймят все кому не лень, как будто она вобще не имеет право на существование.
IT>но раз уж он мне навесил ярлык стэйтлещика, то будем его носить гордо
Где это я на тебя ярлык навешивал? Просто ты очень часто проповедуешь стейтлес модель.
Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности. 
Если нам не помогут, то мы тоже никого не пощадим.
Откуда обобщения?
