Здравствуйте, IT, Вы писали: IT>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.
Хм. По-моему это все же максимализм. Щас не могу с точностью сформулировать пример, но я бы поостерегся выполнять все возможные проверки средствами БД. IT>При этом валидацию данных сервером приложений никто не отменяет. Более того, некоторые правила бизнес-логики можно проверить только средствами сервера приложений. Но тем не менее игнорирование контроля целостности данных сомой БД может привести к неправильной работе самого сервера приложений при 'непреднамеренной' порче данных, что скорее всего при данном подходе приведёт к краху всей системы.
IT>ЗЫ. Синклер, мы уже использовали обороты 'фигня' и 'чушь', поэтому в следующий раз когда будешь вырывать мои слова из контекста можно будет взять 'бред' или 'ерунда'
Ок, прошу прощения за несколько фривольный тон — в азарте погорячился. Вместо "фигня" читать "я не вполне согласен с вышесказанным".
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.
Вот что и требовалось доказать
AVK>Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать. AVK>Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.
Не вижу проблемы Хотя пожалуй вижу одну
AVK>Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?
Дать ему уникальный guid при создании.
IT>>Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.
AVK>У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.
Откуда сделан такой вывод? Пока я вижу, что ты не теми средствами решаешь поставленную перед тобой задачу. Возьми BizTalk и не мучайся (правда он стоит зараза), переписывать бизнес-правила тебе не придётся. Только перерисовывать
IT>>Т.е. ты всё же клонируешь объект?
AVK>В бизнес-коде нет, на клиента во многих случаях да.
Значит сервер у тебя занимается также синхронизацией и версионностью.
IT>>Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак
AVK>А про отдел автоматизации ни я, ни, насколько понимаю, ГВ и не говорят. Если ты ведешь речь об отделе автоматизации то безусловно в большинстве случаев единственный способ применить трехзвенку это либо использовать готовое решение, либо писать чисто стейтлес приложения с минимумов внутренних взаимосвязей.
Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы? Если первое, то пожалуйста. Если второе, то ничем от отдела автоматизации такая работа не отличается. Твоя задача не изобрести ещё один BizTalk, а максимально быстро и с наименьшими затратами решить поставленную задачу.
IT>>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).
AVK>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.
Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код? Код то всё равно писать
IT>>Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.
AVK>Разумеется. Только у стейтлес эту осведомленность проявить куда меньше возможностей. Сам же призаешь что в стейтлес модели основная тяжесть разруливания состояний ложится на sql сервер. С одной стороны это очень хорошо, особенно в малобюджетных проектах. Но с другой стороны это же ограничивает простор для оптимизации на основе метаданных бизнес-логики. Как всегда надо выбирать золотую середину.
Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.
IT>>Насчёт более оптимальных запросов, обеспечиваемых сервером приложений. Это справедливо только для примитивных запросов, и то же самое можно закешировать и в stateless. Для сложных запросов на практике это не реально. Пять строчек на SQL с парой вложенных джоинов обычно выливаются в десятки, если не в сотни строк на C++/C#/whatever, реализующих поиск, фильтрацию и сортировку в объектной модели и отнюдь не отличаются быстродействием доморощенных алгоритмов.
AVK>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.
Ну и как это противоречит stateless модели?
IT>> Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.
AVK>Хороши усилия — после каждого запроса скидывать состояние в БД
Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?
IT>>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию , давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.
AVK>Зря.
Зря что не отличаются?
IT>> Что там управление предприятиями, что тут,
AVK>Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.
Порядки начисления — это бизнес логика.
IT>>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.
AVK>Слова Стива Шварца помнишь?
Какие именно
IT>>Да уже и GUI не очень-то стремяться. Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы
AVK>Отстал от жизни Увлечение веб интерфейсами начинает имхо потихонечку спадать. Теперича, опять же помимо тактического ядерного заряда, рулит XAML, который не пойми что
Всё течёт, всё развивается. Где-то я отстал, где-то ты изобретаешь велосипед. Жизнь
AVK>>>Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.
IT>>Возможно. Насочинять можно много чего.
AVK>Ну он вроде как говорил где именно та или иная схемка реализована на практике.
На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.
AVK>>>Мне как то не приходилось пока делать системы под очень большую нагрузку, так что может поэтому я так скептически отношусь к чисто стейтлес модели.
IT>>Самое фиговое в stateful — это когда понимаешь что чтобы сделать следующий шаг, нужно пройти в два раза больше чем пройдено, что столько усилий потрачено, а результат получился хреновый.
AVK>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.
Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок
AVK> Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.
Ты так думаешь потому что тебе это просто пока не приходилось делать
AVK>>>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.
IT>>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.
AVK>Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.
Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда. Неумение это делать — это уже недостатки не архитектуры, а архитектора
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах. Tom>ну оно конечно так, али ж трошэчку не так. синглетон ты с 1 не реализуеш. да и вообще метод 1 наверно более подходит к стэйтлесс. из всего обсуждения прояснилась действительно не плохая мысль о хранении редко изменяемых данных где то по ближе, чем бд. а таких вроде как хватает. что скажешь?
Думаю, что дело синглетон здесь не при чём
IT>>В общем, не на том акцентируете внимание, товарищи. Tom>Угу. Тут попробуй сказать что нить. Так сразу или 'стэйтфульщик' или ещё чего
Не. По наклеиванию ярлыков у нас есть другие специалисты.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
IT>>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД. S>Хм. По-моему это все же максимализм. Щас не могу с точностью сформулировать пример, но я бы поостерегся выполнять все возможные проверки средствами БД.
Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
Если нам не помогут, то мы тоже никого не пощадим.
IT>В общем, не на том акцентируете внимание, товарищи.
Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.
TK>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?
А что это трудно сделать? Вроде как нет
А на нэте вообще можно красоту с контекстами придумать
TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.
ну ну. вот тебе тестик:
using System;
using System.Data;
using System.Data.OleDb;
using System.Data.Common;
using Microsoft.ApplicationBlocks.Data;
namespace _70
{
class Class1
{
public static String connStr = @"Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=RSDN;Data Source=PC31";
static void M1()
{
try
{
String reqSql = "SELECT * FROM users WHERE userid=4";
for (int i=0; i<1000; i++)
SqlHelper.ExecuteDataset(connStr, System.Data.CommandType.Text, reqSql, null);
}
catch(Exception e)
{
Console.WriteLine(e.Message);
}
}
static void M2()
{
try
{
String reqSql = "SELECT * FROM users";
DataSet ds = SqlHelper.ExecuteDataset(connStr, System.Data.CommandType.Text, reqSql, null);
for (int i=0; i<1000; i++)
ds.Tables[0].Select("userid=4");
}
catch(Exception e)
{
Console.WriteLine(e.Message);
}
}
[STAThread]
static void Main(string[] args)
{
M1();
M2();
Console.WriteLine("Mem cleaned!");
Console.ReadLine();
}
}
}
попробуй выполнить и прочувствовать разницу.
у меня профайлер сказал:
M1 — 4,290
M2 — 165
Просто в последнее время стало модным забивать и забиватся на сервер БД. Ну не эффективно это во многих случаях и приходится ручками лепить довольно много. Не надо делать из сервера БД — спасателей, которые всегда спешат на помощь (c) TK.
Здравствуйте, Tom, Вы писали:
TK>>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти? Tom>А что это трудно сделать? Вроде как нет
В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
Здравствуйте, Tom, Вы писали:
Tom>поправь меня если я тут это не прав в общем
Да легко.. А сделай, по бырому, тестик с группировкой, top 100 например..
M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
Что значит опаньки. Имелось в виду что то типа транзакций для состояния обьектов в оперативной памяти. e/g в методе произошёл эксепшин — все изменения состояния обьекта, произведённые в данном методе откатываются на момент до вызова. А если отключилось электричество то нужно бежать в магаз за покуда есть такая чудная возможность
ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции. Для этого по питанию ставят кондёры, энергия которых, используется при проподании питания.
Здравствуйте, Tom, Вы писали:
Tom>Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.
Сообщения у нас и так кешируются. Только не десять тысяч последних, а те к которым было недавнее обращение.
Tom>поправь меня если я тут это не прав в общем
Неправ. Сообщения у нас кешируются не потому что sql сервер не успевает, а потому что расцветка синтаксиса тормозит. Вот и делай теперь выводы
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции. Для этого по питанию ставят кондёры, энергия которых, используется при проподании питания.
Ага, на пару фарад
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
M>>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом. Tom>Что значит опаньки. Имелось в виду что то типа транзакций для состояния обьектов в оперативной памяти.
Что значит "типа"? одно из свойств ACID, а именно D, подразумевает, что если транзакция зафиксировалась, то откатить ее уже нельзя никаким образом. Вообще. Как ты ее собираешься в памяти фиксировать?
Tom> e/g в методе произошёл эксепшин — все изменения состояния обьекта, произведённые в данном методе откатываются на момент до вызова.
Ок, эксепшена не произошло, сказали commit, чего делаем? Данная транзакция уже стала историей, причем необратимой. На основе произведенных ею действий и внесенных изменений, начали работать другие транзакции.
А она у тебя по прежнему в оперативке, как я понял. Теперь какая-нибудь фигня случилась и не дошла твоя транзакция до диска, бывает. Получается, что другие транзакции работали с данными, которые на самом деле не существовали. Транзакции-то твоей нет больше.. Вот и опаньки. Вариантов не много, надо все другие транзакции, которые работали на основе той, что в памяти осталась и до диска не дошла, тоже откатывать надо. Но они тоже могли успеть зафиксироваться и на их данных могли начать работать другие транзакции...
Cascading Abort это называется, и все БД подобного сценария всячески избегают.
Концепцию БД, в принципе, тоже не глупые люди придумывали...
Tom>ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции.
А когда ты ее начать успел? У тебя же все в памяти....
Hello, "Tom" > TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер. > > ну ну. вот тебе тестик: >
[skip такому тестику]
> > попробуй выполнить и прочувствовать разницу. > у меня профайлер сказал: > M1 — 4,290 > M2 — 165 > > Просто в последнее время стало модным забивать и забиватся на сервер БД. Ну не эффективно это во многих случаях и приходится ручками лепить довольно много. Не надо делать из сервера БД — спасателей, которые всегда спешат на помощь (c) TK.
А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени...
И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Давай прям по пунктам. > > Более того, я сделаю более сильное утверждение, чем сделаное чуть выше: >
действительно интерактивную систему принятия решений на основе актуальных данных НЕВОЗМОЖНО сделать в рамках модели стейтлесс.
> На предстоящий вопрос почему сразу отвечу в виде леммы: > > Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
+1 stateless. Логика так-же остается на сервре. Клиент только готовит первичные данные.
> Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
+1 stateless. только первичные данные.
> Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).
Не совсем так... Не зря пртокол назвается SOAP и Web метод тоже не спроста.
> Следствие 1. из (3) получаем, что методы объекту, который отдается клиенту как бы и не нужны (все равно он все должен на сервере делать) единственное, что нужно объекту, который отдается клиенту — методы для некоего упрощения отображения, > типовых операций, которые можно сделать и в виде внешних классов на клиенте. > То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS
Ну, самый простой бизнес процес из нашей, так сказать, жизни.
Вот собрался Синклер приехать к нам 15-го на встречу, ну и пообщаться тоже. На работе ему это оформляют под это дело командировку, дают командировочные, когда приедет — устроится в гостинницу (может и нет — смотря по реализации), потом мы сходим в Ms, посидим там, дальше поедем пить пиво, купим пиццы и т.п. (кстати — предположим ему компания оплачивает только две пиццы, а купили 3), дальше пиво допили, разъехались, Синклер вернулся домой, отчитался за командировочные (а может и нет — ну, потерял бумажки) и на этом процесс завершился. Все предельно просто.
Вот опиши в двух словах как используюя ООП (так чтоб с наследованием, полиморфизмом и никаких процедур) и statefull сервера реализовать платформу для выполнения данного бизнес-процесса (командировка, пиво, пицца, возврат назад, отдача командировочных и взаимо-расчет)?
> Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.
Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.
> Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.
А зачем использовать стейтлесс и MBR? Или это доказательство по индукции (типа так полохо, так тоже плохо — значит по любому плохо)?
> Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений: >
> Стратегия № 1 ( известная как pessimistic locking + Repeatable Read): Мы должны блокировать объект, к которому кто-то получил доступ. Иначе, при начале изменений этим кем-то, все, кто уже получили тот же объект на чтение, будут иметь неактуальные (частичные) данные. В данной стратегии развития, мы получаем, что один человек, взявший в работу объект, не дает работать всем, кому этот объект нужен зачем-либо, пусть даже для join'ов.
Ну это уже прошлый век. Никто так давно не делает...
> стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.
А зачем делать копирование, если и так используется stateless? Точно от противного...
> > Предположение 3. Вернемся к Предположению 1 (1). Итак, Serializable и мы позволяем клиенту делать с объектом(-ами) все, что угодно, а при пересылке его (их) на сервер проверяем валидность действий и либо принимаем транзакцию, либо отменяем. > Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.
ты еще бы сказал про проблему версионников "кто последний тот и папа" — так вот, проблема эта от разврата. Делать надо все честно и по совести, если один успел, то все остальные желающие — даже и не суются и спокойно идут лесом. Либо синхронизирую свои данные до полной адекватности и повторяют попытку.
> Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели. > Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс. >
Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.
> стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть : >
>
> мы взяли из "неизменного" источника товар
> ввели количество
> возможно исправили цену
> Послали запрос и или получили success либо отопнуты по какой-либо причине (например — нет нужного количества товара
>
>
Это совсем простая схема. В реальности — все на много сложнее.
> TK>А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи? > А может их нет потому, что просто никому не пришло в голову их делать, так как "не модно"? >
так-же как и транзакции в памяти (зато быстро).
> TK>Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу... > Да... возможно, но вот актуальность инофрмации в таком случае обеспечивать тем труднее, чем проще переход на оффлайн.
Какие трудности видишь?
> >> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. > > TK>Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы, > Читай выше, почему такая стратегия не жизненна в любом месте, где нужна строгость в соблюдении точности и актуальности данных.
строгость в соблюдении точности и актуальности данных плохо согласуются с ручным / полу ручным вводом накладных. Так-же ничто не мешает и stateless делать все необходимые проверки.
> TK>SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает... > Да ну? они даже без потерь питания бывают... вот например есть диск, на котором лог файл.. пусть на этом диске есть всего 100 МБ свободного места если совершить достаточно длинную транзакцию — вся БД падает, причем — невосстановимо. самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то) а при отложеном до конца транзакции сбросе данных в БД места под лог вполне может хватить — все это случай из моего опфта... в транзакции было всего лишь 65000 объектов.
В stateless у тебя вряд-ли будет задейтвованно такое количество объектов... все ориентированно именно на короткую работу.
> +1 плюс к тому же, можно в памяти хранить часть особо часто используемых индексов — это даст возможность еще больше разгрузить компьютер, так как на текущий момент самое узкое место всех AppServer'ов да и вообще серверов — это дисковая система. >
Ну, имитацию БД в рамках App сервера мы уже обсуждали...
> Да? насчет отложеных загрузок — я уже как-то приводил пример с графом объектов. > представь себе, что объекты собраны в граф... нет, пусть будет дерево. в дереве — примерно ну например 64К объектов (совершенно реальная цифра — речь идет о справочнике товаров. > Если мы берем вариант совсем без отложеной загрузки, то: >
> Либо мы утягиваем с сервера, при любом неосторожно запросе, весь граф объектов (а нам-то нужен был только один). > Либо мы должны реализовывать отложеную загрузку своими руками, что сводит на нет одну из сильных сторон и аргументов в пользу AppServer'ов, ибо мы просто запрещаем таким образом хранить ссылочные данные. >
Вобщем — что-бы использовать stateless стоит пересмотреть архитектуру.
> TK>С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям. > Далеко не все. Проверено. > Например — как в нем нормально хранить счетные данные типа вот такого: >
у нас есть дерево и на каждом кровне нам нужно иметь в узле статистику по поддереву, которая считается рекрсивно.
> Я думаю, что через известное отверстие даже такой случай можно будет разрулить с помощью indexed view, но какой ценой??? И сколько будет стоить изменение какой-либо части алгоритма?
> В AppServer'е, использующем собственные (хранимые) индексы можно хранить даже такую экзотическую вещь.
При желании — я в БД так-же могу построить индекс и по дереву. В чем приемущество AppServer который будет его каждый раз грузить на себя все данные и перестраивать индекс не ясно...
> TK>"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения... > Ну не совсем.. часть данных, которые есть в AppServer'е могут быть, например, показаниями датчиков.. снимаемые в реальном времени. и ты об этом даже не узнаешь, так как они НИЧЕМ не отличаются от "обычных" бизнес объектов. >
Каждый датчик так-же может не отличаться от обчной stateless службы.
> А так — можно будет во многих случаях обойтись без этих специальных людий и посадить только одного такого Гуру (с большой буквы) который напишеть модуль O-R mapping'а и все. >
Вот читал форум по java — там до сих пор нормальные реализации O/R мапперов ищут. Так-же не забывай, что материализация объектов это тоже не самая быстрая операция.
> правильно.. при увеличении производительности сервера цена сперва растет логарифмически, потом — экспоненциально (второе — совсем недолго) но в результате рост получается ниже линейного. Говорю как краеевед — я иногда железяками торгую, так что стараюсь быть в курсе.
Что-же тогда google мега кластер не забабахали?
> >> > Да только вот незадача — как уже писалось выше ну не подходит стейтлес для интерактивных приложений... >
Это на твой взгляд
> TK>1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер. > Насчет количества блокировок на отдельном сервере — согласен, а вот длительность блокировок будет длиннее, так как при завершении транзакции более сложной, чем изменение одной записи в одной некластеризованой таблице потребует (с большой вероятностью) согласования между серверами, распределенных транзакций, что лишь повысит нагрузку на сервер при блокировке... так что тяжело решить однозначно что тут лучше — от задачи зависит.
что тебе так дался этот кластер? одну таблицу так-же можно на несколько серверов растащить... и без кластера.
> ЗЫ ко всему сразу... начал я писать этот ответ примерно в 09:00 по Москве, так что ежели чего пропустил — не обессудьте
Мы тут так долго сотояние не держим =)
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IT, Вы писали:
ГВ>>Гхм. Отвечу по своему... ммм... опыту. Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности. Например, ЦПУ может работать с памятью без кэшей L0-L2? Без конвейеров? Может! Только общая скорость обработки упадёт. IT>Может упадёт, а может и нет, всё зависит от задачи. Так в стэйтфул ты пытаешься решать проблему даже ещё не зная, существует ли она на самом деле. Оптимизацию запросов и кеширование в стэйтлес никто не отменял. Но делать это можно не только на этапе разработки, но и во время эксплуатации, наблюдая за поведением системы. А это означает прежде всего сокращение сроков разработки.
Да, всё правильно. Только никто не запрещает проводить аналогичные мероприятия и в ходе эксплуатации stateful-системы.
IT>>>Что касается хранения состояния в БД, так где же ему ещё храниться как не в БД. Точно так же можно сказать, что делая стэйтфул модель, ты всего лишь изобретаешь ещё один велосипед и создаёшь ту же самую БД, только в памяти и со своим API ГВ>>В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая. IT>Кто тебе сказал, что более эффективно
Потому что для того и проектируется.
IT>Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.
Во время, отведённое мне на разработку чего? А оптимизация... Не так страшен чёрт, как...
IT>>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже. ГВ>>Ты о чём? Откуда обобщения? IT>Оттуда, откуда и у АВК. От балды.
Ну тогда аргумент отклоняется.
IT>>>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.
ГВ>>Т.е., по сути — превращение stateless в stateful?
IT>Кешь и стэйтфул — это далеко не одно и тоже. Мне не нужно синхронизировать каждый объект и мне не нужно сложных механизмов для этого. Кеширование справочников и сброс кеша при изменении в БД пишется на коленке. А если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту, ...
С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?
IT>...то те же механизмы можно использовать для выноса кеша на сами клиенты. Вынос же стэйтфул на клиента — это брет.
Истинно так.
ГВ>>Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.
IT>Синхронизация кешей по своей сложности — это амёба в сравнении с тем каких монстров приходится писать для синхронизации полноценных стэйтфул моделей.
Ну спасибо, просвятил.
[skip обсуждение структуры RSDN]
IT>>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы. ГВ>>Правда, и потребности в масштабировании уменьшаются. IT>Я как раз думаю что наоборот.
Раз на раз не приходится.
IT>>>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой. Если можно просчитать, что ресурсов одного компьютера хватит с учётом роста нагрузки и будущих апгрейтов, то вперёд. Но как только одна сущность оказывается одновременно в двух местах, то всё... туши свет, кидай гранату. ГВ>>Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель. IT>И это наводит на серьёзные размышления
Угу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Причём здесь характер ключа? Ты посравнивай ради интереса. Да и ключи, они ведь тоже разными бывают.
TK>Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)?
Значит — и мапов тоже два.
TK>На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?
Нет, не всё и не всегда. Только тогда, когда это оправдано.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Хотя пожалуй вижу одну 
, давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.
Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.
Если нам не помогут, то мы тоже никого не пощадим.
не прав в общем 
Мы уже победили, просто это еще не так заметно...
покуда есть такая чудная возможность
Откуда обобщения?