Como dimensionar aplicativos EF Core para desempenho extremo?
Webinar gravado
Por Ron Hussain e Zack Khan
O EF Core está sendo cada vez mais usado em aplicativos de servidor .NET de alta transação (ASP.NET, Web Services, Microservices e outros aplicativos de servidor). Além disso, esses aplicativos enfrentam gargalos de escalabilidade de bancos de dados que podem ser eliminados usando o cache distribuído dentro do EF Core.
- Introdução aos novos recursos do EF Core (modelo, consulta, salvamento de dados)
- Como o cache distribuído resolve gargalos de banco de dados EF Core
- Várias maneiras de usar o cache distribuído em aplicativos EF Core
- Detalhes sobre como usar os métodos de extensão do EF Core para armazenamento em cache
- Manipulando o cache de coleções e relacionamentos de dados
O Entity Framework Core ou EF Core é o novo mecanismo de mapeamento relacional de objetos leve e multiplataforma da Microsoft para .NET que elimina a necessidade da maior parte do código de acesso a dados que os desenvolvedores escrevem. Igual a .NET Core, o EF Core também é multiplataforma, o que significa que você pode usá-lo no Windows, Linux, Mac e está se tornando muito popular na comunidade de desenvolvedores.
Como dimensionar seu aplicativo para obter desempenho extremo, bem como crescimento linear na capacidade de tratamento de solicitações? Assim, você pode dimensionar seu aplicativo, aplicativo Entity Framework Core usando NCache métodos de extensão. Então, nós alinhamos alguns que você pode utilizar. Diferentes cenários que pintarei e, com base neles, apresentarei NCache métodos de extensão, bem como recursos de cache de objeto que você pode usar em um aplicativo típico do Entity Framework Core em seu ambiente.
O que é Entity Framework / EF Core?
Primeiro, falaria sobre o Entity Framework e o Entity Framework Core em geral. Tenho certeza de que todo mundo conhece o EF e o EF Core, mas apenas para completar, para criar alguns detalhes introdutórios.
Entity Framework é um ORM que você pode usar para .NET e com o EF Core você também pode usá-lo para .NET, bem como para .NET Core. O Entity Framework simplifica sua programação de banco de dados. Você pode trabalhar no modelo de objeto conceitual. Portanto, você não precisa trabalhar diretamente com o modelo de dados e simplifica a programação geral de acesso a dados. Você não precisa escrever código persistente por conta própria. Ele pode gerar muita interação entre sua camada de objeto dentro de seu aplicativo para o modelo de dados que você possui e usando o acesso ao banco de dados gerado pelo Entity Framework Core.
É muito popular para o seu .NET e .NET Core formulários. Você pode usá-lo em qualquer tipo de aplicativo, ou seja, pode ser um aplicativo da Web, pode ser um aplicativo de servidor típico, .NET ou .NET Core serviços da web, caso de uso de IOT ou qualquer outro aplicativo de servidor pode utilizar isso por causa de sua popularidade e também por sua facilidade de uso. É muito fácil de configurar e você pode começar com ele.
O Entity Framework Core é uma nova variante. Essa é a nova direção que a Microsoft está tomando, em primeiro lugar de código aberto, é multiplataforma. Assim, você pode executar um aplicativo que está usando .NET Core ou você conhece .NET. Pode ser executado no Windows com .NET e com .NET Core ele pode ser executado no Windows, bem como em ambientes Linux e similarmente Núcleo do Entity Framework segue o terno, certo? Portanto, ele permite que você execute em ambientes Windows e Linux, se isso for um requisito, e é muito leve e modular por natureza. O que essencialmente significa que você não precisa passar por todos os componentes dentro do Entity Framework que costumava ter. O EF Core você pode trabalhar com o componente que você precisa. Você só pode obter o pacote NuGet para isso e, com base nisso, pode criar complexidade incremental em seu aplicativo.
Então, se você precisar, você sabe, gerenciar cenários complexos em seu aplicativo para esse assunto. E, além disso, é super-rápido por causa de .NET Core há um foco específico ou lado do desempenho também. Portanto, o Entity Framework Core foi projetado nas mesmas diretrizes em que o desempenho é um dos principais fatores que você pode alcançar.
Diagrama de arquitetura do Entity Framework
Então, aqui está um diagrama de arquitetura para o Entity Framework Core.
Eu encontrei um diagrama do Entity Framework que ainda se aplica, muitas coisas ainda se aplicam na arquitetura do Entity Framework Core também. Isso é do MSDN. Com o EF Core você tem um provedor de dados ADO.NET. Eu estarei usando o SQL Server como um exemplo de fonte de dados e então você tem o leitor de dados Entity Client que constrói árvores de comando, cenário de acesso a dados e então você tem serviços de objeto e no lado do aplicativo você trabalha com Entity Consulta SQL ou LINQ às Entidades. Então, novamente você trabalha com modelo de objeto e nos bastidores o Entity Framework Core cuida de todos os outros detalhes.
Existe um comando que você executa para gerar seu mapeamento e modelo em tempo de execução, então, modelo conceitual, EDMX, todos esses arquivos de mapeamento, eles se livraram deles dentro do Entity Framework Core. Então, é muito fácil configurar novamente. Novamente, é modular. Assim, você pode introduzir pacotes NuGet e criar um aplicativo Entity Framework Core muito simples em questão de minutos.
O que é escalabilidade?
A seguir, falarei sobre escalabilidade, que é outro conceito que queria destacar. Por que você precisa de cache em um aplicativo que está usando o Entity Framework Core? Em primeiro lugar, há um conceito de escalabilidade. Esse é um recurso muito bom dentro de um aplicativo, onde você pode obter alto desempenho do aplicativo e também sob cargas de pico, certo? Portanto, se você puder ter baixa latência e a menor latência possível e mantiver essa baixa latência sob baixa carga de usuário, digamos de cinco a dez usuários e se você tiver um design de arquitetura de aplicativo de forma que possa gerenciar o mesmo tipo de baixa latência sob uma enorme quantidade de solicitações de usuários carregadas, esse aplicativo seria categorizado como um aplicativo muito escalável.
E a escalabilidade linear é um conceito adicional associado onde você pode adicionar mais e mais servidores e distribuir sua carga e, ao distribuir a carga em vários servidores, mais servidores aumentariam a capacidade de tratamento de solicitações e esse aumento deve crescer de forma linear. Então, se você tem um aplicativo que está aumentando sua capacidade à medida que você adiciona mais servidores e que faz um banner de aumento linear que seria categorizado como um aplicativo linearmente escalável.
Quais são os aplicativos que precisam de escalabilidade?
Portanto, normalmente aplicativos que são de alta transação por natureza, como ASP.NET ou ASP.NET Core aplicativos da web, serviços da web, IOT, aplicativos de big data ou qualquer outro .NET ou .NET Core aplicativos que estão usando o núcleo do Entity Framework, eles exigem alta escalabilidade, certo? Portanto, eles precisam de alta carga transacional de capacidade de manuseio dentro de sua arquitetura.
Onde exatamente está o problema de escalabilidade?
Então, onde exatamente está o problema? Por que você precisa de um sistema de cache para superar esse problema? Você sempre pode criar um Web Farm e um App Farm onde o aplicativo Entity Framework Core pode ser dimensionado linearmente em si mesmo criando um Web Farm ou um App Farm. Você pode colocar um balanceador de carga na frente. Então, esse não é o principal ponto de preocupação. Sua camada de aplicativo sempre pode ser dimensionada. É assim que um Entity Framework Core e qualquer .NET ou .NET Core aplicativos são projetados. Onde você pode rotear solicitações para vários servidores e ainda poder usá-los em combinação entre si.
O principal problema é o gargalo de armazenamento de dados. Normalmente, se for um banco de dados relacional, esse é o exemplo que estamos usando. Os bancos de dados geralmente são uma única fonte para todo o armazenamento de dados. Eles são muito bons para armazenamento. Isso é algo em que eles são melhores. Mas quando se trata de lidar com uma quantidade extrema de cargas de solicitação, por exemplo, você tem muita carga de dados transacionais e de referência vindos de seus aplicativos, o banco de dados não foi projetado para lidar com essa quantidade aumentada de carga de solicitação. Funcionaria bem com baixas cargas de usuário, mas quando começa a consumir capacidade no lado da CPU, no lado da memória e há um túnel DBMS onde todas as solicitações estão sendo roteadas. As chances são de que seu armazenamento de dados se torne um gargalo de escalabilidade. Isso lhe daria degradação de desempenho, onde colocaria solicitações de fila que estão sendo geradas em tempo de execução. Portanto, não há como adicionar outro servidor de banco de dados.
Primeiro de tudo, é caro começar e então não há como você ter dois servidores sendo usados em combinação um com o outro. Portanto, isso não aumentaria o valor do desempenho, pois degradaria seu desempenho e afetaria também a experiência do usuário final e, por sua vez, também pode afetar seus negócios. Porque, se seus aplicativos são lentos em desempenho, muitos usuários não gostariam desse comportamento lento ou lento do seu aplicativo. Portanto, os aplicativos precisam de baixa latência e alta taxa de transferência o tempo todo e a manutenção de alta taxa de transferência vem com uma perda de desempenho e é isso que os bancos de dados tendem a ver onde eles simplesmente diminuem a velocidade de seus aplicativos ou tendem a sufocar completamente na maioria dos casos também.
A Solução
Nesta seção, falaremos sobre como lidar com isso. Solução é muito simples. Você pode usar sistema de cache distribuído por NCache. É muito rápido porque está na memória. É muito escalável porque não é apenas uma fonte única. Você pode ter quantos servidores precisar, adicionados ao cluster de cache e esses servidores em um cluster de cache funcionam em combinação entre si. Você pode distribuir seus dados e, em seguida, distribuir a carga de manipulação de solicitações e, adicionando mais servidores, você também obtém mais escalabilidade do sistema. Não é uma substituição de seus bancos de dados relacionais convencionais. Você usa um cache distribuído em seu aplicativo EF Core em combinação com um banco de dados. Portanto, você armazena em cache os dados mais facilmente acessados, seus dados de referência, ou também armazena em cache alguns de seus dados transacionais.
E falarei sobre como lidar com diferentes cenários de armazenamento em cache, estratégias de armazenamento em cache que você pode utilizar em seu aplicativo.
Arquitetura de Implantação
Aqui está a arquitetura de implantação que esclareceria ainda mais algumas coisas por que é a melhor opção em comparação com bancos de dados relacionais.
Em primeiro lugar, o cache distribuído fica entre seu aplicativo e a camada de banco de dados. E, dizendo no meio, é essencialmente que seu aplicativo usaria primeiro o cache se encontrar dados aqui, ele deve retornar se não encontrar dados aqui, só então deve ir para o banco de dados de back-end, certo? Portanto, em um posicionamento lógico, ele fica entre seu aplicativo e o banco de dados.
No que diz respeito à implantação, você pode ter seu aplicativo implantado em VMs, em caixas físicas, no local ou na nuvem. NCache é suportado no Microsoft Azure, bem como na AWS na forma de uma imagem pré-configurada ou qualquer outra nuvem pode usar nosso instalador que pode ser baixado do nosso site e então você pode começar pela instalação, que é muito fácil de configuração. NCache pode estar em sua própria camada, servidores dedicados separados para NCache ou pode ser executado nas mesmas caixas. Se você tiver caixas onde seu aplicativo está implantado, você pode implantar NCache no mesmo nível também. Recomendamos ter caixas separadas e você pode adicionar dois a três servidores para começar e, em seguida, pode adicionar mais e mais servidores com base em seus requisitos de tratamento de solicitações.
Se você precisar lidar, digamos, com 10,000 usuários e suas solicitações associadas, você pode executar alguns testes e ver quantos servidores você precisa. Em geral, com base em testes recentes, conseguimos atingir dois milhões de solicitações por segundo com apenas 4 a 5 NCache servidores, certo? Assim, você pode ver quantos servidores você precisa para lidar com os requisitos de carga do seu aplicativo. Apenas pré-requisito para NCache é .NET ou .NET Core. Ele roda no Windows, no Windows Nano, bem como em servidores Linux. Da mesma forma, seus aplicativos podem estar na plataforma Windows ou na plataforma Linux.
E também existem alguns recursos poderosos de sincronização de banco de dados. Como eu disse anteriormente, não é uma substituição de seus bancos de dados convencionais. Ele usa seu banco de dados, ele é usado junto com seu banco de dados, certo? Portanto, alguns dados seriam cache, mas todos os seus dados sempre existiriam em seu armazenamento permanente, que é seu banco de dados relacional. E, eu vou falar sobre como fazer o cache daqui a pouco.
3 casos de uso de cache distribuído comumente usados
Aqui estão alguns casos de uso comuns. Casos de uso gerais para cache distribuído e o mais proeminente é o cache de dados do seu aplicativo. Temos o Entity Framework Core aqui.
Cache de dados do aplicativo
Portanto, o primeiro caso de uso, que é nosso caso de uso mais comum, é o caso de uso de cache de dados do aplicativo. Nesse caso, você normalmente armazena em cache os dados que pertencem ao banco de dados. A motivação aqui é que você economiza viagens caras ao banco de dados o máximo possível e os benefícios que você obtém são o alto desempenho para a recuperação de dados. Como os bancos de dados são lentos em comparação com o acesso na memória, é na memória, é super-rápido e você tem vários servidores que hospedam e atendem sua solicitação do seu aplicativo. Assim, você obtém mais escalabilidade, mais rendimento do sistema e, ao mesmo tempo, mantém a baixa latência fornecida para o cache distribuído e, na maioria dos casos, é altamente disponível e confiável, também com base na topologia que você escolheu, ao contrário dos bancos de dados que podem não ser replicados em outros servidores.
Com o cache de dados do aplicativo, você pode armazenar em cache quase tudo. Você pode usar APIs diretas. Você pode armazenar em cache seus objetos de domínio, coleções, conjuntos de dados, itens únicos, resultados, quaisquer dados que deseja armazenar em cache e precisar desses dados novamente, considere usar nosso cache de objetos e com o Entity Framework Core, novamente você pode usar APIs diretas ou extensão métodos que vou lhe mostrar.
Cache de sessão ASP.NET e SignalR Backplane
Em seguida, outro caso de uso para NCache é ASP.NET e ASP.NET Core cache específico. Temos nosso cache de sessão. Cache de sessão em ASP.NET Core é através do IDistributedCache, bem como para o nosso NCache Provedor de sessão também. Então, essa é a segunda opção e então temos SignalR Backplane. Essa é outra opção que você pode utilizar. Se você tiver um aplicativo SignalR, poderá usar NCache como um Backplane. Esta é novamente uma opção sem alteração de código e, em seguida, temos o cache de resposta, o estado de exibição e o cache de saída. Portanto, esses são todos os recursos específicos do ASP.NET e, além disso, você também pode usar o cache de dados do aplicativo em seu aplicativo da Web, se necessário.
Mensagens do Pub/Sub e consultas contínuas
E então, temos poderosos Pub/Sub Messaging and Continuous Query Events ou, eu diria, Pub/Sub Messaging and Events. Você pode usar NCache como sua plataforma de mensagens, onde vários aplicativos estão conectados e esses aplicativos podem se comunicar usando nosso Pub/Sub Messaging. Um aplicativo pode publicar mensagens para NCache, que funciona como um canal de comunicação. Ele tem um conceito de tópicos e, em seguida, esses aplicativos de assinante podem receber essa mensagem se estiverem conectados a esse tópico. Assim, eles podem coordenar entre si o compartilhamento de dados, bem como mensagens personalizadas, se necessário. E podemos construir sistemas de mídia social. Você pode ter um sistema de bate-papo. Você pode ter tabelas de classificação. Você pode usá-lo em qualquer tipo de indústria, conforme necessário, onde você precisa ter componentes diferentes para coordenar seu aplicativo entre si.
Comunicação entre microsserviços
Microsserviços é outro caso de uso, onde você precisa ter aplicativos de microsserviços sem servidor, interagir uns com os outros e eles podem usar NCache para suas necessidades de comunicação e também temos eventos de consulta contínua. Eventos regulares em que seus dados são adicionados, atualizados ou removidos. Em vez do aplicativo enviar eventos, NCache pode enviar eventos para seus aplicativos com base em alterações de dados e isso pode ser em todos os itens ou em itens seletivos ou com base na Consulta Contínua onde você mapeia um conjunto de dados em NCache e NCache apenas envia eventos para esse conjunto de dados especificado.
Há também um quarto caso de uso. Temos recurso de pesquisa de texto completo. É muito comum em aplicativos de comércio eletrônico. Com NCache implementamos a API Lucene .NET. Portanto, se você estiver interessado no recurso de pesquisa de texto completo, NCache vem totalmente equipado com isso também.
Cache de dados do aplicativo no EF Core
Vamos falar sobre como você usaria o cache em um aplicativo típico do Entity Framework Core.
Configurando o aplicativo de exemplo
Então, em primeiro lugar, eu tenho este aplicativo. Aplicação de amostra alinhada aqui. É uma das amostras que vêm instaladas com NCache também. Então, se você for para C:\Arquivos de Programas\NCache\, essas amostras estão disponíveis aqui.
.NET e .NET Core amostras são colocadas separadamente. Então, eu seguiria em frente .NET Core e Entry Framework, temos o exemplo do EF Core aqui. Então, essa é a amostra que estou usando.
Mudei um pouco para demonstrar alguns desses cenários que pretendo apresentar neste webinar. Caso contrário, ele faz o trabalho básico para o seu POC. Certo, então, esta é a amostra. A próxima coisa que eu faria seria fazer logon em nosso ambiente de demonstração e começaria criando um cluster de cache para você, para que você realmente usasse um cluster de cache e o levasse a partir daí.
Criar um cache clusterizado
Portanto, para a criação de cache, temos nossa ferramenta de gerenciamento da web em funcionamento. Vou criar um rapidamente. Então, vamos em frente e adicionar um cache clusterizado. Vamos chamá-lo de democache. Vou anexar alguns números inteiros, democache111. A propósito, você pode manter o formato JSON ou binário, no que diz respeito à serialização. Ai está. Portanto, você pode ter o formato de serialização binário ou JSON. Eu vou em frente com o Binário, porque essa é a opção padrão. Existem quatro topologias de cache que você pode escolher e temos outros webinars, como NCache arquitetura que são especificamente direcionadas para, você sabe, explicar NCache arquitetura. Então, vou continuar com o Partitioned Replica Cache porque isso funciona muito bem para leituras, muito bem para gravações e é super escalável para capacidade de solicitação de leitura e gravação, se você continuar adicionando mais servidores e ele vem equipado com réplicas também , portanto, também não há tempo de inatividade ou perda de dados para seu aplicativo.
Então, eu manteria tudo simples, padrão. Replicação assíncrona entre a partição ativa e seu backup. Então, eu vou escolher isso, é mais rápido. Tamanho do cluster de cache e aqui especifiquei os servidores que hospedarão meu cluster de cache. Como eu disse, vou criar um cache rapidamente porque nosso foco principal é o Entity Framework Core. Caso contrário, em nossos webinars regulares NCache arquitetura ou dimensionamento de aplicativos do Azure com NCache, esses webinars falaram sobre todos esses recursos em grandes detalhes. Então, neste webinar em particular, vou seguir em frente e criar um cache rapidamente. Certo, então, eu especificaria a porta padrão TCP/IP e iniciaria e iniciaria automaticamente esse cache para que ele inicializasse automaticamente quando o servidor fosse reinicializado. Então, é mais ou menos isso.
Simule o estresse e monitore as estatísticas de cache
No que diz respeito às configurações de cache, você só precisa seguir este assistente e isso criaria um cache em vários servidores. Acho que começou também. Eu abria a janela de estatísticas e depois abria NCache janela do monitor que é outra ferramenta que vem instalada com NCache. Atualmente não há atividade, mas posso ir em frente e executar um aplicativo de ferramenta de teste de estresse. É chamado de ferramenta de estresse de teste e isso simularia alguma atividade fictícia, carga fictícia no meu cluster de cache. Apenas para verificar se tudo, foi configurado corretamente. Certo, então, você pode ver, você sabe, certo, mil a mil e quinhentas solicitações por segundo pelo servidor um, bem como pelo servidor dois. Então, no total, está processando cerca de três mil solicitações por segundo e você pode revisar a latência. Temos uma latência média mínima de microssegundos por operação de cache. Acho que está em algum lugar entre, algo em torno de quatro a cinco microssegundos.
Então, esse gráfico seria atualizado e a unidade diminuiria. Uma vez que nós, você sabe, adicionamos um pouco mais de carga. Vamos realmente seguir em frente e fazer isso. Direita. Então, eu tenho outra instância em execução. Só para mostrar que agora deve mostrar o valor aumentado aqui, lá vai. Então, temos cerca de, anteriormente, estava lidando com cerca de mil e quinhentas missões por segundo por cada servidor. Agora está em algum lugar entre duas mil a três mil solicitações por segundo por cada servidor e você pode ver a média de microssegundos por operação de cache em algo em torno de cinquenta a sessenta microssegundos por operação. Isso é um ganho de desempenho enorme. Considerando que seus aplicativos não estão sendo maximizados ou os servidores não estão sendo maximizados. Portanto, você pode esperar respostas abaixo de milissegundos ou microssegundos de seus aplicativos ao usar NCache. Assim, nosso ambiente está configurado. Tudo está configurado. Acho que estamos prontos para ir. Deixe-me parar esses testes e vamos em frente e criar, revisar nosso aplicativo de exemplo que fala sobre cenários de cache.
Quais entidades EF Core armazenar em cache?
Vamos falar primeiro sobre como fazer o cache dentro do Entity Framework Core. Quais entidades do EF Core armazenar em cache? Você tem duas opções, normalmente. Você pode ter uma Entidade Única ou um Resultado de Consulta, que é uma coleção de entidades, certo? Entidade única retornada ou pode ser uma coleção. Entidade única é armazenada como está. A coleção pode ser armazenada como um único item ou cada item da coleção pode ser adicionado individualmente no cache e vamos falar sobre como fazer isso.
Opções de cache de entidade do EF Core
direto NCache APIs. Existem duas abordagens. Em primeiro lugar, você pode usar NCache APIs diretamente, certo? Então, isso é algo que você pode usar em Open Source, Enterprise ou Professional também. E, então, temos os métodos de extensão do Entity Framework Core, nos quais passarei algum tempo.
Entidade única do EF Core em cache: NCache APIs diretas
APIs diretas. Aqui está um detalhe das APIs diretas. Deixe-me mostrar isso daqui, certo?
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}Então, normalmente este é o seu método de obtenção de cliente. Se você estiver usando APIs diretas, é provável que tenha um ID de cliente. Então, antes de tudo, você precisa construir uma chave de cache, certo. Então, isso é algo que você precisa fazer como uma obrigação. Porque, dentro NCache tudo é armazenado em um par chave-valor. Key é sua chave de string, para identificar um objeto. Uma parte do objeto é o valor real, a propriedade real que você deseja adicionar ao cache. Dados reais que você deseja armazenar em cache para seu aplicativo.
Então, eu criei essa organização chave, onde eu tenho cliente como uma palavra-chave e depois o ID do cliente e então forneço um parâmetro de tempo de execução que é passado para mim, certo? Então, isso identificaria esse cliente em particular aqui, com ID de cliente algo exclusivo, certo? Então, isso permitiria exclusivamente que você identificasse esses clientes e, em seguida, chamasse cache. Obtenha para recuperar itens do cache. Direita? Então, em primeiro lugar, se você está usando cache, você precisa ter certeza de que a chave foi construída e, em seguida, verifique se os dados estão disponíveis no cache chamando cache.Get e esse identificador de cache é algo que é retornado quando você inicializa o cache, certo?
Então, estou usando esse cache aqui, NCache.InitializeCache. Ele permite que você inicialize o cache e se conecte a ele. Se você encontrar os itens no cache, o que significa que o cliente não era nulo, você simplesmente voltou daqui. Você economiza viagens caras ao banco de dados e essa é a principal motivação de usar o sistema de cache onde NCache teria seus dados. Assim, você economiza suas viagens caras por meio do banco de dados de back-end. Você não precisa ir ao banco de dados. Mas, já que é a primeira vez que inicia este aplicativo. Então, nesse caso o cache não teria os dados.
Então, nesse caso, você executaria o Entity Framework Core, link dentro do Entity Framework Core. Ele retornaria um único item ou uma coleção. É um cenário de item único e, em seguida, você chama cache.Insert para realmente adicionar isso para o próximo uso e retornar ao cliente também. Portanto, da próxima vez, você sempre encontrará esses dados no cache, desde que não estejam sendo alterados ou não sejam sincronizados com os dados. Então, esse é o nosso único uso de Entidade, APIs diretas.
Coleção de entidades principais do EF em cache: NCache APIs diretas
No caso de Coleções, as APIs Diretas são muito semelhantes.
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} Temos clientes por cidade. A cidade do cliente é um parâmetro de tempo de execução. Construiremos uma lista de clientes e tentaremos buscar essa lista de coleção de NCache cache.Get, obtenha uma lista de clientes. Se não for nulo, retorne daqui, se for nulo, precisamos recuperá-lo do banco de dados de back-end e também adicioná-lo ao cache para o próximo uso. Então, é assim que é e se você quiser armazenar esses itens de cliente individualmente, você também pode iterar para este custList e chamar individualmente cache.Insert fornecendo chaves exclusivas para cada item de coleção também. Então, essa é outra opção que você pode utilizar.
Mas veja, você tem que primeiro construir uma chave, pegar o item do cache. Se estiver lá, faça o tratamento nulo e, se não estiver, você o obtém do banco de dados, executa a lógica de dados e também o adiciona. Então, isso é algo que você tem a ver com o Direct NCache APIs. É o caso de uso mais comum para qualquer cache de banco de dados típico. Para o cache de dados do aplicativo, isso é o que você faria normalmente.
Entidade única do EF Core em cache - Métodos de extensão do EF Core
Mas há outra abordagem, que é através dos nossos Métodos de Extensão e esse é o principal destaque. Você pode armazenar em cache a coleção inteira como um item ou armazenar em cache cada item de coleção separadamente, mas por meio de métodos de extensão.
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} Aqui está o nosso primeiro método de extensão que quero mostrar a você. Tudo bem, então, chama-se From Cache, mas faz muita automação para você, certo. Funciona de tal forma que, em primeiro lugar, permite que você construa algumas opções de cache, certo? Então, você primeiro cria opções de cache e um dos atributos que estou apresentando neste momento é Armazenar como. Então, NCache permitiria que você escolhesse se uma coleção precisa ser armazenada como um único item, como itens individuais, itens de coleção. Digamos que havia 10 itens na coleção. Então, esses seriam adicionados como 10 itens separados em NCache ou você quer armazená-lo como uma coleção que está aqui, certo? Então, essa é a segunda opção. Nesse caso, ele seria armazenado como um item no cache.
Então, estou usando entidades separadas. Então, se eu executar este código aqui, eu tenho um método de extensão que diz From Cache e se eu mostrar a definição disso, está vindo de NCache Alachisoft .NCache.EntityFrameworkCore. Esse é o namespace principal e se eu vier aqui e mostrar os pacotes NuGet. Em Instalado temos Alachisoft .NCachePacote .EFCore NuGet. Então, esse é o pacote NuGet que você precisa apresentar e depois disso você pode começar com esses métodos de extensão. Em primeiro lugar, é uma chave de cache de referência de saída, portanto, a chave de cache será gerada por NCache e dado a você. Então, essa é a flexibilidade e aí é só pegar as opções como parâmetro, né. Então, ele faz muita automação e nos bastidores está fazendo muito trabalho para você. FromCache funciona de tal forma que verificaria automaticamente os dados no cache primeiro, esse é o comportamento, se encontrar, não vai para o banco de dados.
Mas, se não estiver no cache e, em seguida, ele for para o banco de dados como regra e executar a consulta, o conjunto de resultados recuperado e adicionado ao cache usando essa chave de cache sendo preenchida e, em seguida, essas opções de cache configuradas para esse item . Portanto, se você compará-lo com este, não precisará construir a chave de cache. Você não precisa verificar a manipulação de nulos ou a obtenção do cache por conta própria. Você não precisa inseri-lo no cache. Você só precisa usar este método de extensão. Então, isso torna muitas coisas automatizadas e seu modelo de programação muito simplificado para seus aplicativos também.
Coleção de entidades do EF Core em cache: métodos de extensão do EF Core
E, no mesmo caso em que você gostaria de armazená-lo como uma coleção, você simplesmente fornece as opções de armazenamento em cache para ser coleção e, neste caso, você tem uma lista de clientes que você retornaria. Então, você apenas executa a consulta e, em seguida, chama FromCache novamente. Então, isso completa nosso primeiro método de extensão e introdução a ele.
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} Quais dados armazenar em cache no EF Core?
A seguir, falarei sobre dados de referência e transacionais. Este é o segmento principal.
Você estaria lidando com aplicativos que têm muitas leituras, dados com muitas leituras do que gravações e, em seguida, pode haver cenários de aplicativos em que temos leituras e gravações, certo? Então, por exemplo, produtos de dados de pesquisa, funcionários, que não mudam com tanta frequência, mas não são dados estáticos, é algo que muda, mas a frequência de mudança não é tão grande e dados inteiros devem existir no cache. Nesse cenário específico, explicarei o motivo e você deve expirar isso depois de algumas horas ou dias. Isso é como manter o cache atualizado, esse é outro segmento.
Então temos dados transacionais. Vou falar sobre como lidar com o cache de dados transacionais. Ele é criado dinamicamente. Encomendas, contas, são exemplos. Ele muda com muita frequência e, normalmente, os dados transacionais históricos não eram preferidos para armazenamento em cache. Porque, ele deveria mudar e deveria sair do seu aplicativo enquanto seu usuário estiver ativo, só é necessário nesse ponto. Mas, com base em nossa experiência, recomendamos que você ative o armazenamento em cache para dados transacionais também. Porque, enquanto você não está alterando, os dados ainda estão ativos, você pode lê-los muitas vezes e, se tiver milhões de usuários logados, isso resultaria em milhões de solicitações para esses dados voltando ao banco de dados e, se ele está armazenado em cache e mesmo que possa ser de duas a três solicitações, enquanto ele for alterado, ainda será benéfico do ponto de vista do desempenho. Portanto, é altamente recomendável que você considere armazenar em cache algumas de suas transações, se não todas.
Cache de dados de referência no EF Core
Tudo bem, como lidar com o cache de dados de referência no EF Core?
Eu tenho um processo de duas etapas para isso. Você pode carregar dados inteiros no cache, isso é obrigatório. Portanto, todos os seus dados de referência devem ser carregados no cache, é o que recomendamos como obrigatório. Por quê? Porque você não quer ir para o banco de dados, certo? Você deve ir em frente e começar a carregar todos os seus dados do banco de dados em NCache e temos o método de extensão que cuidaria disso imediatamente e usaria apenas o cache e evitaria viagens ao banco de dados.
A segunda etapa é sempre armazenar em cache como entidades separadas. Essa é outra dica que eu te daria de que você não deve armazenar em cache todos os produtos ou qualquer outro, todos os produtos como uma coleção, certo? Pode ser milhares de produtos ou milhões de produtos. Mas armazená-los individualmente permitiria que você buscasse subconjuntos de dados em um estágio posterior, certo. Assim, por exemplo, você carrega todos os produtos, mas em um momento posterior do cache você só precisa de produtos descontinuados. Então, se você os armazenou individualmente no cache, digamos, sessenta mil produtos, esse é o exemplo que vou mostrar. Você só pode encontrar os que você precisa naquele momento. Assim, você não precisa lidar com todo o conjunto de dados do produto e novamente economizando viagens caras ao banco de dados.
Cache de dados de referência no EF Core: cache de pré-carregamentoEntão, temos um método de extensão chamado LoadIntoCache, que é o próximo que vou mostrar a você e também um exemplo funcional disso.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
Agora, LoadIntoCache, em primeiro lugar, as opções de cache devem ser definidas como 'armazenar como entidades separadas' e, em seguida, você deve executar uma consulta que deve carregar todos os produtos e, em seguida, chamar LoadIntoCache e fornecer as opções e, novamente, apenas criará chaves de cache para todos eles individualmente, automaticamente. E continuaria carregando todos esses itens no cache e, em seguida, você pode executar consultas LINQ como esta e essa consulta LINQ é contra NCache. Não está usando nenhum método de extensão. Está chamando o produto em produtos de banco de dados onde product.Discontinued e temos apenas FromCache. Não está indo para o banco de dados. Está recebendo de NCache diretamente.
Cache de dados de referência no EF Core: dados de referência de pesquisa somente do cacheSe você tiver dados de referência, primeiro carregue entidades separadas. Use carregar no cache para carregar todos os produtos em NCache. Depois de fazer isso, você não precisa ir ao banco de dados. Então você usa FromCacheOnly em vez de FromCache. O primeiro método de extensão foi FromCache, que verifica o cache e depois vai para o banco de dados se não estiver no cache. Mas, LoadIntoCache carregaria todos os produtos e, em seguida, FromCacheOnly garantiria que ele falasse apenas com o cache, supondo que todos os dados fossem carregados no cache.
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}Deixe-me executar este código, para que você veja isso em ação. Eu tenho um cache que está configurado aqui mesmo para este teste e vou mostrar as estatísticas. Eu tenho brincado com isso. 60,000 produtos são carregados. Então, deixe-me ir em frente e limpar o conteúdo. Certo, então, vamos revisar as estatísticas. Onde está meu cache? Ai está. Certo, então, são zero itens e então eu irei em frente e executarei isso. Ele apenas armazenaria em cache o único item e, em seguida, coletaria todos os exemplos de código que mostrei, mas gostaria de mostrar como o LoadIntoCache funciona e, com base nisso, colocarei um ponto de interrupção lá também.
Então, os dois primeiros exemplos foram carregar um único item e depois carregar uma coleção, o código inicial que eu mostrei a você e, em seguida, isso aqui está realmente carregando todos os produtos para mostrar o cenário de dados de referência. Primeiro de tudo, está armazenando como entidades separadas e está configurando algumas prioridades, alguma dependência, é elaborado em termos disso e depois vai em frente e carrega todos os produtos, pegando-os do banco de dados e eu recomendo que você continue executando carregar o produto, carregado no cache após alguns intervalos, para que você tenha dados recuperados do banco de dados e carregue no cache sempre funciona contra o banco de dados. Ele sempre irá para o banco de dados e o que quer que você tenha no banco de dados, ele será executado no banco de dados e buscar esses dados de volta para NCache e, em seguida, use FromCacheOnly posteriormente.
Então, é assim que você lida com dados de referência. Em primeiro lugar, você os armazena individualmente, separadamente. LoadIntoCache, usando este método de extensão LoadIntoCache, que sempre executa no banco de dados. Não tem cache como prioridade. Ele sempre seria executado no banco de dados e, em seguida, buscaria tudo de volta para NCache e, em seguida, use FromCacheOnly. É assim que é simples.
Cache de dados transacionais no EF Core
Dados transacionais. Você pode carregar apenas o conjunto de trabalho. É para cache do conjunto de resultados, certo?
Eu pessoalmente recomendo que se você estiver interessado em clientes por uma cidade, pedidos baseados em um produto, você deve ter algum tipo de cache de conjunto de resultados e é isso que você deve fazer. Você deve armazená-los como uma coleção ou entidades separadas com base no tamanho dos resultados, se uma coleção não for tão grande, digamos que esteja lidando com 100 ou 200 itens no máximo, armazene-os como uma coleção e, mas se houver são vários produtos, vários pedidos ou informações de clientes, que seriam categorizados como dados transacionais. Armazená-los como entidade separada. Assim, você pode obter um subconjunto disso e maximizar o uso do cache.
Cache de dados transacionais no EF Core - buscar e armazenar em cache como coleçãoCaso de uso para isso é muito simples novamente. Você simplesmente armazena como uma coleção ou usa FromCache, você não usa FromCacheOnly porque gostaria de ir para o banco de dados se não estiver no cache.
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}Até agora, introduzimos três métodos de extensão. FromCache, que funciona com cache e banco de dados automaticamente e não no cache, você o obteria do banco de dados. LoadIntoCache sempre seria executado no banco de dados. Busque objetos e traga-os para o cache e FromCacheOnly sempre executando no cache e que seja a única fonte verdadeira de dados. Não iria para o banco de dados. Então, espero que isso esclareça muitas coisas.
Mantendo o cache atualizado
O próximo segmento é baseado em como manter o cache atualizado no Entity Framework Core e esse é outro conceito importante que vocês precisam entender ao lidar com duas fontes diferentes.
Você ativou o cache. Você tem o banco de dados de back-end, que é sua principal fonte de dados, armazenamento de dados persistente e, em seguida, o armazenamento em cache, que também possui uma cópia dos dados. Então, como garantir que o cache esteja atualizado em comparação com o banco de dados. Então, vamos passar um tempo aqui.
Manter o cache atualizado: dados de referência
Em primeiro lugar, você deveria, já que você tem todo o conjunto de dados no cache, e se houver uma alteração no banco de dados, certo?
Portanto, você precisa expirar os dados do cache e, para isso, recomendamos que você use a expiração e, em seguida, o recarregamento automático dos dados, pode ser uma opção. Então, a primeira estratégia é usar a expiração, mas sem recarregar. Assim, cada vez que os dados expiram, eles também são recarregados automaticamente no cache e para isso temos essa configuração aqui, Carregar todos os produtos.
Estratégia 1: Use a expiração, mas com recarga automáticavoid LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Deixe-me apenas mostrar isso daqui, certo. Então, em primeiro lugar, você os armazena como entidades separadas porque esse é o caso de uso de dados de referência. Você os carrega como todos os produtos e então configura algum tipo de expiração e então options.SetResyncProvider, deve haver um provedor de recarregamento e então configura options.IsSyncEnabled para true. Então, recarregamento automático, para que ele recarregue automaticamente no cache caso expire, certo. Portanto, essas são as duas propriedades junto com, se você SetResyncProviderName, definiria automaticamente o sinalizador de recarregamento automático como verdadeiro.
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}E, então, você precisa de ResyncProvider aqui, ou seja, nossa implementação de exemplo está bem aqui que estou mostrando.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}Ai está. Você precisa implementar nosso IReadThruProvider. Inicialize sua fonte de dados, descarte-a no final e então você LoadFromSource permite que você obtenha a chave e com base nessa chave você constrói um comando SQL e busca os itens do banco de dados e eu dei uma implementação de exemplo aqui onde construímos um Consulta SQL da chave de cache que temos.
Certo, então, essa chave, nesta implementação de exemplo, também está disponível no GitHub. Então, ele funcionará de tal forma que seus itens que são carregados no cache, se eu executar o carregamento no cache mais uma vez, eles terão expiração anexada. Portanto, eles expirariam após cinco a dez horas, qualquer que fosse o período de expiração e, depois disso, esse provedor entraria em ação e chamaria LoadFromSource usando o manipulador de leitura automática e os dados atualizados seriam trazidos para NCache. Certo, então seu cache seria automaticamente atualizado depois que os itens expirassem.
Estratégia 2: não use a expiração, recarregue manualmenteA segunda abordagem que eu pessoalmente recomendo é não usar expressão, recarregar manualmente chamando LoadIntoCache. E, isso é algo muito simples que você deve criar com este método LoadIntoCache, se eu mostrar mais uma vez. Continue chamando esse método após alguns intervalos e não use nenhuma expressão. Vamos nos livrar desses.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Então, você sabe que esses dados de referência serão válidos apenas para, digamos, uma hora, duas horas, cinco dias, semana, mês. Com base nisso, continue repetindo essa carga de todos os produtos. Isso deve ser chamado após alguns intervalos, certo?
Então, essa é a ideia de que você deve recarregar os dados manualmente com base em uma estimativa inteligente feita no intervalo de expiração, certo? Portanto, você deve definir o horário de trabalho, após o qual deve chamar automaticamente o carregamento de todos os produtos. Assim, ele obtém automaticamente os dados do banco de dados de back-end e seus dados de referência são mantidos atualizados.
Então, eu vou reiterar isso. Então, há duas opções. Se você estiver usando os dados de expiração, serão removidos do cache. Então, você acabaria com conjuntos parciais, então, você precisa recarregar automaticamente como uma obrigação. Mas, se você não usar a expiração, terá todos os dados no cache o tempo todo para dados de referência e poderá recarregar manualmente esses dados após determinados intervalos. Espero que isso esclareça.
Mantenha o cache atualizado: dados transacionais
Em seguida, falaria sobre manter o cache atualizado para dados transacionais e isso é bem simples. Você deve sempre usar expiração curta sem recarregar automaticamente. Porque, novamente, esses são dados de curta duração que podem ser válidos apenas por cinco a dez minutos e você deve usar o FromCache, para que, se não estiver no cache, você sempre o obtenha do banco de dados de back-end.
E, aqui está um exemplo disso, onde temos pedidos de clientes, armazenamos como uma coleção ou itens individuais, depende inteiramente de você. Expiração curta, se necessário, ou não use uma expiração, ou use a expiração e não use nenhuma recarga automática para esse assunto. Para que seja recuperado do banco de dados assim que expirar. Eu pessoalmente recomendo usar uma expiração configurável ou chegar a uma expiração que você sabe com certeza que é um tempo de trabalho para esse conjunto de dados. Para que depois disso não fosse necessário. Portanto, ele deve expirar automaticamente e, nesse ponto, você impõe um acesso ao banco de dados e o obtém automaticamente do banco de dados de back-end.
Expiração curta, sem recarga automática private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}Portanto, abordamos como lidar com dados de referência, bem como dados transacionais. Em seguida, também abordamos como manter o cache atualizado para referência, bem como dados transacionais.
Manipulando relacionamentos em cache
Um para muitos
Algumas outras coisas que você pode encontrar com o cache. Manipulando relacionamentos em cache para EF Core. Novamente, é muito simples. Incluir é suportado, portanto, se você tiver região com regiões de banco de dados e obter região.Territórios ao lado deles, certo? Portanto, você pode chamar FromCache e armazenar regiões separadamente e territórios separadamente e formular uma relação entre região e territórios. Então, se eu te mostrar região com territórios.
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}Isso aqui é um exemplo. Direita. Portanto, os detalhes dessa região incluem e estamos usando o FromCache. Portanto, armazenaremos regiões e territórios de região separadamente, itens separados e, em seguida, construiremos uma dependência baseada em chave. Se as regiões passarem por uma mudança, os territórios também serão invalidados e vice-versa. Então, é assim que você lidaria com relacionamentos um-para-um ou um-para-muitos.
Cache de Operações Agregadas
Operações agregadas também são suportadas. Portanto, você pode executar esses métodos de extensão com um Deferred First ou Default, FromCache. Pode ser baseado em contagem diferida, FromCache. Então, ele os armazenaria como conjunto de resultados, certo? Portanto, não importa se você os armazena como itens de coleção ou únicos, pois isso é apenas resultado de operações agregadas. Então, essa é outra possibilidade com nosso Entity Framework.
Operações Agregadas de Cache - Retornando Entidades
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Operações Agregadas em Cache - Retornando Valores
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}Arquitetura de cache distribuído
Então, no final, gostaria de falar sobre alguns detalhes arquitetônicos sobre cache distribuído. Por que você deve considerá-lo. É altamente disponível, é super confiável, com replicação. É um cache arquitetado ponto a ponto. Não há um único ponto de falha. Você pode adicionar ou remover qualquer servidor em tempo de execução e os clientes têm suporte de failover de conexão construído para ele. Portanto, é altamente disponível e super confiável com 100% de tempo de atividade. Ele vem com muitas topologias de cache, cache de cliente, replicação de WAN, réplicas particionadas e particionadas e posso falar especificamente sobre detalhes de arquitetura se houver alguma dúvida, caso contrário, neste momento, isso conclui nossa apresentação.
High Availability
Topologias de cache
Cache do cliente (próximo ao cache)
Replicação WAN de Cache
Conclusão
Gostaria de fazer uma rápida recapitulação disso. Neste webinar falamos sobre opções de cache, APIs diretas, Métodos de Extensão do Entity Framework Core. Então, temos opções de escolha entre eles. Estávamos mais focados nos métodos de extensão do Entity Framework Core porque é isso que gostaríamos de projetar. É mais fácil de usar. Como lidar com dados de referência e transacionais. Então, falamos sobre abordagens de carregar dados inteiros para dados de referência e, em seguida, usar a abordagem de entidades separadas e, em seguida, usar o cache apenas para todos os dados que você tem no cache. Para dados transacionais, recomendamos apenas armazenar em cache para o conjunto de resultados e, em seguida, usar o método de extensão FromCache para que você possa acessar o banco de dados se ele não estiver no cache. E então, para manter o cache atualizado, falamos que você deve usar expiração com recarregamento automático para dados de referência ou não usar expiração, mas recarregar manualmente após determinados intervalos e para dados transacionais, certifique-se de usar expiração, certo? Isso deve ser uma expiração curta, mas sem recarregamento automático, portanto, você pode voltar ao banco de dados e atualizar seu cache no próximo uso.
Você sempre pode nos contatar em support@alachisoft.com. Se você tiver alguma dúvida técnica, você também pode entrar em contato conosco em sales@alachisoft.com. Se você quiser dar uma olhada no produto, você pode baixar NCache Enterprise para uma avaliação gratuita de 30 dias.