Здравствуйте, AlexGK, Вы писали:
AGK>Cпасибо за ответ. В принципе я уже понял что к чему... Действительно, определенные выгоды есть и весьма ощутимые. AGK>Другой вопрос во сколько обходится такой подход? Кто-нибудь пробовал замерять? КИнтье линк, если есть, сам я попробую проверить на разных выборках/вставках/апдейтах, о результатах напишу. По идее, конечно, сильной потери производительности не должно быть, если грамотно организовать логику и миимимзировать лишние запросы к базе... но увидим.
Насчет потери производительности по сравнению с ХП ничего сказать не смогу но субъективно — если они и есть то не очень большие.
А вот насчет минимизации запросов к базе и поддержки актуального кеша на сервере приложений это очень важно!!!!
В моей практике было такое что где то в 2-3 раза повышалось быстрота работы вычитки когда не нужно было лезть за
некоторыми данными в табличку.... Если более подробнее, то в БД бух учета для каждой записи в практически каждой
таблице заполнялось еще 2 доп. поля
id пользователя который вствил запись и id того кто менял его. Т.к. работа с БД была активной то на таблицу с учетными записями пользователей была достаточно сильная нагрузка по вычитке. И по этому я решил ее закешировать... Быстрота запросов увеличилась достаточно ощутимо.
Так же было еще с парой таблилц которые внес в кэш. Кэш автоматически обновлялся по нотификации с сервера когда данные в кэшируемой таблице
менялись извне. Вобщем гемороя пока все построил было не так уж и много (но был ) зато потом стало ощутимо легче с быстротой.
Хм.. что то я разговорился сегодя... вобщем такие дела.
J>Насчет потери производительности по сравнению с ХП ничего сказать не смогу но субъективно — если они и есть то не очень большие. J>А вот насчет минимизации запросов к базе и поддержки актуального кеша на сервере приложений это очень важно!!!! J>В моей практике было такое что где то в 2-3 раза повышалось быстрота работы вычитки когда не нужно было лезть за J>некоторыми данными в табличку.... Если более подробнее, то в БД бух учета для каждой записи в практически каждой J>таблице заполнялось еще 2 доп. поля J>id пользователя который вствил запись и id того кто менял его. Т.к. работа с БД была активной то на таблицу с учетными записями пользователей была достаточно сильная нагрузка по вычитке. И по этому я решил ее закешировать... Быстрота запросов увеличилась достаточно ощутимо. J>Так же было еще с парой таблилц которые внес в кэш. Кэш автоматически обновлялся по нотификации с сервера когда данные в кэшируемой таблице J>менялись извне. Вобщем гемороя пока все построил было не так уж и много (но был ) зато потом стало ощутимо легче с быстротой. J>Хм.. что то я разговорился сегодя... вобщем такие дела.
Скажи, а какая разница — лежат данные в кэше сервера приложения или в кэше БД? Может быть стоило просто подкрутить что-то в настройках кэша БД? В том же оракле есть возможность закреплять некоторые таблицы в кэше
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Может я чего-то не понимаю?!!
От:
Аноним
Дата:
08.09.06 15:43
Оценка:
J>В моей практике было такое что где то в 2-3 раза повышалось быстрота работы вычитки когда не нужно было лезть за J>некоторыми данными в табличку.... Если более подробнее, то в БД бух учета для каждой записи в практически каждой J>таблице заполнялось еще 2 доп. поля J>id пользователя который вствил запись и id того кто менял его. Т.к. работа с БД была активной то на таблицу с учетными записями пользователей была достаточно сильная нагрузка по вычитке. И по этому я решил ее закешировать... Быстрота запросов увеличилась достаточно ощутимо. J>Так же было еще с парой таблилц которые внес в кэш. Кэш автоматически обновлялся по нотификации с сервера когда данные в кэшируемой таблице J>менялись извне. Вобщем гемороя пока все построил было не так уж и много (но был ) зато потом стало ощутимо легче с быстротой.
Что за кэш такой?
Пока он не обработал уведомление от сервера он возвращал неправильные данные?
Сохраняется ли понятие транзакции при наличии такого кэша?
_>Скажи, а какая разница — лежат данные в кэше сервера приложения или в кэше БД? Может быть стоило просто подкрутить что-то в настройках кэша БД? В том же оракле есть возможность закреплять некоторые таблицы в кэше
Да вобщем то на первый взгляд разницы никакой нивижу. Можно и так.. Просто выбрали эту модель кэша.
В MSSqlServer есть так же возможность закрепить таблицу — dbcc pintable.
Хотя вобщем то вспоминаю что админ сиквела против был такого подхода. Говорил что в случае если буфер кэша будет меньше чем размер таблицы/таблиц то серваку может быть ооочень плохо вплоть до рестарта.
Так что пришлось сделать кэш на АПП сервере.
А>Пока он не обработал уведомление от сервера он возвращал неправильные данные?
Хм.. данные редко меняются и на них так же не очень часто смотрят, восновном для разбора полетов
Но эти данные должны быть! Хотел вначале выкрутится с ленивой загрузкой но потом понял что
проблем будет еще больше. А>Сохраняется ли понятие транзакции при наличии такого кэша?
Не совсем понял вопрос- понятие транзакции по отношению к чему??
В кэше лежать данные которые не удаляются только модифицируются (неключевые поля)
через админскую часть программы и только несколькими людьми,
а не обычными пользователями.
_>>Скажи, а какая разница — лежат данные в кэше сервера приложения или в кэше БД? Может быть стоило просто подкрутить что-то в настройках кэша БД? В том же оракле есть возможность закреплять некоторые таблицы в кэше
J>Хотя вобщем то вспоминаю что админ сиквела против был такого подхода. Говорил что в случае если буфер кэша будет меньше чем размер таблицы/таблиц то серваку может быть ооочень плохо вплоть до рестарта. J>Так что пришлось сделать кэш на АПП сервере.
Я снова ничего не понимаю. Если таблица такая большая, что может прибить кэш на сервере БД, то те же самые проблемы должны быть, если ее закреплять в кэше на апп-сервере
_>Я снова ничего не понимаю. Если таблица такая большая, что может прибить кэш на сервере БД, то те же самые проблемы должны быть, если ее закреплять в кэше на апп-сервере
Ну что ж тут непонятного.. на АПП сервере памяти достаточно — а на сервер БД нагрузка ложится достаточно сильная т.к. там работает не только несколько OLTP систем но и к сожалению еще отчеты строятся, и кэш(оперативку) засорять таблицами имхо не очень правильно.
Вот потому и выбрали такой путь.
Никаких тайных замыслов или каких то секретных потусторонних знаний не использовалось
Да и в случае чего рестарт одного АПП сервера будет заметен ну отслилы 50-100 пользователям и то если они в этот момент не медитировали
глядя в монитор а жали кнопки в приложении а если коннект был потерян то приложение его автоматом восстановит.
Здравствуйте, Jericho113, Вы писали:
_>>Я снова ничего не понимаю. Если таблица такая большая, что может прибить кэш на сервере БД, то те же самые проблемы должны быть, если ее закреплять в кэше на апп-сервере
J>Ну что ж тут непонятного.. на АПП сервере памяти достаточно — а на сервер БД нагрузка ложится достаточно сильная т.к. там работает не только несколько OLTP систем но и к сожалению еще отчеты строятся, и кэш(оперативку) засорять таблицами имхо не очень правильно.
J>Вот потому и выбрали такой путь. J>Никаких тайных замыслов или каких то секретных потусторонних знаний не использовалось
J>Да и в случае чего рестарт одного АПП сервера будет заметен ну отслилы 50-100 пользователям и то если они в этот момент не медитировали J>глядя в монитор а жали кнопки в приложении а если коннект был потерян то приложение его автоматом восстановит.
Ну понятно все с вами )) То бишь БД не только апп-сервер обслуживает.
) зато потом стало ощутимо легче с быстротой.
