Что кэшировать, когда 99,9% ваших данных часто изменяются? - PullRequest
8 голосов
/ 23 октября 2008

Хорошо, я знаю, что спрашивал об этом раньше, и ответ был в основном кеш-данными, которые меняются не часто.

Ну что делать, когда меняется хотя бы 99,9% данных?

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

Так как же все-таки включить какое-то кэширование, но сохранить и убедиться, что просматриваемые данные обновляются при применении изменений?

Ответы [ 5 ]

7 голосов
/ 23 октября 2008

Я полагаю, что на самом деле не 99,9% всех данных изменяются, но происходят изменения в 99,9% всех местоположений данных.

Например, если вы используете доску объявлений, это означает, что будет постоянный поток новых сообщений, но старые сообщения останутся прежними, и даже старые темы будут оставаться неизменными в течение долгого времени.

В этом случае вам потребуется способ сделать недействительными старые кэшированные данные, чтобы вы могли создать кеш, как только просматривается поток (в примере). Если есть изменение в ОДНОЙ из этих тем (то есть, когда кто-то добавляет новое сообщение), этот кэшированный элемент удаляется / помечается как устаревший, поэтому при следующем просмотре он будет перестроен. Другие элементы, которые все еще не изменились, будут использовать кеш.

2 голосов
/ 23 октября 2008

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

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

1 голос
/ 23 октября 2008

Действительно важный вопрос: как часто меняются эти 99,9% информации, каждый ли это доступ, каждую секунду, минуту, час? Все, что находится выше уровня доступа, зависит от количества запросов на единицу времени и выбранной вами схемы кэширования.

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

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

1 голос
/ 23 октября 2008

Это зависит.

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

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

0 голосов
/ 23 октября 2008

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

Время от времени вы можете очищать кеш, чтобы убедиться, что нет ничего несинхронизированного (например, если база данных была обновлена ​​каким-либо другим приложением).

Обратите внимание, что это не будет хорошо работать для сценариев масштаба предприятия.

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