Здравствуйте,

Есть 2-tier бизнес-приложение:
[ UI + BLL + DAL ] <---> [ Data Storage ]

Что вы думаете о реализации кеша на клиентах? Нужно ли? Какие проблемы при этом возникают и как их можно решить?

Я вот у себя решил сделать кеш клиентов, поставщиков и производителей. Разместить его в DAL. Сделал.
Правда что-то не догадался запрофилировать скорость работы до использования кеша и после, поэтому насколько повысилась производительность на клиентах сказать не могу.

Ну плюсы какие: В памяти только один объект в кеше и все ссылки на него, а не куча одинаковых объектов (например если заказ на 1000 позиций, то в позициях заказа мы не будем иметь 1000 разных объектов производителя которые по сути представляют одного и того же производителя). Ну и из БД не надо тянуть лишний раз объекты которые в кеше. Это особенно полезно в ситуациях типа опять же ситуации с заказом. Читаем заказ из БД и не надо нам читать из БД и создавать на каждую позицию объект производителя — дергаем его из кеша: ManufacturerRepository.GetByID(manufacturerID);

Ну да ладно, это я отвлекся.

Возникли проблемы с синхронизацией кеша на разных клиентах (компьютерах).
Казалось бы такие сущности как клиент, поставщик, производитель редко изменяются.
Но дело в том что у меня например в классе клиента есть поля Balance и LastOrderN, которые могут изменяться несколько раз в день.
Рассинхронизация значений этих полей может привести к очень неприятным последствиям. Т.е. например на одном клиенте у customer'а номер последнего заказа увеличивается на единицу, а другой клиент то об этом сразу не узнает..

Начинаются думы и приседания с синхронизацией кеша.
Потом в голову приходит мысль: Может кеш делать только для объектов которые изменяются реально очень редко (раз в несколько дней и реже). Либо например из класса Customer убрать поля Balance и LastOrderN и сделать работу с ними через методы типа CustomerRepository.GetCustomerBalance(Customer customer) и т.д.?

Что скажете?

Буду рад если кто-то внесет ясность в этот вопрос, ну и вообще вашим мнениям =)

MasterZiv
>Какие проблемы при этом возникают и как их можно решить?

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

> Правда что-то не догадался запрофилировать скорость работы до
> использования кеша и после, поэтому насколько повысилась
> производительность на клиентах сказать не могу.

MasterZiv
Так тут и гадать нечего, она повысится однозначно.
Вот МакКоннелл пишет что это очень большая ошибка так думать. И что пока реально не запрофилировали нельзя говорить об эффекте оптимизации. Я считаю что он прав. Но допустим, конечно, что производительность повысится. Вопрос в том - насколько она повысится. Если высокоуровневая функция (считывание заказа например) выполнялась 100 мс, а стала 15 мс, то стоит ли из-за этого заморачиваться с кешем?

> Но дело в том что у меня например в классе клиента есть поля Balance и
> LastOrderN, которые могут изменяться несколько раз в день.
> Рассинхронизация значений этих полей может привести к очень неприятным
> последствиям. Т.е. например на одном клиенте у customer'а номер
> последнего заказа увеличивается на единицу, а другой клиент то об этом
> сразу не узнает..

MasterZivЗначит такие данные просто нельзя кэшировать. вот и все. Кэшируй
только вообще неизменяемые справочники.
Я кеширую клиентов, поставщиков, производителей товара, потому что иногда идут сотни позиций с их идентификаторами. Например мы открываем все заказы за сегодня и ходим сделать один общий заказ нашему дилеру. При чтении заказанных позиций, в каждой позиции идут например CustomerID и ManufacturerID, соответственно на каждую позицию из БД вытягивать все данные клиентов и производителей чтобы создать объекты клиента и производителя - долго. А если есть кеш, то просто делаем типа Customer customer = CustomerRepository.GetByID(customerID) - все моментально. Дополнительно получаем единство объекта, т.е. у нас в кеше один объект клиента Вася Пупкин, и 1000 ссылок на него, а не 1000 разных объектов фактически обозначающих одного и того же Васю Пупкина.

