Здравствуйте, Tom, Вы писали:
M>>И ведь все все знали Tom>Ну да слава богу ГУРУ нас не оставил.
M>>Это все происки MS Tom>тсссс. а то если они узнают, что мы знаем.....
Стебаешься?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaFlour, Вы писали:
LF>Здравствуйте, Tom, Вы писали:
хъ
LF>Распределение нагрузки — это гуд, но тут тоже думать надо. LF>а тут уже советую посмотреть в сторогу GRID и SOA — на сайте оракле посмотри, у них уже есть готовая LF>технология по распределению нагрузки между серверами, может идей какихто почерпнешь оттуда
У MS своя технология Load balansing была еще в 98 году.
Здравствуйте, IT, Вы писали:
IT>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
Это вряд ли. В первом варианте не нужно воевать со временем жизни объектов, а во втором лизинг справляется только с несложными случаями. Нет, я конечно помню что ты приверженец стейтлесс и в этом случае действительно особой разницы между вариантами не будет, но не всегда оно катит.
Здравствуйте, outsourcer, Вы писали:
O>Моё imho голосует за второй подход. Конечно всё можно подвергать сомнению и много зависит от типа проекта, но... O>1) Если необходимо внести изменения в реализацию уровня бизнес-логики, то проще потом переинсталлять один сервер, чем k клиентов
Клиенты все сверхтонкие и напрямую с middle tier не работают. Речь идет о различных подсистемах сервера.
O>2) Если предполагается одновременная работа (возможно различных) клиентов с одними и теми же объектами бизнес-логики, то лучше их разместить на сервере или придется продумать, как им сообщать об изменениях локальных копий (и вообще, сразу появится вопрос с целостностью распределенных данных)
Нет необходимости. По большей части задачки стейтлес.
O>3) По опыту: 2 типа построение системы психологически располагает к аккуратному проектированию. Вероятно потому, что хорошо прослеживается граница между уровнем бизнес-логики и уровнем пользовательских приложений.
А как быть с тем что вызов по ремоутингу в десятки тысяч раз медленее локального? Неужели приведенные пункты являются тому оправданием?
Здравствуйте, AndrewVK, Вы писали:
IT>>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
AVK>Это вряд ли. В первом варианте не нужно воевать со временем жизни объектов, а во втором лизинг справляется только с несложными случаями. Нет, я конечно помню что ты приверженец стейтлесс и в этом случае действительно особой разницы между вариантами не будет, но не всегда оно катит.
Вот видишь, стейтлесс и здесь рулит
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Igor Trofimov, Вы писали:
AVK>>О, это большой и сложный вопрос
iT>Менее интересно не стало
Да я понимаю Просто что то сейчас настроения нет на такие темы распространяться, отдыхаем-с от программирования.
Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.
Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.
Стив Шварц, один из архитекторов СОМ+, а теперь наверное индиги, когда приезжал в Москву сказал примерно следующее:
никаких стейтлесов не существует в природе. Любой вариант это стейтфул. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".
А дальше начинается самое интересное. Заученное "стейтлес всегда лучше масштабируется" оказывается не всегда верным! Нет, оно так если все данные под гребенку отнести либо к стейтлес, либо к стейтфул модели. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д.
Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь показано то что что обычно обзывают стейтлес моделью. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных вся мощная логика поддержки блокировок/версий и изоляции в sql серверах работает по сути в холостую. А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.
Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом
AVK>Извини за философию, но что то меня сегодня на конкретику не тянет .
Да куда уж конкретнее. Спасибо, очень интересные размышления.
AVK>Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом
Здравствуйте, AndrewVK, Вы писали:
AVK>Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом
Ok. Но все видели, это не я начал
AVK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.
Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо. Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова. Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.
AVK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.
Было бы здорово, если бы ты привёл пример когда без этого не обойтись.
AVK>А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.
Удаление гланд через отверстие так же как и ремонт клапанов через выхлопную трубу никогда не было весомым аргументом.
Что касается хранения состояния в БД, так где же ему ещё храниться как не в БД. Точно так же можно сказать, что делая стэйтфул модель, ты всего лишь изобретаешь ещё один велосипед и создаёшь ту же самую БД, только в памяти и со своим API
AVK>Стив Шварц, один из архитекторов СОМ+, а теперь наверное индиги, когда приезжал в Москву сказал примерно следующее: AVK>никаких стейтлесов не существует в природе. Любой вариант это стейтфул. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".
Грамотный мужик. Всё правильно говорит. Вопрос только в том как теперь его мысль интерпретировать.
AVK>А дальше начинается самое интересное. Заученное "стейтлес всегда лучше масштабируется" оказывается не всегда верным! Нет, оно так если все данные под гребенку отнести либо к стейтлес, либо к стейтфул модели. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д.
Ok.
AVK>Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь показано то что что обычно обзывают стейтлес моделью. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных вся мощная логика поддержки блокировок/версий и изоляции в sql серверах работает по сути в холостую.
Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.
AVK>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
Ерунда. Стэйтлес всегда подразумевает, что данные могут быть ещё не подгружены, поэтому при любых намёках на изменения кешированных данных кеш просто элементарно сбрасывается. О блокировках я вообще не понял. В стэйтлес блокировки не нужны.
AVK>В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.
Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
AVK>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
AVK>Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
На самом деле я вовсе не так против стэйтфул как ты против стэйтлес
Просто при больших нагрузках стэйтфул быстро упирается в ресурсы. То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.
Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.
Стэйтфул хорош для приложений с заранее детерминированной нагрузкой. Если можно просчитать, что ресурсов одного компьютера хватит с учётом роста нагрузки и будущих апгрейтов, то вперёд. Но как только одна сущность оказывается одновременно в двух местах, то всё... туши свет, кидай гранату.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
AVK>>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.
IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.
Надо, но только параметры вызова, а не внутреннее состояние.
IT>Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова.
А зачем делать два вызова одного и того же? Как я ниже писал — стейтфул модель себя оправдывает на редко изменяющихся данных, а для них такое просто бессмысленно.
IT> Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.
А это палка о двух концах. Тут и без клонирования ясно — основная проблема стейтлес систем — изоляция, стейтфул — синхронизация, вне зависимости от наличия / отсутствия клонирования.
AVK>>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.
IT>Было бы здорово, если бы ты привёл пример когда без этого не обойтись.
Когда сложные, разветвленные и непредсказуемые действия клиента на относительно длинном интервале времени должны иметь возможность быть откачеными в любой момент. Например документс большим количеством подчиненной информации, при том что эта информация может быть создана только с участием сервера. Альтернатива длинным транзакциям в этом случае одна — реализация механики транзакций и отката на клиенте с серьезными проблемами синхронизации и надежности.
Та же бяка в случае тяжелых и сложных алгоритмов, особенно если они распределенные, правда в этом случае хотя бы от клиента не зависим.
AVK>>А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.
IT>Удаление гланд через отверстие так же как и ремонт клапанов через выхлопную трубу никогда не было весомым аргументом.
Аргумент это сильное осложнение реализации для достижения результата, который может быть получен проще. Для стейтфул моделей такая механика естественна, а вот для стейтлес решается только привлечением тяжелой артиллерии ввиде механики внешних сессий.
AVK>>Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь показано то что что обычно обзывают стейтлес моделью. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных вся мощная логика поддержки блокировок/версий и изоляции в sql серверах работает по сути в холостую.
IT>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.
Счего бы это? Стейтфул модель как правило характеризуется еще и тем что у нее имеются расширенные метаданные бизнес-логики, т.е. значительно больше информации о предметной области, нежели у sql-серверов. Кроме того серверу приложений нет необходимости быть универсальным, его как правило задачивают под узкий круг задач. Отсюда механика управления на сервере приложений более оптимальна. Оптимизацией запросов при помощи сервера приложений можно добится эффективности кеша на не очень часто меняемых данных в районе 99% и практически полного отсутствия блокировок в БД. Это результаты реальной системы. Сервер же БД в такой схеме периодически получает интенсивные и кратковременные плевки.
AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
IT>Ерунда.
Может и ерунда но именно так оно выходит на реальных серверах.
IT>Стэйтлес всегда подразумевает, что данные могут быть ещё не подгружены, поэтому при любых намёках на изменения кешированных данных кеш просто элементарно сбрасывается. О блокировках я вообще не понял. В стэйтлес блокировки не нужны.
Самой стейтлес блокировки не нужны, о том и речь. Вся тяжесть изоляции в этом случае ложится на сервер БД. А вот ему то как раз и приходится несладко.
AVK>>В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.
IT>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
Только достигается оно куда большей кровью при помощи эмуляции тех же самых стейтов, о чем я ранее и писал.
AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
Я не писал о задачках вроде нашего сайта. Я ж говорю что ты там совсем отвык от нашей действительности . Основные задачи, для которых применяется трехзвенка это управление предприятиями. Причем "лоскутная автоматизация", ввиде кучи слабо зависимых клочков, использующих разные технологии обычно никого не устраивает, благо в России багажа старых систем пока еще практически нет. ВОт о таких системах и речь. Что же касается нашего сайта то можешь заметить что я первый же был против превращения нашего сайта в полномасштабную трехзвенку. У всех технологий есть границы применимости.
AVK>>Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
IT>Обращение может и не требует, а изменение требует по полной схеме.
Вот нифига подобного. Сложность синхронизации изменений ложится на сервер приложений, а не на его логику.
IT>И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
Пока не понадобится хранить состояния .
IT>На самом деле я вовсе не так против стэйтфул как ты против стэйтлес IT>Просто при больших нагрузках стэйтфул быстро упирается в ресурсы.
Смею повторится — задачки бывают разные. Если данные по большей части быстро устаревают стетфул модель будет неэффективна, если наоборот неэффективной будеть стейтлес модель. Рулит, как всегда, помимо тактического ядерного заряда конечно, золотая серидина. Т.е. грамотное, с учетом предметной области, распределение между стейтфул и стейтлес, причем желательно без явной границы, т.е. чтобы каждый объект в определенной пропорции был и стейтлес и стейтфул.
IT>То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.
Веб-приложения как правило никто и не стремится сделать стейтфул.
IT>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.
Не все так однозначно. Ровно так же резко усложняется проблема со стейтлес при больших нагрузках из-за лавинообразного нарастания блокировок в БД и ровно такой же геморой начинается при оптимизации этой самой БД и запросов к ней. Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.
Мне как то не приходилось пока делать системы под очень большую нагрузку, так что может поэтому я так скептически отношусь к чисто стейтлес модели.
IT>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой.
А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.
Здравствуйте, 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-модель.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.
Надо, но у тебя не размазано хранение состояния по двум максимально удалённым точкам — серверу БД и клиенту. Следовательно, есть возможность оптимизировать нагрузку на коммуникации. Следовательно, можно даже восстановить состояние клиента в полном объёме при обрыве/восстановлении связи "клиент-сервер", не привлекая к этому сервер БД.
IT>Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова. Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.
В сущности — да, и как раз клонирование появляется при размещении stateful-App-ядра (эк, термин-то ) на кластере. И клонирование действительно должно реализовываться вместе с синхронизацией, следовательно, его место — сугубо в ядре системы, где можно организовать выделенные связи между серверами, по которым не ездит клиентский трафик. И ещё отчасти поэтому появляется более строгое разделение функциональности клиента и сервера, следовательно — более стройная и удобная для модификаций система.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Hello, "Геннадий Васильев" > > Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности.
Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.
> IT>Что касается хранения состояния в БД, так где же ему ещё храниться как не в БД. Точно так же можно сказать, что делая стэйтфул модель, ты всего лишь изобретаешь ещё один велосипед и создаёшь ту же самую БД, только в памяти и со своим API > > В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая. >
Глубоко сомневаюсь на счет эффективности. stateless модель будет легко масштабироваться просто добавлением еще одного сервера. Для statefull это окажется достаточно не тривиальной задачей и рано или поздно — приложение упрется в физические возможности конкретной машины. Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п. Хотя, для не критичного приложения уровня подразделения — использование statefull модели — это разумный выбор.
> AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок. >
Для редко меняемых данных — второй SQL сервер и online репликация. Зачем зацикливаться на масштабировании сервиса, в большинстве случаев — многие из этих задач может на себя взять база данных.
> AVK>>В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.
Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?
> IT>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов. > > Т.е., по сути — превращение stateless в stateful? Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься. >
Наличие кеша — это еще не признак наличия состояния. Преимущество stateless это в аттомарности операций и в том, что никакого промежуточного состояния не сохраняется памяти сервера. т.е. после того, как была выполнена stateless опарация — мы можем забыть о конкретном frontend сервере и следующий запрос может быть с тем-же успехом обслужен любым другим.
> AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии. > IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных. > > Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов. >
Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.
> AVK>>[...] не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности. > IT>Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть. > > Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится. >
Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.
Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.
> Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru. >
Кеш и внутреннее состояние — это несколько разные вещи.
> IT>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой. Если можно просчитать, что ресурсов одного компьютера хватит с учётом роста нагрузки и будущих апгрейтов, то вперёд. Но как только одна сущность оказывается одновременно в двух местах, то всё... туши свет, кидай гранату. > > Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.
Причем — все это понимают и именно по этому становится популярной SOA
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>О, это большой и сложный вопрос iT>>Менее интересно не стало
Да я понимаю Просто что то сейчас настроения нет на такие темы распространяться, отдыхаем-с от программирования.
Ты можешь и сам прикинуть где такое может быть. Основной недостаток стайтфул модели — состояние приходится хранить в памяти на сервере. Если размер такого состояния велик начинаются траблы, кончается ресурсы сервера, память. конечно, IA64 и AMD64 как герои диснея "спешат на помощь", но это все только в краткосрочной перспективе.
Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтфул? Это самый натуральный стейтлесс — только в данном случае его реализация напоминает поведение стейтфул модели. А так, типичный стейтлесс — вызвали метод, он отработал, сбросил результаты и все — мы про него забыли. Реализация — же подобной функциональности через стейтфул — напоминает доставание гланд через неожиданное отверстие.
Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода). В остальном, стайтфул, стайтлесс — это одно и тоже. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".
А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д. что в общем-то не открытие америки.
Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь стейтлес моделью — проявляется во всей своей красе — получили данные, чуть-чуть обработали и забыли. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных есть большой соблаз запишхуть их в кеш и получить мощную отдачу от хорошего, современного сервера. А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую. А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша. Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции (все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные... И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.
В противоположность ей стайтлесс модель на таких данных ведет себя хорошо, поскольку гибкие возможности современных быз ранных, обладающих большей информацией о механизмах хранения данных (все основано на серьезном математическом аппарате), эффективных средствах кеширования и распределения информации — не вносит практически никакого оверхеда, но предоставляет поистинне фантастические возможности для масштабирования. Редко меняющиеся данные спокойно могут реплицировать на десяток не особо мощных машин, и когда будут идти обращения к БД, они не будут испытывать практически никаких блокировок — поскольку вся архитектура является распределенной и выполнять эту работу будет наименее загруженный участник.
Было одно преимущество стейтфул модели — считается, что программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, правда обращение к объекту требует потокобезопасности (кого это сейчас пугает?). Но, современные средства такие, как BizTalk сервер не только предоставляют удобные стредства для программирования бизнес логики, но и имеют массу шлюзов в уже имеющиеся системы.
Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от AVK в защиту стейтфул модели и неделя будет завершена достойно целым философским трактатом
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Если нам не помогут, то мы тоже никого не пощадим.
Откуда обобщения?
