Здравствуйте, Cyberax, Вы писали:
C>А тут у нас проблем с когерентностью данных — не всегда просто понять
C>когда надо менять страницу, в случае изменения данных.
Это очень-очень традиционная проблема.
Есть более-менее традиционный путь решения этой проблемы: организация конвеера.
Конвеер устроен примерно так:
0. Web запрос
1. SQL запрос
2. Dataset
3. Rendered Page
4. Client Page

Работает это примерно вот таким образом:
1. Клиент делает запрос (0).
2. Сервер смотрит в кэш на предмет готовности rendered page для этого запроса.
2.1. Если page найден, то в зависимости от if-modified-since в хидерах запроса отправляется либо 304 (что быстрее всего) либо 200.
3. Если page не найдена или устарела, то она рендериться заново, используя датасеты из кэша. Это дает выигрыш в том случае, если датасеты имеют шанс на повторное исползьование, в противном случае можно конвеер сократить. Отрендеренная страничка кладется в кэш.
4. Если датасета в кэше нет или он устарел, то строится и выполняется SQL запрос. Датасет кладется в кэш.
5. Ключевой момент — вычисление устарелости датасета. Эта проверка выполняется на каждый запрос, и должна быть достаточно дешевой.
Возможные способы ее реализации:
1. Банальный таймаут. В сильно нагруженных приложениях очень помогает
2. Принудительный сброс кэша при модификации данных. Легко делать, если запрос достаточно тривиален, и все модификации проходят через то же веб-приложение
3. Выполнение специфичного SQL звпроса. Например, если у нас был какой-то отчет по продажам, то на if-modified-since достаточно проверить exists(select if from sales where sale_date > @lastResultDate), что очень дешево (и уж точно на порядок дешевле вычисления полного select ... group by ...)
4. Использование встроенных в СУБД механизмов подписки на оповещения об изменениях. Самый простой и прозрачный способ, но подходит не для всех СУБД.

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

S>Здравствуйте, Cyberax, Вы писали:
C>>А тут у нас проблем с когерентностью данных — не всегда просто понять
C>>когда надо менять страницу, в случае изменения данных.
S>Это очень-очень традиционная проблема.
S>Есть более-менее традиционный путь решения этой проблемы: организация конвеера.
S>Конвеер устроен примерно так:
S>0. Web запрос
S> 1. SQL запрос
S> 2. Dataset
S> 3. Rendered Page
S>4. Client Page
Хорошее, простое и неправильное решение.

S>Работает это примерно вот таким образом:
[skip]
S>4. Использование встроенных в СУБД механизмов подписки на оповещения об изменениях. Самый простой и прозрачный способ, но подходит не для всех СУБД.
Уууу... Не покрывает и части моих проблем

0. Web запроса нет. По причине отсутствия web-клиента — используем GUI на Java и C# (для PDA).
1. ОДИН запрос??? Ты смеешься?
2. Ты точно смеешься.
3. См. 0

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