> Либо например из класса Customer убрать поля Balance и LastOrderN и
> сделать работу с ними через методы типа
> CustomerRepository.GetCustomerBalance(Customer customer) и т.д.?

MasterZivНу это - другой вопрос, вопрос проектирования БД, но - тоже вариант.
Собственно, то, что контрагент и его балланс находятся в одной таблице,
иначе как ошибкой проектирования я бы не назвал, но это все - отдельный
разговор.
А не прочитаете очень краткую лекцию где хранить например баланс клиента и номер его последнего заказа? Мне будет полезно.

Dmitriy IvanovВ целом, идея правильная. Повышение быстродействия через кэширование -
основное преимущество 2-х уровневых приложений перед 3-х уровневыми (где
приходиться довольствоваться возможностями тонкого клиента-браузера).

Теоретические аспекты хорошо прописаны в подходе, называемом
Object-relational mapping. Даже если Вы не программируете на Java,
рекомендую почитать документацию по Hibernate.
Ну в 3х уровневых приложениях никто так же не мешает сделать кеш на клиентах, хотя думаю что обычно делают на application server'е, на котором размещают DAL с кешем и возможно BLL.
Хотя вы наверное говорите о веб-приложениях. Кстати на ASP .NET на серверной стороне можно сделать постоянный кеш а не только на сессию?

softwarer
При кэшировании на клиенте однозначно нужно тянуть с сервера не только id объекта (для поиска в кэше) но и id/таймстамп его последнего изменения и соответственно прочищать кэш.
Можно пожалуйста подробнее?

softwarer MozgCРассинхронизация значений этих полей может привести к очень неприятным последствиям. Т.е. например на одном клиенте у customer'а номер последнего заказа увеличивается на единицу, а другой клиент то об этом сразу не узнает..
Вот этот вот абзац наводит на мысль, что Вы перетянули на клиента то, что нужно делать на сервере...
Может быть. Как бы вы сделали? Напоминаю, что на сервере у меня только СУБД и все.

softwarer MozgCПотом в голову приходит мысль: Может кеш делать только для объектов которые изменяются реально очень редко (раз в несколько дней и реже).
В чем принципиальная разница? Полагаете, глюка раз в несколько дней принципиально лучше, нежели глюка несколько раз в час?
Наверное вы правы... Научите как правильно :)

softwarerДля реализации любого кэша мы должны либо быть уверены, что все обращения к объекту идут через владельца кэша, либо контролировать соответствие объекта в кэше основному. Для контроля следует ввести некий идентификатор версии объекта - например, timestamp его последнего изменения. Каждый раз, когда мы запрашиваем с сервера выборку, следует тянуть не только id объектов, но и их версию, сравнивать с локальной и использовать объект из кэша только при совпадении (при несовпадении - дозапрашивать).
Как это поможет в следующей ситуации: открываем форму создания заказов поставщикам. При этом загружаются все существующие поставщики (и помещаются в combobox). Поставщики загружаются из кеша, с описанной вами проверкой по timestamp. все ок. Тут на другом клиенте кто-то делает заказ поставщику X и номер его последнего заказа увеличивается на 1. На первоначальном клиенте мы тоже создаем заказ поставщику X и так как номер последнего заказа поставщика X берется из объектка Supplier из кеша (который у нас точно обновленный на момент загрузки формы, но уже устаревший на данный момент), то происходит попытка создать заказ под номером, под которым уже есть заказ (сделанный недавно на другом клиенте). Как быть? Чем в этом случае помогает дополнительная проверка по timestamp'у?

softwarerКаждый раз, когда мы отправляем на сервер изменение объекта, следует отправлять также локальную версию и при несовпадении с серверной - запускать процедуру разрешения конфликта обновлений.
Не понял что вы имеете в виду..

softwarer MozgCРассинхронизация значений этих полей может привести к очень неприятным последствиям. Т.е. например на одном клиенте у customer'а номер последнего заказа увеличивается на единицу, а другой клиент то об этом сразу не узнает..
Вот этот вот абзац наводит на мысль, что Вы перетянули на клиента то, что нужно делать на сервере...
Можно подробнее, пожалуйста?

