Нужно ли DbContext MemoryCache или Redis в Net Core?

Question

У нас есть несколько таблиц поиска в базе данных SQL Server. Таблицы используются в выпадающих меню приложений.

AddressType:

• Home
• Business

ProductType:

• Книги
• Еда
• Электроника

Вместо постоянного чтения таблиц поиска базы данных, команда хочетприменить MemoryCache или Redis Cache (для уменьшения нагрузки на базу данных и увеличения производительности в памяти). Однако мы узнали, что Entity Framework Core DbContext уже имеет кеширование.

Итак, будет ли в этом случае какое-либо значение в кэшированных таблицах, если после определенного количества операций чтения DbContext уже это сделает? Поможет ли добавление дополнительного кода кэширования для MemoryCache/Redis сверх DbContext? Или это будет ненужный слой?

Answer 1

Как и в Microsoft - это EF Core 2.0, EF Core поддерживает только кэш первого уровня, то есть, когда сущность материализуется в результате выполнения запроса, она сохраняется в кеше в памяти, связанном с Entity Framework. Контекст (он же System.Data.Entity.DbContext class)

Механизм кэширования первого уровня EF Core обеспечивает некоторое повышение производительности, однако рассмотрим сценарий, в котором запись объекта изменяется на уровне базы данных, и мы все еще работаем надлокально кэшированные копии сущностей из контекста Entity Framework. так что это приводит к ситуации, когда мы получим неправильный набор результатов.

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

Итак, мы видим, что механизм кэширования первого уровня EOB Core из коробки (OOB) работаетдалеко не идеально. Это приводит к неуклюжему коду, который подвержен ошибкам, и существует довольно высокая вероятность того, что кодовая база станет извилистой и не поддерживаемой в долгосрочной перспективе. Ниже перечислены некоторые другие недостатки механизма кэширования первого уровня EF Core OOB:

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

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