Hello, Ivan!
You wrote on Mon, 20 Aug 2007 11:58:10 GMT:
ID> Возможно, кто-то встречался с интересными паттернами или просто ID> поделится опытом — где лучше всего решать проблемы синхронизации ID> в сервере приложений?
Здравствуйте, Ivan Danilov, Вы писали:
ID>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
ID>Можно линк на статью/best practices etc.
Можно рассмотреть ActiveObject или instance-per-request (SingleCall в remoting или IHttpHandler в веб приложениях).
Какие именно проблемы синхронизации вы хотите решить?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Можно рассмотреть ActiveObject или instance-per-request (SingleCall в remoting или IHttpHandler в веб приложениях).
TK>Какие именно проблемы синхронизации вы хотите решить?
Собственно, классы, взаимодействующие с клиентом являются Stateless. А вот под ними лежат контроллеры, которые работают с business entities и используют хранилища.
Соответственно, основная проблема — куда засунуть код, контролирующий целостность данных (т.е. предотвращающих запись и запись/чтение одновременно), чтобы он не торчал из всех дыр в приложении. Как его централизовать, что-ли?
Здравствуйте, Ivan Danilov, Вы писали:
TK>>Какие именно проблемы синхронизации вы хотите решить? ID>Собственно, классы, взаимодействующие с клиентом являются Stateless. А вот под ними лежат контроллеры, которые работают с business entities и используют хранилища.
ID>Соответственно, основная проблема — куда засунуть код, контролирующий целостность данных (т.е. предотвращающих запись и запись/чтение одновременно), чтобы он не торчал из всех дыр в приложении. Как его централизовать, что-ли?
А нельзя переложить все эти concurrency заботы на хранилища данных? Если на хранилища данных это переложить нельзя, то можно применить АОП и полностью отделить логику доступа от логики контроля.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>А нельзя переложить все эти concurrency заботы на хранилища данных? Если на хранилища данных это переложить нельзя, то можно применить АОП и полностью отделить логику доступа от логики контроля.
В принципе, на хранилища переложить можно. Немного, правда, боюсь дедлока, который на таком низком уровне отследить не удастся никак. Простейший способ синхронизации — использование ключевого слова lock на хранилище, но при дедлоке он просто повесит весь сервер Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
Что касается Аспект-оринетированного программирования — кроме названия, я о нем не знаю ничего Буду гуглить.
ID> Простейший способ синхронизации — использование ключевого слова lock на хранилище
Был неправ, он вообще ничем не помогает. Объекты-то могут быть уже получены другим потоком. Лочить business entities? Их же тысячами используют... Повесится
Здравствуйте, Ivan Danilov, Вы писали:
ID>В принципе, на хранилища переложить можно. Немного, правда, боюсь дедлока, который на таком низком уровне отследить не удастся никак. Простейший способ синхронизации — использование ключевого слова lock на хранилище, но при дедлоке он просто повесит весь сервер Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
т.е. хранилище это нечто самопальное, а не готовая БД с поддержкой техже транзакций?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Был неправ, он вообще ничем не помогает. Объекты-то могут быть уже получены другим потоком. Лочить business entities? Их же тысячами используют... Повесится
Если хранилище "свое собственное" то наверное, мало чего остается... с другой стороны, если блокировка есть только на чтение/запись — это может быть не так сложно...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Ivan Danilov, Вы писали:
ID>> БД присутствует. FireBird 1.5. IB>Ну вот пусть этим FB и занимается. Получится проще, надежнее и быстрее.
Здравствуйте, Ivan Danilov, Вы писали:
ID>>> БД присутствует. FireBird 1.5. IB>>Ну вот пусть этим FB и занимается. Получится проще, надежнее и быстрее.
ID>Хм. А кэшированные данные как охранять?
Тут можно определиться с тем, насколько критичными являются кешированные данные. В каких-то случаях, может оказаться достаточным просто сбросить закешированное значение при его изменении. для каких-то, можно завести специальную табличку в FB для отслеживания блокировок...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ivan Danilov, Вы писали:
ID>>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
AVK>Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
Как можно их избежать? В любом случае несколько потоков будут работать с одними и теми же данными. Я себе с трудом представляю другой вариант...
Здравствуйте, Ivan Danilov, Вы писали:
ID>Хм. А кэшированные данные как охранять?
Во-первых, заниматься кешированием в рукопашную, только после того как стало понятно, что есть узкое место и оно лечится кешированием.
А во-вторых — не охранять, а просто грохать при поступлении новых данных.
Здравствуйте, TK, Вы писали:
TK>Тут можно определиться с тем, насколько критичными являются кешированные данные. В каких-то случаях, может оказаться достаточным просто сбросить закешированное значение при его изменении. для каких-то, можно завести специальную табличку в FB для отслеживания блокировок...
Мда, про то, что можно просто сбросить кэш я банально не подумал.
Получается что-то типа строк в CLR — один раз получил и они всегда константные. А при изменении создается новый объект, который ложится в кэш.
Процедура обновления будет выглядеть примерно так:
class Updater { // класс, которому зачем-то надо поменять данные
...
public void ChangeData(int ID) {
IFirstBE old = firstBE_DAC.Get(ID);
IFirstBE editing = old.Clone();
// some operations with editing
...
bool success = firstBE_DAC.Update(editing, old);
}
}
class FirstBE_DAC {
...
public IFirstBE Get(int ID) {
if (_cache.ContainsKey(ID))
return _cache[ID];
IFirstBE entity = GetFromDb(ID);
_cache.Add(ID, entity);
return entity;
}
public bool Update(IFirstBE edited, IFirstBE old) {
current = Get(edited.ID);
if (match(current, old) {
_cache[edited.ID] = edited;
UpdateToDB(edited);
return true;
}
else
{
// optimistic concurrency failedreturn false;
}
}
}
Правда, на класс кэша и бизнес-объектов тоже придется навесить SynchronizationAttribute, чтобы при добавлении/изменении и клонировании не попортились.
Здравствуйте, AndrewVK, Вы писали:
AVK>А никак, пускай FB кеширует.
Хм. А не слишком ли велики затраты на выполнение по 15 раз одних и тех же запросов? Само время выполнения запроса будет небольшим. Но пока запрос достучится до СУБД, пока вернется ответ... А если все это на разных машинах — то еще плюс латентность сети.
Только клонирование перенести в обязанности кэша. Чтобы выдавал не свой объект, а копию. И проблем меньше, и BE синхронизировать не надо будет — все равно у всех разные.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Хм. А не слишком ли велики затраты на выполнение по 15 раз одних и тех же запросов?
А это смотря что для тебя важнее — минимально возможное время отклика системы при низкой загрузке или максимально возможная загрузка при лимите на стоимость железа.
Здравствуйте, AndrewVK, Вы писали:
AVK>А это смотря что для тебя важнее — минимально возможное время отклика системы при низкой загрузке или максимально возможная загрузка при лимите на стоимость железа.
Минимальное время отклика при низкой нагрузке. Больше 100 пользователей пока что нету даже в перспективе, да и больших объемов данных нету. А вот разнесение по разным серверам вполне возможно, в целях безопасности (от меня это никак не зависит).
Думал даже при загрузке сервера считывать ВСЮ базу в память (по запросу на каждую таблицу), т.е. использовать БД исключительно для долговременного хранения, а всю текущую информацию держать в памяти.
Размер базы пока весьма скромный и не превышает 50 Мб, так что перегрузок сети быть не должно.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Минимальное время отклика при низкой нагрузке.
Ну тогда имеет смысл делать кеши в памяти.
ID>А вот разнесение по разным серверам вполне возможно, в целях безопасности (от меня это никак не зависит).
Разнесение чего по серверам? СУБД и апп-сервера? Все равно в таком случае как правило канал до БД толстый и в эксклюзивном пользовании, в отличие от канала до клиентов. Опять же, у тебя БД маленькая, значит и время проталкивания по сети невысоко. Значит имеет смысл учитывать только латентность. У тебя латентность канала до БД сопоставима со временем отклика апп-сервера на запрос клиента?
ID>Думал даже при загрузке сервера считывать ВСЮ базу в память (по запросу на каждую таблицу), т.е. использовать БД исключительно для долговременного хранения, а всю текущую информацию держать в памяти.
Совсем не факт что это приведет к сильному росту производительности. Хотя, кто его знает в случае FB.
И, в любом случае, для начала нужно сделать прототип с простейшими алгоритмами, а потом уже, если производительность не удовлетворяет, подкручивать где надо. Иначе есть риск проделать всю работу в холостую.
Здравствуйте, AndrewVK, Вы писали:
ID>>Минимальное время отклика при низкой нагрузке. AVK>Ну тогда имеет смысл делать кеши в памяти.
Что я и делаю
ID>>А вот разнесение по разным серверам вполне возможно, в целях безопасности (от меня это никак не зависит). AVK>Разнесение чего по серверам? СУБД и апп-сервера? Все равно в таком случае как правило канал до БД толстый и в эксклюзивном пользовании, в отличие от канала до клиентов. Опять же, у тебя БД маленькая, значит и время проталкивания по сети невысоко. Значит имеет смысл учитывать только латентность. У тебя латентность канала до БД сопоставима со временем отклика апп-сервера на запрос клиента?
Сопоставима. Там везде каналы толстые, т.е. локалка, поделенная на 2 домена.
ID>>Думал даже при загрузке сервера считывать ВСЮ базу в память (по запросу на каждую таблицу), т.е. использовать БД исключительно для долговременного хранения, а всю текущую информацию держать в памяти. AVK>Совсем не факт что это приведет к сильному росту производительности. Хотя, кто его знает в случае FB.
Хм. Как Вы написали чуть выше, имеет смысл учитывать только латентность. Она таким образом сокращается ровно вдвое — на запрос к СУБД (если посчитать каналы к серверу и клиенту одинаковыми).
А если еще учесть специфику данных — иерархическое дерево в БД, что влечет за собой большое количество запросов для обхода — выигрыш может быть даже и больше. Ведь так я все дерево сразу собираю на апп-сервере, а так его по частям придется выдирать из СУБД (например, если нужен отчет по ветке со всеми детьми).
AVK>И, в любом случае, для начала нужно сделать прототип с простейшими алгоритмами, а потом уже, если производительность не удовлетворяет, подкручивать где надо. Иначе есть риск проделать всю работу в холостую.
Делал. Загрузка всей базы и распихивание по business entities занимает около минуты, может быть чуть-чуть больше.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Только клонирование перенести в обязанности кэша. Чтобы выдавал не свой объект, а копию. И проблем меньше, и BE синхронизировать не надо будет — все равно у всех разные.
SynchronizationAttribute — их есть два. Один для COM+ другой, для ContextBoundObject. думаю, что ни тот ни другой тут не подойдут.
Что касается кеширования то, тут можно рассмотреть две альтернативы — кешировать объекты или кешировать "сырые" данные. Например, NHibernate занимается кешированием "сырых" данных. Вообще, если проект у вас относительно простой, можно рассмотреть использование того-же NHibernate/ActiveRecord это вполне может решить задачи кеширования/доступа к данным при минимальном риске от использования новой технологии
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Думал даже при загрузке сервера считывать ВСЮ базу в память (по запросу на каждую таблицу), т.е. использовать БД исключительно для долговременного хранения, а всю текущую информацию держать в памяти.
Не думаю, что считывать в память всю базу данных это будет хорошей идеей (лично я видел много отрицательных примеров когда, приложение становилось от этого слишком ресурсоемким и не поворотливым). Альтернативрой считывания всех данных в память может быть использование локальной БД содержимое которой, синхронизируется с "внешней" (Многие статьи с ключевым словом SmartClient рассказывают о подобном подходе). Локальная БД (тот-же встраиваемый firebird или SqlServer) будет крутиться в процессе сервера что даст высокую производительность (т.к все операции в рамках одного процесса) и эффективное использование ресурсов (хранение данных на локальном диске и т.п)
ID>Размер базы пока весьма скромный и не превышает 50 Мб, так что перегрузок сети быть не должно.
И бы рассмотрел "худший" сценарий. 50Мб надо будет скачать, сохранить в локальной памяти, плюс, орагнизовать к ним доступ и т.п. Все это может привести к достаточно ощутимой нагрузке.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
В плане загрузки всей базы — убрать один оператор LoadAll() для каждого маппера — не проблема. Это я буду уже под реальной нагрузкой смотреть — стоит там что-то прикручивать или пусть так работает
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Ivan Danilov, Вы писали:
ID>>Только клонирование перенести в обязанности кэша. Чтобы выдавал не свой объект, а копию. И проблем меньше, и BE синхронизировать не надо будет — все равно у всех разные.
TK>SynchronizationAttribute — их есть два. Один для COM+ другой, для ContextBoundObject. думаю, что ни тот ни другой тут не подойдут. TK>Что касается кеширования то, тут можно рассмотреть две альтернативы — кешировать объекты или кешировать "сырые" данные. Например, NHibernate занимается кешированием "сырых" данных. Вообще, если проект у вас относительно простой, можно рассмотреть использование того-же NHibernate/ActiveRecord это вполне может решить задачи кеширования/доступа к данным при минимальном риске от использования новой технологии
Мда, был неправ. Ну что ж, хорошо, что мне вовремя на ляп указали, спасибо
Буду юзать ReaderWriterLock.
Насчет NHibernate — я с ним не очень знаком, так что пока оставлю свое кэширование (все-таки уже написано, отлажено и протестировано), а если будет время/необходимость — вернусь к этому вопросу.
Фактически, я создал тему потому что боялся расползания локов по всему тексту — и идею, как этого избежать — уже получил, спасибо
Здравствуйте, Ivan Danilov, Вы писали:
ID> Но пока запрос достучится до СУБД, пока вернется ответ... А если все это на разных машинах — то еще плюс латентность сети.
Что такое Connection Pooling знаешь? "достучиться" в данном случае не правильный термин, правильный — "передастся". А это существенно меньше времени и латентность уже такой роли не играет.
Ну и второе — с кешем я бы по прежнему рекомендовал бы связываться только в том случае, когда станет ясно, что БД не справляется. При размере БД в 50 Мб, любая вменяемая СУБД ее все равно сама в память поднимет, так что возня с кешем в этом месте заметного эффекта не окажет.
IB wrote: > При размере БД в 50 Мб, любая вменяемая СУБД ее все равно сама в память > поднимет, так что возня с кешем в этом месте заметного эффекта не окажет.
Смотри что за приложение. Скорость извлечения данных из локального кэша
обычно в тысячи раз быстрее даже простого обращения к БД.
Если у нас есть много мелких запросов — выигрыш может быть весьма
значителен.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Ivan Danilov, Вы писали:
ID>> Но пока запрос достучится до СУБД, пока вернется ответ... А если все это на разных машинах — то еще плюс латентность сети. IB>Что такое Connection Pooling знаешь? "достучиться" в данном случае не правильный термин, правильный — "передастся". А это существенно меньше времени и латентность уже такой роли не играет.
Чтобы что-то передавать — сначала надо достучаться
Я не имел в виду открыть новый Connection, я имел в виду именно задержки при передаче запроса/ответа. И, кроме латентности,
IB>Ну и второе — с кешем я бы по прежнему рекомендовал бы связываться только в том случае, когда станет ясно, что БД не справляется. При размере БД в 50 Мб, любая вменяемая СУБД ее все равно сама в память поднимет, так что возня с кешем в этом месте заметного эффекта не окажет.
А какая разница, куда поднимет ее сама СУБД? О_о Предположим, что время обработки любого запроса СУБД — 0. То есть на время отклика влияет только сеть. Представь, что клиент хочет отчет, для формирования которого надо очень много небольших запросов (сейчас — вполне реальная ситуация). Если считать, что каналы клиент-апп.сервер и апп.сервер-субд.сервер одинаковые и пренебречь временем извлечения данных из кэша — производительность возрастет ровно вдвое.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Что я и делаю
Неправильно делаете.
ID>>>Думал даже при загрузке сервера считывать ВСЮ базу в память (по запросу на каждую таблицу), т.е. использовать БД исключительно для долговременного хранения, а всю текущую информацию держать в памяти. AVK>>Совсем не факт что это приведет к сильному росту производительности. Хотя, кто его знает в случае FB. ID>Хм. Как Вы написали чуть выше, имеет смысл учитывать только латентность. Она таким образом сокращается ровно вдвое — на запрос к СУБД (если посчитать каналы к серверу и клиенту одинаковыми). ID>А если еще учесть специфику данных — иерархическое дерево в БД, что влечет за собой большое количество запросов для обхода — выигрыш может быть даже и больше. Ведь так я все дерево сразу собираю на апп-сервере, а так его по частям придется выдирать из СУБД (например, если нужен отчет по ветке со всеми детьми).
Не надо так делать. Читайте классику. Хранимая процедура обхода дерева пишется на FB на раз-два. Прочитайте для начала статьи на RSDN, посвяшенные хранению иерархических структур.
AVK>>И, в любом случае, для начала нужно сделать прототип с простейшими алгоритмами, а потом уже, если производительность не удовлетворяет, подкручивать где надо. Иначе есть риск проделать всю работу в холостую. ID>Делал. Загрузка всей базы и распихивание по business entities занимает около минуты, может быть чуть-чуть больше.
Разработчики RDBMS уже вложили сотни человеко-лет в отладку ACID. Что, есть острое желание повторить всё то же самое? Если грамотно пользоваться сервисами CУБД, то всё получится само — и производительность, и масштабируемость, и параллелизм.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ivan Danilov, Вы писали:
IB>>Ну и второе — с кешем я бы по прежнему рекомендовал бы связываться только в том случае, когда станет ясно, что БД не справляется. При размере БД в 50 Мб, любая вменяемая СУБД ее все равно сама в память поднимет, так что возня с кешем в этом месте заметного эффекта не окажет. ID>А какая разница, куда поднимет ее сама СУБД? О_о Предположим, что время обработки любого запроса СУБД — 0. То есть на время отклика влияет только сеть. Представь, что клиент хочет отчет, для формирования которого надо очень много небольших запросов (сейчас — вполне реальная ситуация). Если считать, что каналы клиент-апп.сервер и апп.сервер-субд.сервер одинаковые и пренебречь временем извлечения данных из кэша — производительность возрастет ровно вдвое.
А если переписать отчет так, чтобы выполнялся один большой запрос вместо "очень много небольших", то производительность возрастет до оторопи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А если переписать отчет так, чтобы выполнялся один большой запрос вместо "очень много небольших", то производительность возрастет до оторопи.
А хранить нужные данные в памяти даст не тот же самый результат? За тем исключением, что так они уже разобраны и готовы, а результаты запроса еще нужно обработать перед передачей на клиента.
Здравствуйте, Sinclair, Вы писали:
ID>>А какая разница, куда поднимет ее сама СУБД? О_о Предположим, что время обработки любого запроса СУБД — 0. То есть на время отклика влияет только сеть. Представь, что клиент хочет отчет, для формирования которого надо очень много небольших запросов (сейчас — вполне реальная ситуация). Если считать, что каналы клиент-апп.сервер и апп.сервер-субд.сервер одинаковые и пренебречь временем извлечения данных из кэша — производительность возрастет ровно вдвое. S>А если переписать отчет так, чтобы выполнялся один большой запрос вместо "очень много небольших", то производительность возрастет до оторопи.
Только, вот сопровождаемость этого дела (если запихнуть всю логику в БД) может упасть точно так же...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Sinclair, Вы писали:
ID>>Хм. Как Вы написали чуть выше, имеет смысл учитывать только латентность. Она таким образом сокращается ровно вдвое — на запрос к СУБД (если посчитать каналы к серверу и клиенту одинаковыми). ID>>А если еще учесть специфику данных — иерархическое дерево в БД, что влечет за собой большое количество запросов для обхода — выигрыш может быть даже и больше. Ведь так я все дерево сразу собираю на апп-сервере, а так его по частям придется выдирать из СУБД (например, если нужен отчет по ветке со всеми детьми). S>Не надо так делать. Читайте классику. Хранимая процедура обхода дерева пишется на FB на раз-два. Прочитайте для начала статьи на RSDN, посвяшенные хранению иерархических структур.
Я в курсе пользы хранимых процедур и активно их использую. Статьи читал, и не только их.
AVK>>>И, в любом случае, для начала нужно сделать прототип с простейшими алгоритмами, а потом уже, если производительность не удовлетворяет, подкручивать где надо. Иначе есть риск проделать всю работу в холостую. ID>>Делал. Загрузка всей базы и распихивание по business entities занимает около минуты, может быть чуть-чуть больше. S>Разработчики RDBMS уже вложили сотни человеко-лет в отладку ACID. Что, есть острое желание повторить всё то же самое? Если грамотно пользоваться сервисами CУБД, то всё получится само — и производительность, и масштабируемость, и параллелизм.
ACID я использую именно из СУБД
Разворор вроде сейчас идет о кэшировании, а не о поддержке транзакций? В контексте кэша:
Атомарность (Atomicity) — не имеет смысла, т.к. при изменениях часть кэша просто сбросится. Никакие Commit/Rollback не требуются.
Непротиворечивость (Consistency) — оставляется полностью на откуп бизнес-логике и проверкам на стороне СУБД. Кэш тут вообще не при чем.
Изоляция (Isolation) — это и было проблемой. Но если сделать по копии данных для каждого потока — и она отпадает. А оптимистическая блокировка реализуется очевидным образом, — не в нее вложили сотни человеко-лет.
Долговечность (Durability) — для кэша не имеет смысла по определению.
Здравствуйте, Ivan Danilov, Вы писали: ID>А хранить нужные данные в памяти даст не тот же самый результат?
Нет, не тот же.
В отличие от данных в памяти, запрос автоматически выполняется с нужным уровнем изоляции и нет нужды вручную обеспечивать ACID. ID> За тем исключением, что так они уже разобраны и готовы, а результаты запроса еще нужно обработать перед передачей на клиента.
Непонятно, что значит "разобраны и готовы". Клиенту вряд ли передают набор бизнес-объектов; скорее речь идет о построении какого-то сериализованного представления — HTML/XML/PDF/XLS. Ну так вот генерация этого представления из удобным образом сформированного датасета ничуть не дороже, чем по бизнес-объектам, лежащим в памяти.
Если хочется что-то покэшировать, то лучше кэшировать именно отчет. См. напр. серверные генераторы отчетов (Crystal, MS SQL Server Reporting Services и др.).
Не надо изобретать велосипедов. Кэширование в стейтлесс среде — хорошая и правильная штука; нужно только аккуратно выбрать гранулярность кэша.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, TK, Вы писали:
TK>Только, вот сопровождаемость этого дела (если запихнуть всю логику в БД) может упасть точно так же...
Всё зависит от того, как написаны запросы. Современные СУБД предоставляют вполне вменяемые средства декомпозиции запросов, и при должной квалификации разработчика получается все более-менее нормально. А некомпетентный разработчик и в апп-сервере наколбасит неподдерживаемого кода — только в путь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
TK>>Только, вот сопровождаемость этого дела (если запихнуть всю логику в БД) может упасть точно так же... S>Всё зависит от того, как написаны запросы. Современные СУБД предоставляют вполне вменяемые средства декомпозиции запросов, и при должной квалификации разработчика получается все более-менее нормально. А некомпетентный разработчик и в апп-сервере наколбасит неподдерживаемого кода — только в путь.
У меня, например, та же проблема. В моей предметной области на SQL все плохо ложится — операции типа "взять следующий элемент и сравнить с двумя предидущими", например, делаются через Ж. Так что проще писать тупой императивный код, работающий с объектами.
И тут кэш просто рулит. Реальные цифры: "отчет" (если быть точным — подготовка данных для группы отчетов) выполнял 5112 SQL-операторов и занимал 51 секунду времени. Включили кэш, после загрузки данных в него — отчет стал занимать 300 миллисекунд (там что потом его сериализация для отдачи клиенту дольше занимает). Разница по времени — больше чем на два порядка.
Кстати, объектная база (которая работает в качестве "персистентного кэша" на узлах-хабах) выполняет тот же отчет за 5 секунд.
Здравствуйте, Ivan Danilov, Вы писали:
S>>Не надо так делать. Читайте классику. Хранимая процедура обхода дерева пишется на FB на раз-два. Прочитайте для начала статьи на RSDN, посвяшенные хранению иерархических структур. ID>Я в курсе пользы хранимых процедур и активно их использую. Статьи читал, и не только их.
В таком случае, не вполне понятно ваше желание использовать множество запросов к СУБД в рамках одного клиентского запроса. Как правило, такие решения возникают на базе использования навигационного доступа к данным, что есть Великое Зло.
ID>Разворор вроде сейчас идет о кэшировании, а не о поддержке транзакций?
Как это? Разговор начался ровно с проблем синхронизации. Я надеюсь, связь транзакций с синхронизацией очевидна? ID>В контексте кэша: ID> Изоляция (Isolation) — это и было проблемой. Но если сделать по копии данных для каждого потока — и она отпадает.
Гм. Я не знаю специфики вашего приложения, но как правило, 1 инстанс кэша на поток — это очень дорого.
При мелкой гранулярности проблема упирается в наполнение кэша. Грубо говоря, за каждым объектом нужно сбегать в базу данных, причем отдельным запросом. Кэширование результатов запроса целиком в этом смысле значительно дешевле.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ivan Danilov, Вы писали: ID>>А хранить нужные данные в памяти даст не тот же самый результат? S>Нет, не тот же. S>В отличие от данных в памяти, запрос автоматически выполняется с нужным уровнем изоляции и нет нужды вручную обеспечивать ACID.
Про ACID в моем случае здесь: Re[16]: Multithreading в Application server layer
По-моему все нормально.
ID>> За тем исключением, что так они уже разобраны и готовы, а результаты запроса еще нужно обработать перед передачей на клиента. S>Непонятно, что значит "разобраны и готовы". Клиенту вряд ли передают набор бизнес-объектов; скорее речь идет о построении какого-то сериализованного представления — HTML/XML/PDF/XLS. Ну так вот генерация этого представления из удобным образом сформированного датасета ничуть не дороже, чем по бизнес-объектам, лежащим в памяти.
Угу, построение дерева по плоскому датасету для расчета статистических значений тоже ничего не требует. В принципе, можно переложить это дело на клиента — тогда и правда будет ничуть не дороже. Но если начальство захочет отдельный тип прав "Просмотр статистики" — то возможна ситуация, когда сами данные недоступны, а статистика доступна. И передавать на клиента уже нельзя.
Честно говоря, преимущества хранения копии данных в кэше я вижу (если ресурсов хватает). А вот преимущества подхода "оставить все на СУБД" довольно расплывчаты пока что. Потому и спорю
S>Если хочется что-то покэшировать, то лучше кэшировать именно отчет. См. напр. серверные генераторы отчетов (Crystal, MS SQL Server Reporting Services и др.).
Зачем кэшировать отчеты, которые строятся раз в неделю?
Здравствуйте, Ivan Danilov, Вы писали:
ID>Сопоставима. Там везде каналы толстые, т.е. локалка, поделенная на 2 домена.
При чем тут толщина канала? Речь о среднем времени, которое апп-сервер затрачивает на обработку запроса. Если, к примеру, это время измеряется в десятках миллисекунд, то лантентность канала между апп-мервером и СУБД можно особо во внимание не принимать.
ID>Хм. Как Вы написали чуть выше, имеет смысл учитывать только латентность. Она таким образом сокращается ровно вдвое — на запрос к СУБД (если посчитать каналы к серверу и клиенту одинаковыми).
Я написал, что, возможно, имеет смысл учитывать латентность. А возможно и не имеет.
ID>А если еще учесть специфику данных — иерархическое дерево в БД, что влечет за собой большое количество запросов для обхода — выигрыш может быть даже и больше. Ведь так я все дерево сразу собираю на апп-сервере, а так его по частям придется выдирать из СУБД (например, если нужен отчет по ветке со всеми детьми).
Можешь организовать в апп-сервере локальную БД и синхронизировать ее по мере надобности.
ID>Делал. Загрузка всей базы и распихивание по business entities занимает около минуты, может быть чуть-чуть больше.
50М распихивать минуту? Что то какое то экстремально больлшое время у тебя получилось.
Здравствуйте, Cyberax, Вы писали:
C>Смотри что за приложение.
О чем я и пишу..
C>Скорость извлечения данных из локального кэша обычно в тысячи раз быстрее даже простого обращения к БД.
Вопрос в другом — нужна ли эта тысяча.
C>Если у нас есть много мелких запросов — выигрыш может быть весьма значителен.
А может и не быть, даже скорее всего не будет. С другой стороны, выигрыш будет еще больше, если кешировтаь не голые данные, а уже ближе к конечному пользователю, скажем, если это веб-приложение, то кешировать уже отрендеренные веб-страницы.
Вот поэтому я и говорю, что надо сначало понять что кешировать и зачем, а потом уже бросаться это делать.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Я не имел в виду открыть новый Connection, я имел в виду именно задержки при передаче запроса/ответа.
Задержки именно на передачу — минимальны.
ID>А какая разница, куда поднимет ее сама СУБД?
Она поднимает ее практически туда, куда хочешь ты...
ID> О_о Предположим, что время обработки любого запроса СУБД — 0.
Не надо предполагать. Надо взять и померять и только после того как выяснилось чторезультат не устраивает — вкрячивать кешь в то место, где он окажется наиболее эффективным и наименее затратным в реализации. Или просто зарпос переписать или пересмотреть логику работы с отчетами.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, TK, Вы писали:
TK>>Только, вот сопровождаемость этого дела (если запихнуть всю логику в БД) может упасть точно так же... S>Всё зависит от того, как написаны запросы. Современные СУБД предоставляют вполне вменяемые средства декомпозиции запросов, и при должной квалификации разработчика получается все более-менее нормально. А некомпетентный разработчик и в апп-сервере наколбасит неподдерживаемого кода — только в путь.
В FireBird появились человеческие средства, сравнимые по удобству сопровождения с нормально написанным кодом на C#?
В прошлой версии, написанной на Delphi/Interbase, вся логика была как раз завязана на SP. Такое спагетти... Хотя писал не я, предшественника я понимаю — языка СУБД просто не хватает, чтобы нормально все реализовать.
Вот, сейчас переписываю.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ivan Danilov, Вы писали:
ID>>Я в курсе пользы хранимых процедур и активно их использую. Статьи читал, и не только их. S>В таком случае, не вполне понятно ваше желание использовать множество запросов к СУБД в рамках одного клиентского запроса. Как правило, такие решения возникают на базе использования навигационного доступа к данным, что есть Великое Зло.
Я описывал худший случай. Просто очень не хочется на каждую задачу писать хранимку — я и так в них начинаю путаться уже
Естесственно, что полный обход дерева рекурсивно не выполняется — оно же до завтра работать будет
ID>>Разворор вроде сейчас идет о кэшировании, а не о поддержке транзакций? S>Как это? Разговор начался ровно с проблем синхронизации. Я надеюсь, связь транзакций с синхронизацией очевидна?
Угу. Меня мучил вопрос изолированности данных именно в кэше.
S>Гм. Я не знаю специфики вашего приложения, но как правило, 1 инстанс кэша на поток — это очень дорого.
А зачем мне весь кэш копировать? Как правило, пользователь работает только с небольшим набором бизнес-объектов за раз. Да и то, если не требуется редактирование — можно всем выдавать один и тот же объект. Операции же редактирования вообще довольно редкие (сравнительно с чтением) и для них сделать по копии нужных объектов не будет накладно.
S>При мелкой гранулярности проблема упирается в наполнение кэша. Грубо говоря, за каждым объектом нужно сбегать в базу данных, причем отдельным запросом. Кэширование результатов запроса целиком в этом смысле значительно дешевле.
Так вот собственно, кэшированние всей БД — частный случай кэширования результатов запроса целиком
И бегать за объектами в БД придется только если их кто-то обновил, т.е. при сбросе кэша.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
ID>Можно линк на статью/best practices etc.
ID>P.S. Так как вопрос о стоящей задаче все равно кто-то задаст — она в общих описана здесь: Re[4]: Глобальные переменные
IB wrote: > C>Скорость извлечения данных из локального кэша обычно в тысячи раз > быстрее даже простого обращения к БД. > Вопрос в другом — нужна ли эта тысяча.
Эрм... Ускорение в тысячу раз — ненужная вещь? Вы, случаем, не в Intel
работаете?
> C>Если у нас есть много мелких запросов — выигрыш может быть весьма > значителен. > А может и не быть, даже скорее всего не будет.
Будет. Абсолютно точно — сам проверял не раз. Из-за банального
отсутствия round-trip'а до базы данных.
> С другой стороны, выигрыш > будет еще больше, если кешировтаь не голые данные, а уже ближе к > конечному пользователю, скажем, если это веб-приложение, то кешировать > уже отрендеренные веб-страницы.
А тут у нас проблем с когерентностью данных — не всегда просто понять
когда надо менять страницу, в случае изменения данных.
> Вот поэтому я и говорю, что надо сначало понять что кешировать и зачем, > а потом уже бросаться это делать.
Естественно. Серебряных пуль я не предлагаю.
Здравствуйте, Cyberax, Вы писали:
C>Эрм... Ускорение в тысячу раз — ненужная вещь?
Не ужели ты очередной маньяк от производительности? Не разочаровывай меня..
C>Будет. Абсолютно точно — сам проверял не раз.
Ты проверял на своих, довольно узких задачах.
C> Из-за банального отсутствия round-trip'а до базы данных.
Ходить до базы в тысячу раз медленнее чем не ходить? У тебя БД ручным тормозом оборудована?
C>А тут у нас проблем с когерентностью данных — не всегда просто понять когда надо менять страницу, в случае изменения данных.
Тут у нас проблем, как правило, не больше чем с когерентностью БО, а зачастую даже меньше. Впрочем, опять-таки от задачи зависит.
C>Естественно. Серебряных пуль я не предлагаю.
А я что-то такое уж было заподозрил.. )
Hello, Cyberax!
You wrote on Tue, 21 Aug 2007 07:59:14 GMT:
TK>>> Только, вот сопровождаемость этого дела (если запихнуть всю TK>>> логику в БД) может упасть точно так же... S>> Всё зависит от того, как написаны запросы. Современные СУБД S>> предоставляют вполне вменяемые средства декомпозиции запросов, и S>> при должной квалификации разработчика получается все более-менее S>> нормально. А некомпетентный разработчик и в апп-сервере S>> наколбасит неподдерживаемого кода — только в путь. C> У меня, например, та же проблема. В моей предметной области на SQL C> все плохо ложится — операции типа "взять следующий элемент и C> сравнить с двумя предидущими", например, делаются через Ж. Так что C> проще писать тупой императивный код, работающий с объектами.
Здравствуйте, YК, Вы писали:
C>> У меня, например, та же проблема. В моей предметной области на SQL C>> все плохо ложится — операции типа "взять следующий элемент и C>> сравнить с двумя предидущими", например, делаются через Ж. Так что C>> проще писать тупой императивный код, работающий с объектами. YК>Это чистой воды OLAP. Зачем тут SQL вообще?
Это никакой не OLAP, даже близко. У меня, в основном, проблемы связаны с учетом рабочего времени и составлением расписания.
Hello, Cyberax!
You wrote on Tue, 21 Aug 2007 09:36:22 GMT:
C>>> У меня, например, та же проблема. В моей предметной области на C>>> SQL все плохо ложится — операции типа "взять следующий элемент C>>> и сравнить с двумя предидущими", например, делаются через Ж. C>>> Так что проще писать тупой императивный код, работающий с C>>> объектами. YК>> Это чистой воды OLAP. Зачем тут SQL вообще? C> Это никакой не OLAP, даже близко. У меня, в основном, проблемы C> связаны с учетом рабочего времени и составлением расписания.
Судя по описанию, проблемы связаны с использованием неподходящего инструмента. Запросы вроде "взять следующий элемент и сравнить с двумя предыдущими" делаются на MDX элементарно.
Здравствуйте, Cyberax, Вы писали: C>У меня, например, та же проблема. В моей предметной области на SQL все плохо ложится — операции типа "взять следующий элемент и сравнить с двумя предидущими", например, делаются через Ж.
Интересно. В MS SQL это работало достаточно эффективно начиная примерно с 2000 версии. Впрочем, я согласен с тем, что есть класс задач, плохо выражающийся в терминах реляционной алгебры. Пока что принадлежность данной конкретной задачи к этому классу неочевидно.
C>Так что проще писать тупой императивный код, работающий с объектами.
Ну... "Проще" — не всегда значит "лучше". В таких случаях меня настораживают вопросы типа "все хорошо, но как мне...". Ну то есть человек воспользовался неким супер-подходом (например, Lazy load) для красивого и простого решения какой-нибудь задачи. А потом у него вылезает какая-нибудь мелкая проблемка, навроде когерентности кэшей, и я начинаю подозревать вероятность появления совершенно чудовищных костылей, которые полностью нивелируют простоту и красоту этого замечательного подхода.
C>И тут кэш просто рулит. Реальные цифры: "отчет" (если быть точным — подготовка данных для группы отчетов) выполнял 5112 SQL-операторов и занимал 51 секунду времени. Включили кэш, после загрузки данных в него — отчет стал занимать 300 миллисекунд (там что потом его сериализация для отдачи клиенту дольше занимает). Разница по времени — больше чем на два порядка.
Ничего удивительного. Я в свое время занимался оптимизацией отчетов, которые уже были написаны на SQL. Но их писали индусы, имеющие самое отдаленное представление о планах запросов и механике SQL Server, поэтому нудное и кропотливое переписывание SQL выигрывало тоже от порядка до двух. Просто благодаря выбору правильного порядка join/group by. C>Кстати, объектная база (которая работает в качестве "персистентного кэша" на узлах-хабах) выполняет тот же отчет за 5 секунд.
Как правило, банальное переписывание взрослого отчета с клиппера на MS SQL замедляет его в несколько раз. Потому что курсоры в клиппере реализованы существенно более оптимально. А вот переписывание его с нуля на том же MS SQL, аккуратная раздача индексов, и прочие методы традиционной медицины творят просто чудеса.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ivan Danilov, Вы писали: ID>В FireBird появились человеческие средства, сравнимые по удобству сопровождения с нормально написанным кодом на C#?
На моей памяти, хватало и средств Interbase 6.0. ID>В прошлой версии, написанной на Delphi/Interbase, вся логика была как раз завязана на SP. Такое спагетти... Хотя писал не я, предшественника я понимаю — языка СУБД просто не хватает, чтобы нормально все реализовать.
А чего именно не хватает? ID>Вот, сейчас переписываю.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
IB wrote: > C>Эрм... Ускорение в тысячу раз — ненужная вещь? > Не ужели ты очередной маньяк от производительности? Не разочаровывай меня..
А, угадаю еще раз — в Microsoft?
> C>Будет. Абсолютно точно — сам проверял не раз. > Ты проверял на своих, довольно узких задачах.
Не таких уж узких. Почти всегда performance от кэша выигрывает.
> C> Из-за банального отсутствия round-trip'а до базы данных. > Ходить до базы в тысячу раз медленнее чем не ходить? У тебя БД ручным > тормозом оборудована?
Нет. Типичный roundtrip по сети до базы — около миллисекунды, причем это
еще при хороших условиях.
Сколько за это время можно достать и склонировать объектов из hash-карты
в локальной памяти ты можешь посчитать сам.
> C>А тут у нас проблем с когерентностью данных — не всегда просто понять > когда надо менять страницу, в случае изменения данных. > Тут у нас проблем, как правило, не больше чем с когерентностью БО, а > зачастую даже меньше. Впрочем, опять-таки от задачи зависит.
А еще бывают GUI-клиенты
YК wrote: > YК>> Это чистой воды OLAP. Зачем тут SQL вообще? > C> Это никакой не OLAP, даже близко. У меня, в основном, проблемы > C> связаны с учетом рабочего времени и составлением расписания. > Судя по описанию, проблемы связаны с использованием неподходящего > инструмента. Запросы вроде "взять следующий элемент и сравнить с двумя > предыдущими" делаются на MDX элементарно.
У меня нет хороших и красивых упорядоченых последовательностей, по
которым можно строить кубики. "Предидущий" элемент зависит от каждого
конкретного параметра отчета.
Представь себе расписание — нужно его автоматически составить. Могут
быть констрейнты типа "человек не должен работать более двух дней подряд
в одном подразделении" или "работать только в один из выходных через две
недели". Попробуй на досуге записать второе условие в SQL. Причем таких
параметров штук 20 (и постоянно добавляются).
Sinclair wrote: > Интересно. В MS SQL это работало достаточно эффективно начиная примерно > с 2000 версии. Впрочем, я согласен с тем, что есть класс задач, плохо > выражающийся в терминах реляционной алгебры. Пока что принадлежность > данной конкретной задачи к этому классу неочевидно.
Какие именно? Естественно, не имеется в виду ссылка на два предидущих
ряда запроса — там логические сущности, которые тоже надо вычислять.
Мы пробовали это делать — оказывается, что MSSQL и Oracle часто тупо
сливают императивному коду из-за того, что не могут использовать
мемоизацию и другие оптимизации. А борьба с помощью хинтов —
изнурительное занятие.
> C>Так что проще писать тупой императивный код, работающий с объектами. > Ну... "Проще" — не всегда значит "лучше". В таких случаях меня > настораживают вопросы типа "все хорошо, но как мне...". Ну то есть > человек воспользовался неким супер-подходом (например, Lazy load) для > красивого и простого решения какой-нибудь задачи. А потом у него > вылезает какая-нибудь мелкая проблемка, навроде когерентности кэшей, и я > начинаю подозревать вероятность появления совершенно чудовищных > костылей, которые полностью нивелируют простоту и красоту этого > замечательного подхода.
Поэтому мы используем транзакционный, кластерный кэш и двухфазный коммит
(который не нужен для readonly-операций) и движемся к распределенной
grid-подобной архитектуре.
> Ничего удивительного. Я в свое время занимался оптимизацией отчетов, > которые уже были написаны на SQL. Но их писали индусы, имеющие самое > отдаленное представление о планах запросов и механике SQL Server, > поэтому нудное и кропотливое переписывание SQL выигрывало тоже от > порядка до двух. Просто благодаря выбору правильного порядка join/group by.
Оно в первой версии около часа работало — минутой оно стало после
тюнинига. Дальше просто уже было непонятно как можно "малой кровью" без
жутких хаков оптимизировать.
> А вот переписывание его с нуля > на том же MS SQL, аккуратная раздача индексов, и прочие методы > традиционной медицины творят просто чудеса.
Традиционная медецина в виде реляционной алгебры и [де]нормализации
схемы — это все понятно. Просто что делать, если задача в терминах
реляционной алгебры вообще не выражается?
Здравствуйте, 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. Использование встроенных в СУБД механизмов подписки на оповещения об изменениях. Самый простой и прозрачный способ, но подходит не для всех СУБД.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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-запросов от всех подключеных клиентов. В результате, загрузка сервера с сотней клиентов, имеющих обновления в пределах пары секунд — почти минимальна.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>А, угадаю еще раз — в Microsoft?
То есть, все-таки маньяк?
C>Не таких уж узких. Почти всегда performance от кэша выигрывает.
Вопрос, как я уже говорил, в другом — нужны ли эти копейки...
Здравствуйте, IB, Вы писали:
C>>А, угадаю еще раз — в Microsoft? IB>То есть, все-таки маньяк?
Я угадал?
C>>Не таких уж узких. Почти всегда performance от кэша выигрывает. IB>Вопрос, как я уже говорил, в другом — нужны ли эти копейки...
Ускорение запроса в тысячу раз и приложения в разы. Подумаешь...
Здравствуйте, 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.
Ок, понял. Просто по твоим изначальным примерам вся эта сложная кухня была неочевидна.
YК wrote: > C> Сейчас в реакторе всего 203 правила. Из них к расписанию относятся > C> 132. > Ок, понял. Просто по твоим изначальным примерам вся эта сложная кухня > была неочевидна. > А Drools не пробовали использовать?
Сначала его и использовали, потом купили коммерческий движок.
Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
Буду гуглить. 
Мы уже победили, просто это еще не так заметно...
Хотя писал не я, предшественника я понимаю — языка СУБД просто не хватает, чтобы нормально все реализовать.
Потому что курсоры в клиппере реализованы существенно более оптимально. А вот переписывание его с нуля на том же MS SQL, аккуратная раздача индексов, и прочие методы традиционной медицины творят просто чудеса.
