Стратегия кэширования для запрашиваемых данных

В настоящее время я занимаюсь созданием репозитория для проекта, который будет интенсивно работать с БД (были проведены тесты производительности и требуется кэширование, поэтому я спрашиваю)

Теперь я установил, что каждый объект индивидуально кэшируется, если я хочу сделать запрос для них, объекты передаю запрос в базу данных и возвращу требуемый идентификатор. (Для некоторых простых запросов я кэшировал и управлял идентификаторами)

Затем я попадаю в кеш с этими идентификаторами и вытаскиваю их, любые отсутствующие объекты группируются в оператор "where in" и запускаются в базу данных; в этот момент я повторно заполняю кеш с отсутствующими идентификаторами.

Сами запросы, скорее всего, связаны с поиском/упорядочением данных.

Это подходящая стратегия? Или, может быть, есть лучшие методы?

Ответ 1

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

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

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

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

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

Единица измерения работы

Это также помогает узнать о Элемент работы.

Когда вы извлекаете данные из и из базы данных, важно сохранить отслеживать то, что вы изменили; иначе данные не будут записаны обратно в базу данных. Точно так же вы необходимо вставить новые объекты, которые вы создаете и удалите все объекты, которые вы удаляете.

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

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

Ответ 2

Если вы используете SQLServer, вы можете использовать SqlCacheDependency, где ваш кеш будет автоматически заселен при изменении таблицы данных в базе данных, Здесь ссылка для SqlCacheDependency

Эта ссылка содержит аналогичное решение для зависимостей кэша. (Это для файла, а не для БД. Вам нужно будет внести некоторые изменения в соответствии с приведенной выше ссылкой msdn, чтобы иметь зависимость кеша от БД)

Надеюсь, что это поможет:)

Ответ 3

Я не советую настраивать стратегию кэширования. Кэширование сложно. В соответствии с выбранной вами платформой вы можете выбрать стороннюю библиотеку/инструмент кэширования.