ASP.NET C #: результаты кэширования базы данных, когда и как сделать недействительными (для каждой записи) - PullRequest
0 голосов
/ 31 июля 2009

мое приложение отображает контактную информацию (из приблизительно 2000 записей контактов с различной подробной информацией (имена, номера телефонов и т. Д.), Которые составляют основу контактной сетки), которая обычно редко изменяется.

Тем не менее, большое количество пользователей имеет право редактировать эту информацию, и если она редактируется, требуется, чтобы изменения были видны всем сразу.

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

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

Как я могу использовать этот дизайн и код? Ваша помощь очень ценится.

Ответы [ 5 ]

3 голосов
/ 06 декабря 2009

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

Я бы так не поступил. Если имеется несколько одновременных обновлений, вы не будете уверены, что замены кэша выполняются в том же порядке, что и обновления базы данных (если только обновление кэша не является частью той же транзакции, что и обновление базы данных, что кажется чрезмерным). *

Вместо этого я бы:

  • Хранить элементы в кэше с ключом кэша, полученным из первичного ключа.

  • При каждой операции обновления просто удаляйте запись в кэше после обновления базы данных. Таким образом, кэш будет обновляться с обновленными данными при следующем обращении к нему.

0 голосов
/ 04 августа 2009

Для этого мы использовали блок кэширования Enterprise Library. Однако мы используем его без резервного хранилища, как описано Abhijeet Patel.

Кэш структурирован как пара ключ / значение.

Когда пользователь пытается получить запись, мы проверяем, находится ли она в кэше, если да, возвращаются из кэша, если нет, получают из базы данных и обновляют кеш.

Когда пользователь изменяет строку, обновляйте кэш одновременно с обновлением базы данных.

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

0 голосов
/ 31 июля 2009

Похоже, вам нужно сохранять отметку времени каждого обновления. С каждой записью связана временная метка.

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

Каждый раз, когда изменение сохраняется, метка времени записи обновляется. Затем, когда другие пользователи должны загрузить изменения, вы можете запросить что-либо обновленное после последней известной максимальной отметки времени клиента. Другие пользователи получат только изменения.

0 голосов
/ 31 июля 2009

Блок кэширования MS Enterprise Library обладает хорошими функциями, позволяющими настраивать зависимости кэша и аннулирование на основе аннулирования на основе времени и на основе уведомлений (включая те, которые получены из хранилища данных). Проверьте это

0 голосов
/ 31 июля 2009

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

Если вы действительно беспокоитесь о целостности данных, вы можете вести журнал транзакций операций cache & db, чтобы у вас был способ узнать, что происходило в момент сбоя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...