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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Структура работы

Также полезно знать о шаблоне Единица работы .

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

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

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

Answer 2

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

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

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

Answer 3

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