При изменении БД у меня клиентам отсылаются извещения (через широковещательный надежный messaging, работающий через HTTP с comet-подобным сервером) с обновленными объектами. На клиенте есть понятие "сессий" — они открываются для каждого логического элемента (tab'а на форме редактирования, набору связных полей, таблицам и т.п.), эта сессия держит список видимых объектов. Когда приходят оповещения, то они пересылаются сессиям, в которых есть измененные объекты. Ну а дальше србатывает мой databinding, который дает feedback пользователю.

Причем, с помощью отсылки оповещений, содержащих измененные объекты, мы снимаем надобность в шторме SQL-запросов от всех подключеных клиентов. В результате, загрузка сервера с сотней клиентов, имеющих обновления в пределах пары секунд — почти минимальна.

Здравствуйте, Cyberax, Вы писали:
C>Хорошее, простое и неправильное решение.


C>0. Web запроса нет. По причине отсутствия web-клиента — используем GUI на Java и C# (для PDA).
Это другой совершенно вопрос.
C>1. ОДИН запрос??? Ты смеешься?
Почему один? Количество не имеет значения. Page и Dataset связаны многие-ко-многим. Это частности.
C>При изменении БД у меня клиентам отсылаются извещения (через широковещательный надежный messaging, работающий через HTTP с comet-подобным сервером) с обновленными объектами.
В идеологии request-oriented приложений (в частности в web) вместо рассылки извещений через широковещательный надежный messaging изменения применяются сразу к кэшу. Что существенно уменьшает throughput, т.к. экземпляр кэша ровно один независимо от количества клиентов.

C>На клиенте есть понятие "сессий" — они открываются для каждого логического элемента (tab'а на форме редактирования, набору связных полей, таблицам и т.п.), эта сессия держит список видимых объектов. Когда приходят оповещения, то они пересылаются сессиям, в которых есть измененные объекты. Ну а дальше србатывает мой databinding, который дает feedback пользователю.
Это 1-в-1 система, в написании которой я участвовал 10 лет назад. Только это были не PDA, а десктопы (с аналогичными, правда, характеристиками ).
C>Причем, с помощью отсылки оповещений, содержащих измененные объекты, мы снимаем надобность в шторме SQL-запросов от всех подключеных клиентов. В результате, загрузка сервера с сотней клиентов, имеющих обновления в пределах пары секунд — почти минимальна.

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

C>А, угадаю еще раз — в Microsoft?
То есть, все-таки маньяк?

C>Не таких уж узких. Почти всегда performance от кэша выигрывает.
Вопрос, как я уже говорил, в другом — нужны ли эти копейки...

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

C>>А, угадаю еще раз — в Microsoft?
IB>То есть, все-таки маньяк?
Я угадал?

C>>Не таких уж узких. Почти всегда performance от кэша выигрывает.
IB>Вопрос, как я уже говорил, в другом — нужны ли эти копейки...
Ускорение запроса в тысячу раз и приложения в разы. Подумаешь...

То-то RSDN все время тормозит и падает

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

C>Я угадал?
Ничего тебе не скажу..

C>Ускорение запроса в тысячу раз и приложения в разы. Подумаешь...
Во-первых, в тысячу или на доли процента — еще бабушка на двое сказала. Во-вторых, ускорение запроса хоть в десять тысяч раз, вполне может вылиться в ускорение приложения на те же доли процента.
Или ты таки серебряную пулю нашел?

C>То-то RSDN все время тормозит и падает
Тебе прекрасно известно почему RSDN тормозит и падает. Вот когда напишешь такой же, чтобы не тормозил и не падал, на таком же железе, тогда и будешь подкалывать.

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

C>>Ускорение запроса в тысячу раз и приложения в разы. Подумаешь...
IB>Во-первых, в тысячу или на доли процента — еще бабушка на двое сказала. Во-вторых, ускорение запроса хоть в десять тысяч раз, вполне может вылиться в ускорение приложения на те же доли процента.
Интересно, а как это можно выяснить, если для почти всех приложений на .NET, которые я только видел, добавление подобного кэша просто невозможно архитектурно?

IB>Или ты таки серебряную пулю нашел?
Ага, точно. Сам отлил из фамильного серебра.

C>>То-то RSDN все время тормозит и падает
IB>Тебе прекрасно известно почему RSDN тормозит и падает. Вот когда напишешь такой же, чтобы не тормозил и не падал, на таком же железе, тогда и будешь подкалывать.
Надо будет попробовать

Hello, Cyberax!
You wrote on Tue, 21 Aug 2007 10:22:28 GMT:

>> Судя по описанию, проблемы связаны с использованием неподходящего
>> инструмента. Запросы вроде "взять следующий элемент и сравнить с
>> двумя предыдущими" делаются на MDX элементарно.
C> У меня нет хороших и красивых упорядоченых последовательностей, по
C> которым можно строить кубики.

Пока я вижу только примеры запросов, которые прямо ложатся на временное измерение. Члены этого измерения можно отфильтровывать как душе угодно.

C> "Предидущий" элемент зависит от каждого конкретного параметра
C> отчета.

Это неважно. Понятие предыдущего элемента — PrevMember — встроено непосредственно в MDX и зависит от контекста, т.е. от текущего среза. Главное — получить этот срез.
Понимаешь, MDX дает достаточно гибкости в построении запросов, если рассматривать OLAP не только как средство просмотра заранее спроектированных кубов.

C> Представь себе расписание — нужно его автоматически составить.
C> Могут быть констрейнты типа "человек не должен работать более
C> двух дней подряд в одном подразделении"
C> или "работать только в один из выходных через две недели".

Подобная фильтрация по времени делается несложно. У меня только один вопрос: эти контрейнты к каким данным применяются?

C> Попробуй на досуге записать второе условие в SQL. Причем таких
C> параметров штук 20 (и постоянно добавляются).

Так речь о том и идет, что не надо для этого SQL использовать.
На самом деле, ты более пристально на MDX смотрел?

YК wrote:
> C> У меня нет хороших и красивых упорядоченых последовательностей, по
> C> которым можно строить кубики.
> Пока я вижу только примеры запросов, которые прямо ложатся на временное
> измерение. Члены этого измерения можно отфильтровывать как душе угодно.
Они не являются "временными". Там получится дофигамерная
динамическая структура, если ее формализовать (я пытался — для
применения симплекс-метода оптимизации).

Представь себе расписание — это само по себе двумерная стркутура. Каждая
клетка влияет на свой столбец и свою строку. Кроме того, почти любое
изменение расписания косвенно влияет на остальное расписание.

Причем _количество_ данных — не такое уж и большое. Мне почти никогда не
нужно затрагивать данные, более чем за месяц (есть только несколько
годовых отчетов, запускаемых почти что раз в год). Количество людей и их
данные — тоже невелико (тысячи, максимум). В общем, объемы совершенно
смешные. Поэтому кубики абсолютно не нужны — мы простым линейным поиском
быстрее все обойдем.

Другое дело — алгоритмы. Мы сейчас собираемся лицензировать систему,
использующую генетический алгоритм для решения всех constraint'ов.

> Понимаешь, MDX дает достаточно гибкости в построении запросов, если
> рассматривать OLAP не только как средство просмотра заранее
> спроектированных кубов.
Да знаю я, использовал его. OLAP замечательно работает с массивами
независимых данных — типа объемов продаж.

> C> Представь себе расписание — нужно его автоматически составить.
> C> Могут быть констрейнты типа "человек не должен работать более
> C> двух дней подряд в одном подразделении"
> C> или "работать только в один из выходных через две недели".
> Подобная фильтрация по времени делается несложно. У меня только один
> вопрос: эти контрейнты к каким данным применяются?
Базовая структура — таблица assignment'ов. Простая связь один-ко-многим
человек<->assignment. Ну и куча информационных таблиц — доступность в
конкретный день, rate, performance, удобность для кандидата,
предпочтения работодателя, ограничения контрактов (ооо.... там их
стоооолько...).

Сейчас в реакторе всего 203 правила. Из них к расписанию относятся 132.

> C> Попробуй на досуге записать второе условие в SQL. Причем таких
> C> параметров штук 20 (и постоянно добавляются).
> Так речь о том и идет, что не надо для этого SQL использовать.
> На самом деле, ты более пристально на MDX смотрел?
Сначала был жуткий запрос на Oracle DML и SQL. С большой радостью от
него избавились.

Здравствуйте, AndrewVK, Вы писали:
AVK>Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
Философское высказывание, только как-то обычно не выходит избежать . Да и данные имеют свойство менятся, так что копии придётся синхронизировать .

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

S>А чего именно не хватает?
Если не ломать голову, рисуя собственные UDF — то практически всего
Начиная от простейших функций обработки строк.

Если писать UDF — картина немного сглаживается, но все равно — никак не стуктурированный набор из сотни разнообразных SP поддерживать мало кому понравится
Чувствушь себя вернувшимся из C# в Turbo Pascal...

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

C>Интересно, а как это можно выяснить,
Написать и посмотреть.

C> если для почти всех приложений на .NET,
Причем тут Net? Хоть на ассемблере пиши.

C> которые я только видел,
И много видел?

C> добавление подобного кэша просто невозможно архитектурно?
Значит такая архитектура, примерно как у гибернейта и продуктов на его основе..

C>Ага, точно. Сам отлил из фамильного серебра.
То-то я смотрю, старье какое-то подсовываешь..

C>Надо будет попробовать
Вот когда попробуешь, тогда голос и подавай.

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

AVK>>Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
A>Философское высказывание, только как-то обычно не выходит избежать .

Ну, тут у кого как.

A> Да и данные имеют свойство менятся, так что копии придётся синхронизировать .

Проектируй так, чтобы синхронизировать приходилось как можно меньше.

Hello, Cyberax!
You wrote on Tue, 21 Aug 2007 14:51:23 GMT:

C> Другое дело — алгоритмы. Мы сейчас собираемся лицензировать
C> систему, использующую генетический алгоритм для решения всех
C> constraint'ов.

C>>> Представь себе расписание — нужно его автоматически составить.
C>>> Могут быть констрейнты типа "человек не должен работать более
C>>> двух дней подряд в одном подразделении"
C>>> или "работать только в один из выходных через две недели".
>> Подобная фильтрация по времени делается несложно. У меня только
>> один вопрос: эти контрейнты к каким данным применяются?
C> Базовая структура — таблица assignment'ов. Простая связь
C> один-ко-многим человек<->assignment. Ну и куча информационных
C> таблиц — доступность в конкретный день, rate, performance,
C> удобность для кандидата, предпочтения работодателя, ограничения
C> контрактов (ооо.... там их стоооолько...).

C> Сейчас в реакторе всего 203 правила. Из них к расписанию относятся
C> 132.

Ок, понял. Просто по твоим изначальным примерам вся эта сложная кухня была неочевидна.

А Drools не пробовали использовать?

YК wrote:
> C> Сейчас в реакторе всего 203 правила. Из них к расписанию относятся
> C> 132.
> Ок, понял. Просто по твоим изначальным примерам вся эта сложная кухня
> была неочевидна.
> А Drools не пробовали использовать?
Сначала его и использовали, потом купили коммерческий движок.