В общем, очень долго поразмышляв, я решил отказаться от кеша на клиенте.
Точнее использовать только "местный кеш", в пределах одной бизнес-транзакции.

Но сначала решил сделать "замеры" и вот результаты:
Задача: загрузка всех позиций из заказа клиента. Позиций 80, среди 80 позиций 7 разных производителей. ХП к сожалению не использовались в виду лени их создания. ПО и СУБД находились на одном компьютере (1-tier).

Схема 1:
Кеширование "на процесс", т.е. единый кеш на весь клиент и на все время работы клиента. Кеш предварительно заполнен всеми производителями.
Результат: 19 мс

Схема 2:
Местное кеширование, т.е. как я сейчас собираюсь сделать — кеширование в пределах бизнес-транзакции.
Результат: 23 мс

Схема 3:
Местное кеширование. Местный кеш вначале бизнес-транзакции полностью заполняется производителями.
Результат: 12 мс

Схема 4:
Без какого-либо кеширования на клиенте, вся информация о производителях подключаются INNER JOIN'ом и для каждой позиции создается свой объект производителя:
Результат: 11 мс

Схема 5:
Без какого-либо кеширования на клиенте, за каждым производителем лезем отдельным запросом в БД.
Результат: 177 мс

На результаты конечно нельзя сильно полагаться из-за того что не использовались ХП и думаю мог быть достаточный overhead из-за парсинга и построения планов зарпосов СУБД.
Смущает результат первой схемы. Он почему-то больше чем результат схемы 3, хотя казалось бы результаты должны быть одинаковы. Разница только что в схеме 1 использовался мой самодельный Cache<T> который прямо делегировал работу в Dictionary, а в схеме 3 Dictionary использовался напрямую.

Результаты подтвердили мои мысли о том, что использование единого кеша на процесс особых преимуществ по скорости не дает, и что схемы 2-3 дают хорошие результаты при намного меньшем геморое.
Но тут все-таки вопрос к более опытным: какие могут быть подводные камни при использовании кеша на бизнес-транзакцию вместо кеша на процесс? Само собой сразу приходит на ум синхронизация изменений, типа в одном окошечке изменили, в другом окошке изменения отобразились. Но реально ли это нужно и реально ли из-за этого могут быть какие-нибудь проблемы?

Теперь буду думать как красиво сделать использование такого кеша на бизнес-транзакцию. Если делать отдельный generic класс типа LocalCache, то ему видимо надо будет передавать объект доступа к БД из DAL, реализующий какой-нибудь универсальный IAccessor с методом типа LoadObject(PrimaryKey key), либо сразу делегат на метод загрузки объекта по PK. Либо делать отдельные классы кешей на каждую сущность, типа CustomerLocalCache =) но это я почти уверен неправильно. Как лучше? Буду рад примерам.

PS. Тут мне говорили что я перетаскиваю на клиент то, что должно делаться на сервере. Имеете в виду, что правильнее чтобы например ХП сама назначала номер заказу поставщика?

Petro123 MozgC
PS. Тут мне говорили что я перетаскиваю на клиент то, что должно делаться на сервере. Имеете в виду, что правильнее чтобы например ХП сама назначала номер заказу поставщика?
правильнее не делать велосипедов, а использовать библиотеки доступа к БД
А в чем я делаю велосипед? Можно пожалуйста конкретнее, без абстракций и метафор?
И что вы имеете в виду под библиотеками доступа к БД?

Petro123
- какой язык?
- какие библиотеки используете по данному ЯП?
Хм.. Вам действительно важно это? C#, ADO .NET, MySQL Connector for .NET.

Petro123
- чем не устраивает кэш в СУБД (штатный)
По скорости вытаскивания плоских данных устраивает. Хочется обеспечить единство объектов, а не городить одинаковые объекты к тому же еще и понижая скорость за счет постоянного инстанциирования.

Petro123
- вы прикладник или пишете системную библиотеку?
прикладник.

Petro123
- что за изобретение - "местный кеш", в пределах одной бизнес-транзакции?
Это не изобретение. Identity Map который заполняется и используется во время одной бизнес-транзакции.