Redis vs NCache
Webinar gravado
Por Ron Hussain e Zack Khan
NCache é um cache distribuído .NET Open Source nativo que é muito popular entre .NET de alta transação, .NET Core e aplicativos Java. Redis é desenvolvido pela Redis Labs e atualmente é usado pela Microsoft no Azure. Neste webinar, saiba como NCache e Redis comparar entre si. O objetivo deste webinar é facilitar e agilizar sua tarefa de comparar os dois produtos, especialmente em aspectos qualitativos, como recursos, desempenho, escalabilidade, alta disponibilidade, confiabilidade de dados e administração.
Aqui está o que este webinar aborda:
- Desempenho e escalabilidade
- Elasticidade de cache (alta disponibilidade)
- Topologias de cache
- SQL e LINQ Pesquisando o Cache
- Integrações de terceiros (EF, EF Core, NHibernate etc)
Hoje, temos o tópico de comparar dois produtos que são muito semelhantes, mas também diferentes em muitos aspectos. Então nós temos NCache que é nosso principal produto de cache distribuído para .NET e .NET Core aplicativos e, em seguida, compararemos do ponto de vista de recursos com Redis. Então, temos muito o que cobrir nisso. Vou abordar muitos detalhes técnicos, começando pela plataforma e pela pilha de tecnologia. Em seguida, falaremos sobre o agrupamento. Como esses dois produtos se comparam em relação ao cluster de cache e quais são os diferentes benefícios que você obtém ao usar esses produtos e, em comparação, como NCache é melhor e depois falarei sobre os diferentes recursos. Nós iremos comparação de recurso por recurso em relação aos diferentes casos de uso em que você pode usar esses produtos e, em seguida, como esses dois produtos se comparam do ponto de vista da comparação de recursos.
Para este webinar, selecionei NCache Enterprise 5.0.2, na medida em que Redis está preocupado, vamos nos concentrar principalmente no Azure Redis. Isso é código aberto Redis 4.0.1.4. Mas, eu também daria detalhes sobre o Redis projeto de código aberto, bem como, Redis laboratório que é a variante comercial do Redis. Então, vamos comparar NCache com todos esses sabores, mas nosso foco principal seria o Microsoft Azure Redis, o modelo hospedado de Redis que você pode obter no Microsoft Azure.
O problema de escalabilidade
Então, antes de começarmos, vou passar principalmente pelos detalhes introdutórios sobre esses dois produtos. Então, por que exatamente você precisa de uma solução de cache distribuído?
Então, e depois disso, você iria em frente e compararia produtos diferentes. Portanto, normalmente é o desafio de escalabilidade e desempenho que você pode estar enfrentando em seu aplicativo. Pode ser que seu aplicativo esteja recebendo muita carga de dados e, embora sua camada de aplicativo seja muito escalável, você sempre pode criar um web farm, pode adicionar mais recursos na camada de aplicativo, mas todas essas instâncias de aplicativo devem voltar e conversar de volta -end fontes de dados. E, quando você precisa voltar e conversar com essas fontes de dados, é aí que você vê problemas de desempenho porque os bancos de dados, normalmente os bancos de dados relacionais, são lentos em termos de manipulação de carga transacional.
Há um problema de desempenho associado a eles e, em termos de dimensionamento, por exemplo, se você precisar ter muita capacidade de manipulação de solicitações ou requisitos em torno disso, precisamos lidar com muitas solicitações e seus aplicativos estão gerando muitos carga do usuário, o banco de dados não foi projetado para lidar com essa carga transacional extrema. É muito bom para armazenamento, onde você pode armazenar muitos dados, mas ter carga transacional nesses dados é algo para o qual o banco de dados não seria um candidato muito bom. Pode sufocar. Isso lhe daria lentidão e a experiência do usuário final pode ser degradada.
Assim, você pode ter um impacto no desempenho e não tem a capacidade de aumentar a capacidade dentro da arquitetura do aplicativo.
A solução: cache distribuído na memória (NCache)
A solução é muito simples, você usa um sistema de cache distribuído na memória como NCache que é super-rápido porque está na memória. Então, em comparação com um banco de dados relacional ou um sistema de arquivos ou qualquer outra fonte de dados que não seja baseada em memória, se estiver vindo de um disco em comparação com o armazenamento de seus dados na memória, na memória, isso o tornará super- velozes. Então, o primeiro benefício que você obtém é que você obtém um desempenho super-rápido de NCache.
O segundo benefício é que é um cluster de cache. Não é apenas uma única fonte. Você pode começar com um servidor, mas normalmente recomendamos que você tenha pelo menos dois servidores e crie um cluster de cache e assim que criar esse cluster de cache, melhoraria se apenas distribuíssemos a carga em todos os servidores e você continuasse adicionando mais servidores em tempo de execução.
Assim, você pode dimensionar sua capacidade, você pode aumentar a capacidade em tempo de execução adicionando mais servidores e usá-lo em combinação com seus bancos de dados relacionais de back-end também. Não é uma substituição de seus bancos de dados relacionais convencionais e falaremos sobre alguns casos de uso mais adiante.
Implantação de Cache Distribuído (NCache)
Aqui está uma implantação típica.
estou a usar NCache como um exemplo por enquanto, mas mais adiante nesta apresentação, compararemos como Redis é implantado e como NCache é implantado e quais são as flexibilidades disponíveis nesses produtos.
Então, para NCache, é muito flexível. Você pode optar por implantá-lo no ambiente Windows, bem como no Linux. Ele está disponível no local e é compatível com ambientes de nuvem. Está disponível no Azure, bem como AWS marketplaces. Assim, você pode obter uma imagem pré-configurada de NCache e comece com ele. Estão disponíveis contêineres do Docker para Windows e Linux, que você pode usar em qualquer plataforma, onde precisar usar isso.
Normalmente, seus aplicativos, sejam eles hospedados no local ou na nuvem, podem ser um serviço de aplicativo, pode ser um Cloud service, pode ser um microsserviço, pode ser o site do Azure, qualquer tipo de aplicativo pode se conectar a ele no modelo cliente-servidor e fica entre seu aplicativo e seu banco de dados back-end e esse é o modelo de uso típico. A ideia aqui é que você armazene dados dentro NCache e, como resultado, você economizaria viagens caras ao banco de dados de back-end. Você economizaria as viagens ao banco de dados o máximo possível e sempre que precisar ir ao banco de dados, sempre iria ao banco de dados, buscar dados e trazê-los para o cache para que da próxima vez que os dados existissem e você não tenha para ir ao banco de dados. E, como resultado, o desempenho de seus aplicativos e a escalabilidade geral são aprimorados porque agora você tem acesso à memória, o que melhora o desempenho. Você tem vários servidores que hospedam e atendem suas solicitações, suas solicitações de dados. Então, é mais escalável em comparação. Além disso, há recursos de alta disponibilidade e confiabilidade de dados que também são incorporados NCache protocolo.
NCache podem ser hospedados nas mesmas caixas, onde seus aplicativos estão sendo executados. Ou pode ser apenas uma camada separada. Na nuvem, a abordagem preferencial seria usar uma camada dedicada separada de cache e, em seguida, seus aplicativos são, as instâncias do aplicativo estão sendo executadas em sua respectiva camada. Mas, ambos os modelos são suportados na medida em que NCache está preocupado.
Alguns números de escalabilidade. Recentemente, realizamos esses testes em nosso laboratório da AWS, onde simulamos a carga de solicitação de leitura e gravação e continuamos aumentando a carga e, após certo ponto, quando vimos que os servidores estão sendo maximizados, aumentamos o número de servidores no cluster de cache. Assim, de 2 a 3 servidores e depois de 3 a 4, conseguimos atingir 2 milhões de solicitações por segundo com apenas 5 NCache servidores e isso não é, isso não era um dado touch-and-go. Esses eram dados de aplicativos da vida real, mas simulados em nosso laboratório da AWS dentro de nossos aplicativos. E, o fator de latência também foi muito otimizado. Conseguimos tudo isso com latência de microssegundos. Assim, o desempenho da solicitação individual não foi prejudicado, quando conseguimos atingir toda essa carga.
Casos de uso comuns: cache distribuído
Alguns casos de uso e isso é algo comum para Redis também, mas vou falar sobre como NCache compararia.
Cache de dados do aplicativo
Onde você armazena em cache quase tudo que normalmente busca no banco de dados de back-end e os dados existem em seu banco de dados e agora você deseja armazená-lo em cache. Assim, você economiza viagens caras ao banco de dados e já estabelecemos que o banco de dados é lento e não é muito ideal em termos de manuseio de carga de transações. Temos muitos recursos de sincronização de banco de dados nesta linha, mas nesta você simplesmente se conecta a NCache e usar basicamente nossas APIs para fazer conexão, você sabe, fazer qualquer chamada de dados para NCache. Assim, você pode armazenar em cache quase tudo. Pode ser seus objetos de domínio, coleções, conjuntos de dados, imagens, qualquer tipo de dados relacionados a aplicativos que podem ser armazenados em cache usando nosso modelo de cache de dados.
ASP.NET/ASP.NET Core Cache
Então temos nosso ASP.NET e ASP.NET Core cache específico. Isso é novamente um caso de uso técnico, onde você pode usá-lo para ASP.NET ou ASP.NET Core cache de estado de sessão. ASP.NET ou ASP.NET Core SignalR Backplane. NCache pode ser conectado como um Backplane. Para ASP.NET Core você também pode usá-lo para o Cache de Resposta. Interface e sessões IDistributedCache através IDdistribuídoCache interface, esses dois recursos também são suportados com NCache e para aplicativos legados, você também pode usá-lo para View State e Output Caching. queria fazer uma pergunta rápida para você, Ron.
Nós entramos, a questão é NCache e o Azure dão suporte a um modelo de programação sem servidor?
Absolutamente. Isso é algo que, em termos de implantação do Azure, você pode ter seus aplicativos implantados em servidores ou em seu aplicativo, no que diz respeito à parte do aplicativo, também podem ser aplicativos sem servidor. Você pode simplesmente incluir nossos pacotes NuGet dentro de seu aplicativo e esses aplicativos podem apenas fazer NCache ligam sempre que precisam. Eles nem precisam ter qualquer instalação de NCache ou ter uma configuração de servidor no que diz respeito aos recursos do aplicativo. Mas, até onde, NCache a implantação do lado do servidor está preocupada porque NCache é a fonte de dados, portanto, deve ter uma VM ou um conjunto de VMs, onde seus aplicativos se conectam, recuperam e adicionam dados.
Então, dos servidores, NCache ponto de vista do servidor de cache, como uma fonte que você precisa NCache servidores, mas no que diz respeito aos seus aplicativos, eles podem ser estritamente sem servidor e não há problemas. Até arquitetura de microsserviços. Esse é um exemplo muito comum, onde microsserviços, existem muitos microsserviços. Pode haver uma função do Azure, que está apenas executando e que lida com muitos dados e esses dados podem vir NCache. Então, você trata NCache como fonte de dados. Considerando que seus aplicativos podem ser sem servidor e NCache é totalmente compatível com esse modelo.
Mensagens e eventos do Pub/Sub
Então outro caso de uso está por aí Mensagens do Pub/Sub e isso gira em torno de microsserviços porque esse é um dos casos de uso impressionantes em que você pode usar mensagens para aplicativos sem servidor. Os microsserviços são aplicativos sem servidor acoplados frouxamente e construir uma comunicação entre eles é um grande desafio. Assim, você pode usar nossa plataforma de mensagens Pub/Sub, onde você pode utilizar nosso mecanismo de propagação de eventos assíncronos orientado a eventos. Onde vários aplicativos podem publicar mensagens para NCache e os assinantes podem receber essas mensagens.
Como é baseado em um mecanismo orientado a eventos assíncrono, os aplicativos do editor não precisam esperar pelo reconhecimento ou pelas mensagens sendo entregues e, da mesma forma, os assinantes não precisam esperar ou enviar mensagens. Eles são notificados por meio de retornos de chamada quando as notificações. Então, é muito flexível e esse é outro caso de uso em que você pode usar NCache como uma plataforma de mensagens Pub/Sub para seus aplicativos.
NCache HISTÓRIA
Mais alguns detalhes e depois falaremos sobre as diferenças entre NCache e Redis. NCache foi lançado em 2005. Está no mercado há mais de 15 anos. Versão atual do NCache é 5.0, 15ª versão. Temos muitos e muitos clientes. NCache também está disponível na edição Open Source. Que você pode baixar do nosso site, bem como do repositório GitHub.
Alguns NCache Clientes
Alguns de nossos clientes. Você também pode obter uma lista detalhada.
Plataforma e tecnologia
A seguir falaremos sobre como NCache compara com Redis e o primeiro segmento é construído em alguns detalhes introdutórios sobre a tecnologia em geral. Essas serão informações sobre a tecnologia de cache distribuído. Agora vamos nos concentrar diretamente em como NCache compara com Redis e tenho alguns segmentos que formulei.
Então, a primeira seção que definimos é plataforma e tecnologia e mencionei inicialmente que estamos segmentando NCache 5.0.2. Então, NCache 5.0 SP2 é a versão principal em NCache local e de Redis ponto de vista, usaremos o Azure Redis como comparação e também falaremos sobre Open Source e Redis Laboratório como parte disso. A maioria desses detalhes são comuns para diferentes sabores de Redis.
Cache .NET nativo
Então, vindo de um background do Azure, se você planeja escolher um produto, a primeira coisa seria a compatibilidade com a plataforma.
então, NCache em si é escrito em 100% .NET. É um .NET nativo ou.NET Core produto, no que diz respeito às suas aplicações, certo. Então, basicamente, ele é escrito em .NET e principalmente para aplicativos .NET e é implantado no Windows Server 2016, 2019 e até 2012. Apenas pré-requisito para NCache is .NET framework or .NET Core para esse assunto. Considerando que, para Redis, está escrito em C++. NCache é escrito em .NET. É 100% desenvolvido, na verdade C# é a principal linguagem de tecnologia que estamos usando e é 100% nativa .NET e .NET Core. Enquanto que Redis é uma solução baseada em C++ Linux.
Então, vindo de uma perspectiva do Windows, do Windows background e se você tem seus aplicativos escritos em .NET, a escolha natural seria usar um produto que também é escrito em .NET para que você esteja na mesma pilha de tecnologia. Você não precisa ter muitas variações na pilha de desenvolvimento de aplicativos. Então, esse é um problema ou uma diferença entre esses dois produtos.
O segundo aspecto é o Windows versus Linux e então você sabe o que está disponível em NCache e o que está disponível Redis lateral. Windows, do ponto de vista NCache implantação, que é uma implantação preferencial, mas também temos uma implantação Linux disponível com a ajuda de nossos .NET Core Liberação do servidor. Portanto, somos totalmente compatíveis com o Windows 2012, 2016, 2019. Nossas imagens do Docker também estão disponíveis para a variante do Windows. Uma variante de NCache. Então, você pode simplesmente baixar nossa imagem do Docker e girar a imagem do Windows de NCache conforme necessário e nós o apoiamos totalmente em ambiente de produção. É um apoio oficial do nosso lado. Considerando que, se você comparar Redis mesmo no Microsoft Azure o Redis está hospedado no Linux. A abordagem preferida, o modelo de implantação preferido é o Linux para Redis. A variante do Windows é um projeto de terceiros. O Microsoft Open Tech tem uma versão portada dele. Não há apoio oficial de Redis em si. O projeto em si é arquivado. Está bugado, instável e até o Azure Redis, como discutido anteriormente, usa a versão Linux e o grande problema com isso é que você não tem um suporte oficial do Redisfabricantes de Redis ou do ponto de vista, se você quiser usar o projeto de código aberto e quiser implantá-lo em sua própria premissa, é aí que você veria muitos problemas.
Como parte disso, eu também gostaria de destacar um outro aspecto é, se você usar NCache no local e agora você deseja migrar do local e gostaria de usar no Azure, o mesmo software funciona como está. Portanto, não há necessidade de mudança de mover NCache do local para o Azure. Da mesma forma, dentro dos fornecedores de nuvem, se você planeja usar NCache no Azure, você pode simplesmente migrar para a AWS, se precisar. Porque, exatamente o mesmo software está disponível em todas as plataformas. Considerando que, tanto quanto, Redis está preocupado, Azure Redis é um modelo hospedado que é implantado no Linux no que diz respeito à implantação de back-end, mas você não tem a mesma variante disponível no local. Então, você tem que lidar com código aberto Redis ou algum provedor terceirizado. Mesmo você tem que ir com uma variante comercial, que é um produto completamente diferente.
Então, o ponto principal que eu gostaria de destacar aqui é que Redis no local que é de código aberto ou alguma versão comercial versus Redis no Azure ou Redis na AWS, que é o Elastic Cache. Estes são produtos completamente separados. Então, há uma transição, há muita mudança. Você não pode portar Redis de um ambiente para outro sem passar por algumas mudanças. Alguns conjuntos de recursos estão ausentes. Algumas APIs são diferentes. O modelo de implantação é completamente alterado entre esses produtos. Então, não há mudanças se você mantiver NCache no local no Windows ou Linux e agora você deseja migrar e ir para o Azure, seria exatamente o mesmo produto e agora deseja alterá-lo do Azure para AWS, deseja alterar o fornecedor da nuvem, é mais flexível em comparação para Redis. Assim, NCache é muito mais flexível.
Suporte Linux, NCache é totalmente compatível, oficialmente suportado. Até o desempenho é testado e o desempenho do Linux é super-rápido, equivalente a NCache no Windows. Temos imagens do Docker disponíveis. Totalmente suportado em produção e temos ferramentas de monitoramento e gerenciamento totalmente integradas que você pode, estas são ferramentas de gerenciamento e monitoramento da web que você pode acessar de qualquer lugar. Assim, até mesmo suas implantações do Linux podem ser gerenciadas e monitoradas como você implantaria, gerenciaria e monitoraria suas implantações do Windows com NCache. Linux também é suportado em Redis. Assim, seu suporte à produção disponibilizado pela Redis Laboratório. Azure Redis também está hospedado na versão Linux. Portanto, é suportado pelo próprio fornecedor.
O segundo aspecto depois da plataforma é novamente o .NET e .NET Core, a pilha de tecnologia. Temos um Cliente oficial disponível. Nós o implementamos. Apoiamos totalmente e se houver algum conjunto de recursos e é por isso que NCache é compatível em toda a linha. Portanto, se você escolher ambientes locais ou Azure ou AWS, terá o mesmo sabor de NCache e seu Cliente disponível em toda a linha. E, se houver alguma alteração que precise ser feita, forneceremos essas alterações oficialmente porque somos donos de tudo, bem como do projeto. Considerando que, para Redis é um terceiro. Assim, para diferentes idiomas, o suporte vindo de diferentes idiomas também vem de diferentes fornecedores. Portanto, pode haver uma diferença no conjunto de recursos. Pode haver uma diferença no ciclo de lançamento. Portanto, você precisa confiar em clientes de terceiros no que diz respeito à tecnologia no que diz respeito aos requisitos do cliente.
Então, quero destacar alguns aspectos em torno NCache sendo .NET nativo e .NET Core produto. NCache é totalmente suportado no Windows, bem como no Linux. Enquanto que, Redis não é muito estável no Windows. É a versão portada de terceiros e o suporte ao Linux está disponível e é isso, então, você precisa confiar no suporte do Linux até Redis está preocupado. Então, vindo de um background em tecnologia da Microsoft, isso é algo em que você precisa confiar.
Desempenho e escalabilidade do cache
O segundo aspecto é nosso desempenho de cache. Esse também é um aspecto muito importante.
Ambos os produtos são muito rápidos e essa é a ideia aqui que principal benefício de NCache e Redis, a principal razão pela qual você escolheria tal produto é o aspecto de melhoria de desempenho. Já estabelecemos que os bancos de dados são lentos e pouco escaláveis. Esses produtos são rápidos e muito escaláveis em comparação. Então, eu não tiraria nada de Redis. Apenas a versão do Windows não é estável e há problemas de desempenho, mas se você tiver a versão do Linux, também é muito rápido e escalável e é extremamente rápido e NCache também é muito rápido. É muito escalável. Temos nosso próprio protocolo de clustering baseado em TCP/IP implementado, que é muito otimizado e muito robusto em desempenho.
No entanto, existem algumas diferenças aqui também. Dentro de NCache temos muitos recursos de melhoria de desempenho. Recentemente, também fizemos um webinar, onde abordamos seis maneiras diferentes de melhorar NCache atuação. Se você configurar NCache por padrão, ele lhe dará um desempenho muito bom, mas além disso, com base em seus casos de uso, você pode habilitar diferentes recursos e melhorar ainda mais o desempenho e um desses recursos é o nosso Cache de Cliente.
NCache: Cache do cliente (próximo ao cache)
Client Cache é um recurso exclusivo para NCache. Redis não tem esse recurso.
É um cache local do lado do cliente, que novamente é possível mesmo para aplicativos sem servidor, onde você pode ter uma cópia InProc dentro do processo do aplicativo e/ou para aplicativos baseados em servidor, você pode usar um cache do cliente fora do processo . A ideia aqui é que isso economizaria viagens caras pela rede para o cluster de cache. Esse cache já estava salvando viagens para as fontes de dados de back-end. Agora você pode ter cache no meio e assumir que você tem 100 itens no cache, se você alimentou alguns itens no lado do aplicativo, digamos 10 itens, esses 10 itens seriam trazidos de volta ao cache do cliente automaticamente e da próxima vez seu aplicativo encontraria esses dados mais próximos de seu aplicativo e, como resultado, economizaria viagens de rede caras.
E, este é um cache de cliente sincronizado. A sincronização é gerenciada por NCache. Qualquer alteração no cache do cliente é propagado no cache do servidor tanto porque essa é a cópia mestre. Este é um subconjunto dos dados e essa alteração também é propagada para outros caches de clientes. Se você tiver um cenário de dados de referência. Se você tiver muitas leituras e gravações, é altamente recomendável ativar o cache do cliente e obter um desempenho muito bom em comparação com um cache que está sendo executado em nosso banco de dados.
Recentemente fizemos um POC com um dos nossos clientes, um dos nossos maiores clientes. Onde eles tinham um fluxo de trabalho, que demorava cerca de 46 segundos com as configurações padrão. Eles estavam fazendo um monte de NCache chamadas e recuperação de dados. Portanto, foi principalmente um caso de uso intensivo de leitura. Ativamos o cache do cliente fora do processo, a propósito, existem dois tipos, você pode mantê-lo fora do processo, o que significa que um processo de cache separado é executado na caixa do aplicativo ou você pode ter o InProc, onde o cache do cliente é executado dentro do processo do aplicativo. O InProc não possui serialização ou processo para processar sobrecarga de comunicação. Então, é extremamente rápido. Mesmo em comparação com OutProc é mais rápido. Então, com esse cliente, o fluxo de trabalho estava demorando cerca de 46 segundos para começar. Em seguida, ativamos o cache do cliente fora do processo, reduzimos para 3 a 4 segundos e, em seguida, ativamos ainda mais o cache do cliente InProc e conseguimos fazer tudo isso em 400 a 500 milissegundos. De 46 segundos a 400 a 500 milissegundos, esse é o tipo de melhoria de que estamos falando e esse recurso está completamente indisponível em nenhum outro produto ou mesmo em qualquer outro sabor de Redis, incluindo Redis Labs, incluindo projeto de código aberto e Azure Redis.
Assim, você pode ajustar o desempenho, usando nosso cache de cliente e é um trabalho sem alteração de código. É apenas uma configuração que você ativa.
As operações em massa são suportadas em ambos os lados, mas com NCache é, nossas operações em massa funcionam em todo o cluster de cache, o que significa que, se você tiver dez servidores e tiver dados totalmente distribuídos, uma chamada em massa buscará dados de todos esses servidores e o resultado consolidado será recuperado. Então, todos esses trabalham em combinação uns com os outros para formular o resultado e então você obtém um resultado que é completo por natureza. Enquanto que Redis as operações em massa estão em um nível de estilhaço. Então, você tem que lidar com dados em um determinado shard. Então, essa é a limitação. Se você tiver, digamos, vários nós no cluster de cache e tiver fragmentos mestres disponíveis, portanto, você poderá executar operações em massa em um determinado fragmento.
Então, essa é a limitação. Caso contrário, esse é um bom recurso de melhoria de desempenho, onde você, em vez de ir e voltar para solicitações individuais, envia uma solicitação grande e obtém todos os dados de uma só vez e, como resultado, comprova seu desempenho.
Serialização, esse é outro recurso e há outro aspecto, porque a maior parte do seu tempo seria gasto em serialização e desserialização de dados e isso é verdade para NCache bem como para Redis. Por padrão, ambos os produtos seriam serializados e desserializados, mas com NCache existe uma maneira de melhorar sua sobrecarga de serialização e desserialização. Temos uma serialização rápida e complexa, que otimizaria seu tempo de serialização, o que normalmente seu aplicativo levaria. Seus objetos se tornam complexos. Portanto, sem nenhuma alteração de código, você pode defini-los como tipos compactos e NCache garantiria que ele executasse a serialização compacta neles em tempo de execução e melhoraria sua sobrecarga de serialização e desserialização.
Por fim, também temos o recurso de compactação. A compactação é feita na extremidade do cliente. Normalmente, se você estiver lidando com objetos maiores, digamos, 2 MB, 3 MB ou digamos 500 kilobytes, esse é um objeto maior. Portanto, normalmente recomendamos que você lide com objetos menores, mas se você tiver objetos maiores, haverá muita utilização da rede e o desempenho também será prejudicado. Com NCache você pode ativar a compactação. Essa é uma opção sem alteração de código, que não está disponível no Redis side e comprimiria automaticamente os itens ao adicionar ao cache. Assim, objetos menores são adicionados e transferidos, viajam entre seu aplicativo e o cache e, da mesma forma, o mesmo objeto menor também é recuperado no final do aplicativo. Lidar com uma carga útil menor melhora o desempenho de seus aplicativos. Portanto, o desempenho geral do aplicativo aumentaria se a compactação estivesse ativada.
Portanto, recomendamos que qualquer objeto maior que, digamos, 100 kilobytes, você definitivamente deve ativar a compactação e há um limite que você pode ativar e apenas objetos maiores são compactados, objetos menores são deixados como estão.
Portanto, todos esses recursos de melhoria de desempenho, cache do cliente, operações em massa, serialização compacta, compactação, não estão disponíveis ou Redis. Por exemplo, o cache do cliente não está disponível. As operações em massa estão disponíveis, mas são limitadas. Não há opções de otimização de serialização e a compactação é algo que não está disponível. Então, é aí que você tem uma clara diferença entre NCache e Redis, Onde NCache é um pacote completo onde temos muitos recursos centrados em desempenho embutidos nele.
High Availability
O próximo segmento é a alta disponibilidade e é aí que você verá uma enorme diferença no conjunto de recursos entre NCache e Redis. A alta disponibilidade é outro aspecto em que essas partes podem ser comparadas. Para aplicativos de missão crítica, este é um aspecto muito importante que você precisa de uma fonte. Agora você está trazendo seus dados que normalmente estão no banco de dados e dentro do banco de dados você teria algum tipo de espelhamento, algum tipo de backup, certo?
Então, com os dados sendo movidos em um produto que é cache distribuído, embora melhore seu desempenho, é muito escalável, mas a alta disponibilidade é um aspecto muito importante. Para aplicativos de missão crítica, qualquer tempo de inatividade não é aceitável. Isso afetaria seus negócios e a experiência do usuário pode ser afetada. Então, não é acessível. Portanto, é muito importante que seu aplicativo sempre consiga obter resposta do cache onde os dados existem. Então, aqui temos um enorme conjunto de diferenças de recursos.
Cluster de cache
NCache é um cluster de cache arquitetado 100% ponto a ponto.
É dinâmico e auto-curativo e vou falar sobre como, você sabe, isso funciona, mas em comparação Redis usa mestre/escravo. Então, sendo arquitetura peer-to-peer NCache permite adicionar e remover servidores automaticamente e é perfeito para seus aplicativos. Você pode ir em frente e adicionar quantos servidores precisar. Por exemplo, você começou com 2 servidores. Agora você deseja adicionar o terceiro servidor, você pode fazer isso rapidamente. Você não precisa parar o cache ou os aplicativos cliente que estão conectados a esse cache. A experiência perfeita é observada. Assim, seus aplicativos podem continuar funcionando sem qualquer tempo de inatividade ou perda de dados com nossos recursos de alta disponibilidade e confiabilidade de dados. Considerando que, em Redis você não pode adicionar novos fragmentos automaticamente. Porque não há rebalanceamento automático de dados. Esse é o núcleo da natureza dinâmica do nosso cluster de cache. Dentro de NCache, ele reequilibra automaticamente os dados se você quiser adicionar novos servidores.
Então, existem dois cenários. Um em que você adiciona um novo servidor para trazer capacidade, para trazer mais escalabilidade e o outro cenário é que você desativa um servidor.
Então, vamos primeiro abordar o cenário do nó sendo adicionado. Um novo nó é unido. Com NCache, seus dados serão distribuídos automaticamente.
Por exemplo, de 2 para 3 servidores, se você adicionar mais 2, você tinha 6 itens aqui e você adicionar outro servidor para o qual os dados existentes seriam transmitidos, serão balanceados para o servidor recém-adicionado. Então, esse servidor pegaria parte dos dados dos servidores existentes e isso será feito automaticamente. É dinâmico por natureza. Então, há um rebalanceamento automático de dados que acontece. Com Redis, é um rebalanceamento manual de dados e isso é verdade para o Azure Redis porque há diferentes conjuntos de camadas disponíveis no Azure. Há um básico, há um nível médio e há um avançado. O clustering só entra em jogo com o avançado aqui, que também é caro e, além disso, eles precisam de pelo menos 3 servidores, o que é novamente uma limitação.
Com o NCache você pode até ter o clustering totalmente instalado e funcionando com apenas 2 servidores e, além disso, adicionar um novo servidor requer um rebalanceamento manual de dados. Essa é uma grande questão. Então, você teria algum tipo de limitação no aplicativo e quando planeja adicionar capacidade. Considerando que, com NCache você pode conseguir isso em tempo de execução. Você pode adicionar mais servidores rapidamente.
O segundo aspecto é um servidor caindo. Então, temos, dentro Redis temos um conceito de mestre e escravo. Um mestre replica os dados para o escravo. Há um fragmento de escravo. Portanto, o mestre deve replicar os dados e pode ser de maneira síncrona ou assíncrona. Dentro Redis, se um estilhaço escravo cair, o próprio mestre para, o cluster se torna inutilizável. Então, isso é um grande problema e isso pode acontecer o tempo todo. Estritamente em implantações no local onde você tem um código aberto ou Redis Implantação de laboratório de Redis. Nesse caso, se um servidor ficar inativo e for o escravo de um shard mestre, o próprio cluster se tornará inutilizável. Então, você tem que se envolver e fazer uma intervenção manual para se recuperar desse cenário. Considerando que dentro NCache é automático. Assim, qualquer servidor pode cair, o nó sobrevivente e ele pode estar ativo ou de backup.
Por exemplo, este servidor fica inativo, esta é uma partição ativa, também possui uma partição de backup. Se todo este servidor ficar inativo, o backup promove o ativo. A partição de backup é promovida para ativa e você obtém todos os dados do nó sobrevivente e há um failover de conexão incorporado a ela. Qualquer servidor com clientes inativos detectaria isso em tempo de execução e eles decidiriam e fariam failover para os nós sobreviventes e aqui eu gostaria de reforçar esse conceito de que, com o Redis você precisa no mínimo 3 servidores. Este é o conceito de regra da maioria. O coordenador do cluster tem que ganhar uma eleição. Não é o caso com NCache. Você pode iniciar o cluster de cache totalmente funcional com apenas 2 nós e fornecer recursos completos de alta disponibilidade. Qualquer servidor caindo, um nó sobrevivente é totalmente capaz de trabalhar sem problemas e esse não é o caso com Redis.
Configurações dinâmicas. Você pode alterar as configurações do cluster em tempo de execução e isso envolve adicionar novos servidores, remover servidores ou alterar algumas configurações no cluster de cache. Isso é algo que você pode aplicar em um cluster de falha inteiro em tempo de execução sem interrompê-lo. Considerando que para Redis, é limitado. Há muitas configurações que você precisa aplicar manualmente e, em seguida, há muitos eventos de integridade do cluster disponíveis no NCache lado, que você pode assinar. Você pode usar ferramentas de monitoramento e gerenciamento em cima dele. Enquanto que, Redis não tem essas características.
Então, esse é um conceito muito importante. Deixe-me apenas resumir para você. Adicionando e removendo um servidor em Redis é algo que lhe daria muitos problemas. Para adicionar dados não seria rebalanceado automaticamente. Portanto, não é cem por cento arquitetura peer-to-peer. Portanto, o cluster de cache é limitado em sua capacidade. Da mesma forma, se um fragmento escravo cair, o próprio cluster se tornará inutilizável. Porque há um problema de distribuição que agora você precisa gerenciar manualmente. Failover também é manual, certo? Portanto, se um servidor cair, você precisará fazer o failover manualmente e começar a usar os nós sobreviventes. Se você adicionar novos servidores, ele terá que mudar manualmente para os servidores recém-adicionados.
Então, essas são todas as limitações que você teria e, sabe, eu ficaria surpreso em ver o uso de uma implantação de produção dessa natureza e agora você precisa aumentar a capacidade ou precisa desativar os servidores para manutenção. Então, isso seria muito difícil com produtos como Redis. Enquanto que, NCache oferece uma experiência perfeita. Onde você pode adicionar ou remover servidores rapidamente sem afetar nada.
Partições/Fragmentos Dinâmicos
Agora, outro conceito dentro, você sabe, o cluster é o mecanismo de autocura.
NCache tem partições dinâmicas. Você adiciona mais servidores, os dados são redistributadas, novas partições são formuladas em tempo de execução. Da mesma forma, você desativa um servidor, o cluster tornaria o backup disponível e ele se curaria e formularia um cluster de cache de 2 nós saudável se você o reduzisse de 3 para 2 e, em seguida, o aspecto de confiabilidade. Tem direito de partições de replicação, que também está disponível em Redis como a forma de escravos, mas sua alta disponibilidade depende da replicação. Eles não têm com Redis você não teria alta disponibilidade se não tivesse shards escravos configurados. Então, você precisa ter fragmentos de escravos disponíveis. Considerando que, com a NCache, temos topologias.
Por exemplo, Partitioned Cache, onde temos master shards, master partitions. Se esse servidor ficar inativo, você ainda terá alta disponibilidade porque os clientes detectariam isso e fariam failover e começariam a usar o nó de sobrevivência. Eles teriam perda de dados e isso é verdade para Redis também. Perda de dados porque não há replicação, mas ainda está altamente disponível e, em seguida, temos um aprimoramento para isso, onde também temos suporte à replicação. Se este servidor ficar inativo, não só o backup do servidor será disponibilizado aos clientes automaticamente com failover. Então, Redis é limitado. Sua alta disponibilidade depende da replicação. Não é altamente disponível, se a replicação não estiver ativada, o que também é um fator limitante.
E então o mecanismo de autocura, embora nenhuma intervenção manual seja necessária.
Se você começar com 3 servidores, você derrubará um servidor, usará uma partição ativa, um mestre e também perderá um escravo de outro servidor. Então, nesse caso o backup do servidor 3 estava no servidor 1, então, isso se torna ativado. Ele se junta às partições ativas em tempo de execução. Nenhuma intervenção é necessária. O trabalho manual é necessário e, em seguida, o servidor de partição 2 formularia uma partição íntegra no servidor 1. Assim, o cluster se recuperaria automaticamente e essa é a natureza dinâmica do NCache em comparação a Redis. Para onde Redis, os estilhaços não podem ser reajustados em tempo de execução. O cluster para se o fragmento escravo ficar inativo. Os dados redisa tribulação não é dinâmica. A alta disponibilidade depende da replicação, o que não acontece com NCache. NCache oferece alta disponibilidade mesmo sem replicação.
Então, todos esses benefícios que você obtém NCache, o torna um produto muito mais superior porque esses recursos estão completamente ausentes ou limitados em Redis e isso é verdade para o Azure Redis. Isso também é verdade para o código aberto porque são produtos muito comparáveis e isso também é verdade para Redis Laboratório Redis oferecendo também.
NCache Demo
Agora vou passar algum tempo mostrando o produto real em ação para que você tenha uma ideia de como NCache fica configurado. Então, este é o nosso ambiente de demonstração. Eu tenho trabalhado com isso. Então, vou apenas criar um novo cache. Esta é a nossa ferramenta de gestão web que vem instalada com NCache. O modo de serialização pode ser binário ou JSON. Depende inteiramente de você. Vou apenas nomear o cache e mostrar como criar um cluster de cache, conectar um aplicativo cliente e monitorá-lo e gerenciá-lo também.
Então, vou manter tudo simples porque o foco principal deste webinar é em torno NCache vs Redis, então, vou manter todos os detalhes simples. Réplica particionada, essa é nossa topologia mais recomendada. Replicação assíncrona entre ativo e backup. Então, você pode escolher Sincronizar. O assíncrono é mais rápido, então vou usar isso. Tamanho do cluster de cache. Então vou especificar esses nós de servidor onde NCache já está instalado. porta TCP. NCache é um protocolo de comunicação de base TCP/IP. Então, vou manter tudo simples e nisso vou habilitar o despejo para que o cache fique cheio. Assim, ele remove automaticamente alguns itens do cache e, como resultado, abre espaço para os itens mais recentes. Inicie esta cache e termine. Iniciar automaticamente na inicialização do serviço, portanto, toda vez que meu servidor for reinicializado, ele ingressará automaticamente no cluster de cache e pronto. É assim que é simples configurar um cluster de cache e depois usá-lo, o que mostrarei a seguir.
Suporte à nuvem (Azure e AWS)
Então, nosso modelo de serviço gerenciado está chegando. Nosso próximo lançamento está focado no que eu acho que daqui a duas ou três semanas. Assim, teremos uma gestão totalmente NCache software como um modelo de serviço no Azure, bem como na AWS.
No momento, será o modelo VM. Se você tiver no local, poderá usar caixas físicas ou de VM. Se você escolher o Azure, precisará configurar sua VM por meio do marketplace ou apenas configurar uma VM e instalar NCache software baixando em nosso site. E também temos o ambiente conteinerizado. Temos imagens Docker e somos totalmente suportados no Azure Kubernetes Service, EKS - Elastic Kubernetes Service e qualquer outro, por exemplo, plataforma OpenShift Kubernetes, NCache já está totalmente integrado e totalmente suportado nessas plataformas. No que diz respeito ao aspecto gerenciado, isso é algo que está surgindo. Então, daqui a duas ou três semanas, estaria totalmente disponível.
Então, vou mostrar a você a janela de estatísticas, que é um contador de perfmon e, a propósito, essas opções de monitoramento estão disponíveis para NCache, em termos de NCache tanto no ambiente Windows quanto no Linux, certo?
Então, vou executar uma ferramenta de teste de estresse. Acho que já tem um rodando para outro cache. Então, eu vou executar mais um e isso simularia nossa carga fictícia em nosso cluster de cache. Você apenas especifica o nome e ele descobre automaticamente os servidores usando os arquivos de configuração e apenas se conecta a ele.
Portanto, temos status de cluster totalmente conectado, solicitações por segundo mostrando taxa de transferência, latência por microssegundo médio por operação de cache, adições, buscas, atualizações, exclusões, tamanho do cache, CPU, memória. Assim, você obtém uma visão de monitoramento centralizada. Você pode usar esta ferramenta. Você também pode usar o Windows perfmon.
Para Linux temos nosso monitoramento customizado. Assim, você também pode usar nossa ferramenta de monitoramento diretamente para servidores Linux e também pode usar qualquer ferramenta de terceiros para monitoramento NCache também. Então, essa foi uma rápida olhada em nosso processo de criação de cache. Alguns aspectos de monitoramento e gerenciamento.
Então, voltando. Já que discutimos alguns detalhes. A próxima coisa que eu gostaria de discutir é a oferta de nuvem/suporte à nuvem. Agora Redis em si, você pode escolher um cache não gerenciado, você também pode escolher o cache gerenciado e, em seguida, há um serviço hospedado disponível e a opção de gerenciamento é de fornecedores de terceiros. A opção hospedada é do Azure Redis, onde você pode ter uma variante de código aberto de Redis personalizado pela Microsoft e que está disponível como um modelo hospedado. Considerando que, no NCache lado, temos o modelo de servidor de cache, modelo VM. Eu já discuti a abordagem do contêiner. É totalmente compatível com Windows, bem como com contêineres Linux. Temos demonstrações em vídeo disponíveis para contêineres do Azure Service Fabric para Windows, detalhes da arquitetura de microsserviços. Temos o Serviço de Kubernetes do Azure que está usando contêineres do Linux. EKS – Elastic Kubernetes Service e acho que também fizemos Red Hat OpenShift Containers por meio do Kubernetes.
Então, essas são todas as opções de implantação de contêiner disponíveis e são flexíveis, sua plataforma, você sabe, não é específica da plataforma. Assim, você pode implantá-lo em qualquer tipo de plataforma em contêiner sem problemas. O serviço gerenciado está chegando, então já discutimos isso. Então, isso é algo em que NCache teria gerenciado o serviço, mas isso está em nossa próxima versão.
Um aspecto importante é o benefício de usar um modelo de VM, embora você precise se conectar a uma VM em vez de um serviço, mas você controla tudo. Você pode executar o código do lado do servidor que abordarei a seguir, mas o aspecto mais importante é o aspecto do desempenho. Já discutimos que há muitos recursos de desempenho dentro NCache, que faltam Redis. Se você optar por ter o Azure Redis, você teria que se conectar à infraestrutura do Azure. Então, essas são VMs, que estão sendo executadas em uma rede virtual separada. Estes estão localizados nas proximidades, mas novamente eles estão longe. É diferente da sua própria rede virtual que você tem no Microsoft Azure e onde você tem todas as suas implantações de aplicativos.
Com o NCache você pode escolher nosso NCache implantação na mesma rede virtual, como suas redes virtuais de aplicativo. Por exemplo, seu serviço de aplicativo, seu site do Azure, seus microsserviços do Azure, eles estão sendo executados em uma rede virtual do Azure. Você pode optar por implantar VMs do Azure na mesma rede virtual e melhorar o desempenho do seu aplicativo. Com base em nossos próprios testes em nosso laboratório, NCache foi quatro a cinco vezes mais rápido que o modelo SaaS de Redis que você normalmente obtém no Microsoft Azure. Então, esse é um aspecto muito importante que eu gostaria de destacar.
Além disso, você obtém muito controle sobre sua VM. Você tem controle total sobre como iniciar um cache, aumentar o tamanho e obter capacidade total. Não há limite de unidades de solicitação, não há limite de tamanho, não há pegada de uso e você não está sendo cobrado como parte disso. Você traz sua própria licença e isso também pode ser perpétuo, isso também pode ser uma licença de assinatura, que pode ser muito flexível em termos de licenciamento. Além disso, você pode executar o código do lado do servidor em cima do seu NCache servidores. Você pode gerenciar isso totalmente. Você pode otimizar totalmente isso. Você pode escrever muitas interfaces. Tais como, read-through, write-through, write-behind, cache loader e alguns recursos de grade de computação, como MapReduce, Aggregator, Entry processors e isso só é possível com NCache. Mesmo nosso modelo SaaS que seria um modelo hospedado que teria todas essas ofertas disponíveis, o que não vai ser o caso de Redis. Então, essa é a nossa plataforma.
Mantendo o cache atualizado
Próximo segmento, próximos 15 minutos eu gastaria na comparação de nível de recurso e para isso tenho alguns segmentos definidos. Então, vou começar se você precisar manter o cache atualizado e isso é muito importante, deve haver um webinar separado apenas sobre isso, como manter o cache atualizado especificamente em relação às fontes de dados de back-end, em relação ao uso do aplicativo casos.
Então, em comparação com Redis, você sabe, NCache tem um monte de recursos deste lado também.
Temos expiração da base de tempo, que é absoluta e deslizante, mas também temos um mecanismo de recarga automática disponível para isso. Redis só tem expiração absoluta e deslizante sem nenhum mecanismo de recarga. Para recarregar, permitimos que você implemente uma interface, chamada manipulador de leitura, que é um código do lado do servidor. Novamente, isso é possível porque NCache permite que você dê, tenha acesso total às suas VMs onde NCache está hospedado. Assim, você pode implantar o código do lado do servidor em cima de NCache E use NCache poder computacional para apoiá-lo.
Você pode sincronizar seu cache com banco de dados. NCache é muito forte na sincronização de banco de dados. Temos dependência SQL. Temos dependência de banco de dados que é apenas compatível com banco de dados. Temos procedimentos armazenados .NET CLR. Portanto, todos esses recursos permitem que você sincronize seu cache com o banco de dados. E a ideia aqui é se houver uma mudança no banco de dados, um registro no banco de dados mudar e você tiver esse registro armazenado em cache, essas duas fontes podem estar fora de sincronia. Então com NCache, se houver uma alteração no banco de dados, você poderá invalidar ou recarregar automaticamente esses dados em NCache em tempo de execução. Este é um recurso exclusivo para NCache. Nenhum outro produto tem esse recurso. Assim, você pode ter cache totalmente sincronizado com seu banco de dados back-end e isso não é verdade apenas para bancos de dados relacionais, também temos recursos no lado de fontes de dados não relacionais.
A dependência de arquivo é outro recurso em que você pode tornar os itens dependentes do arquivo. Conteúdo do arquivo, se o conteúdo for alterado, os itens serão removidos ou recarregados automaticamente. E dependência personalizada, você pode usar com qualquer fonte. Poderia ser um NoSQL database, pode ser um sistema de arquivos ou relacional, qualquer conector, qualquer serviço web. Assim, você pode validar itens com base em seus requisitos flexíveis. Demos uma implementação dessa dependência com o Cosmos DB. Então, nós implementamos a sincronização de NCache com Cosmos DB. Se você estiver usando NCache ao lado do cosmos DB, você pode usar a dependência personalizada e acho que fiz um webinar sobre isso também.
Manipulação de dados relacionais. Assim, os dados relacionais têm relacionamentos. Os itens no cache são pares de valores-chave para que você possa fazer relacionamentos entre itens diferentes e isso é algo que não está disponível no Redis lateral. Então, você teria que lidar com itens em seu mérito separado. Considerando que, com NCache você pode combinar itens em grupos um para um, um para muitos ou muitos para muitos. O item pai passa por uma alteração, o item filho pode ser automaticamente invalidado ou recarregado, conforme necessário.
Agrupamento de dados, pesquisa SQL e LINQ
Outro aspecto é o agrupamento e busca de dados, onde NCache é muito forte & Redis não possui nenhum recurso. E, novamente, isso é verdade para o Azure Redis que é muito limitado de qualquer maneira. O código aberto Redis está um pouco à frente, mas ainda é limitado em termos de recursos. Mesmo o Redis Lab, a versão comercial do Redis, que não está equipado com esses recursos.
A pesquisa SQL está disponível. Você pode pesquisar itens dentro NCache com base em seus atributos de objeto. Os objetos são adicionados ao cache. Você pode definir índices para seus atributos. Por exemplo, os produtos podem estar no índice por seu ID, seu preço, suas categorias e agora você pode pesquisar esses produtos usando esses atributos. Um exemplo típico seria selecionar o produto em que a categoria do ponto do produto é algo ou o preço do ponto do produto é maior que 10 e o preço do ponto do produto é menor que 100 e NCache executaria uma pesquisa na memória em todos os itens, em todos os servidores, consolidaria os resultados e traria de volta o conjunto de resultados. Assim, você não precisa mais lidar com chaves. Você recupera dados com base em um critério.
As pesquisas LINQ também estão disponíveis. Temos .NET e .NET Core aplicativos. Se você estiver usando, você sabe, a pesquisa LINQ, você pode executar a pesquisa LINQ em NCache também. Então, esse é um recurso exclusivo para NCache onde Redis não tem nenhum suporte. Redis qualquer, todos os sabores de Redis, não tem esse suporte.
Você pode ter grupos, subgrupos. Você pode fazer coleções logicamente dentro NCache. Isso não está disponível em Redis e você pode recuperar, atualizar e remover dados com base nesses grupos.
Tags e tags nomeadas podem ser atribuídas. Por exemplo, você pode usar palavras-chave que podem ser anexadas aos seus itens. Um exemplo típico seria que você pode marcar todos os clientes com a etiqueta do cliente. Todos os pedidos com uma etiqueta de pedido e pedidos de um determinado cliente também podem ter um ID de cliente anexado como uma etiqueta. Quando você precisar de pedidos, basta dizer obter por tag e fornecer os pedidos como uma tag, para que você receba todos os pedidos. Quando você precisa de pedidos de um determinado cliente, você diz obter por qualquer tag ou obter por tag e fornecer o ID do cliente, ele obterá todos os pedidos, mas apenas para esse ID do cliente. Então, essa é a flexibilidade de usar tags e tags nomeadas que você tem com NCache. Redis não suporta estes.
Código .NET do lado do servidor
Já discutimos que normalmente usamos o padrão cache-aside, onde você primeiro verifica os dados no cache, se for encontrado lá você retorna, se não encontrar dados no cache, você iria para o banco de dados de back-end em seu aplicativo e, em seguida, buscar esses dados e trazê-los para o cache. Então, há um null, você recupera null e então você vai para o banco de dados. Você pode automatizar isso com a ajuda do manipulador Read-Thru. É um código do lado do servidor que é executado em seu NCache servidores. Nosso serviço gerenciado também teria esse recurso. Então, você implementa essa interface que permite conectar-se a qualquer fonte de dados. Pode ser um serviço da Web, uma fonte de dados relacional ou uma fonte de dados não relacional e há vários métodos que seriam chamados assim que houvesse um nulo encontrado no cache.
Então, você chama o método Cache.Get, habilita o sinalizador Read-Thru. Se o item não estiver no cache, a chamada é passada para o manipulador Read-Thru e, como resultado, você buscaria dados do banco de dados de back-end passando por esse código do manipulador. Qual é o seu código de usuário em execução NCache lado do servidor. Assim, você pode facilmente passar NCache e obter os dados que você precisa.
Write-through é o oposto dele, que também é suportado e Redis não possui esses recursos onde você pode atualizar algo no cache e agora deseja atualizar o banco de dados, pode atualizar o banco de dados chamando seu manipulador de gravação. Você implementa e registra esse manipulador write-through e NCache chamaria para atualizar o banco de dados de back-end e o write-behind é o oposto dele. Qualquer atualização no cache, aplicativo cliente retorna e NCache atualizaria o banco de dados de back-end de forma assíncrona nos bastidores. Então, NCache pode até melhorar seu desempenho para operações de gravação no banco de dados, o que não é possível com Redis ou qualquer outro produto, se você não tiver a capacidade de executar o código do lado do servidor. E este é um .NET puramente nativo e .NET Core bibliotecas de classes que você pode implementar e registrar como leitura e gravação por meio de interfaces, o que é possível com NCache.
O carregador de cache é outro recurso. Onde você pode pré-preencher o cache implementando uma interface e registrando-se com NCache. Assim, cada vez que você reinicia seu cache, você carrega automaticamente alguns de seus dados importantes dentro NCache e isso é executado em todos os servidores simultaneamente. Então, é super rápido. Assim, você pode pré-preencher todos os seus dados e nunca mais precisará acessar o banco de dados. Você sempre encontraria esses dados porque os pré-carregou.
Dependência personalizada, processador de entrada, esses são novamente recursos exclusivos apenas para NCache e o motivo o principal motivo de não poder usar esses recursos. Em primeiro lugar, Redis não tem esses recursos, os módulos não são suportados no Azure Redis ou mesmo em código aberto Redis. Do lado do servidor, o código não é possível com o Azure Redis. Principalmente, porque você não tem acesso às VMs subjacentes e esse foi o principal motivo pelo qual eu estava me referindo anteriormente com NCache em um modelo de VM no momento, você tem acesso total onde o implanta, como o controla, como o gerencia. Assim, você tem controle total. Não é uma caixa preta como Redis é.
Replicação WAN para Multi-Datacenter
Mais alguns detalhes e então eu vou concluir isso. A replicação de WAN é outro aspecto.
Ativo-passivo é suportado em Redis, onde você pode transferir todo o datacenter, cache de um datacenter para outro. Dentro NCache, temos ativo-passivo. Portanto, transição unidirecional de dados de um datacenter para outro. Também temos um caso de uso ativo-ativo, que é muito urgente e muito importante, em que você pode ter os dois sites ativos. Você precisa das atualizações do site um no site dois e vice-versa. Então, isso não é uma habilidade em Redis lado. Você não tem essa capacidade, portanto, não pode executar sites ativos-ativos com Redis. Com NCache isso é verdade para o caso de uso de cache de dados do seu aplicativo em que você tem dados em ambos os sites sendo atualizados e isso também é possível por meio de nossas sessões de vários sites. Então, esse é outro espaço onde NCache é um vencedor claro.
Topologias de cache
Em seguida, alguns outros detalhes. Topologias de cache. Temos uma lista enorme de topologias de cache em comparação com Redis.
Então, com base em diferentes casos de uso, nós espelhamos, replicamos, particionamos e depois Partition Replica e já debatemos, discutimos como NCache clustering é melhor em geral e temos muito mais opções em comparação com Redis Ofertas.
Ferramentas GUI - Administração e Monitoramento de Cache
Então temos ferramentas GUI. Aqui está uma comparação. Gerente, monitor.
Considerando que temos ferramentas do PowerShell, temos ferramentas de despejo e recarregamento, administração completa, aspectos de monitoramento são incorporados a ele. Enquanto que, Redis é limitado nessa frente também e, como parte disso, mostrei alguns detalhes e isso é verdade para Windows, bem como para implantações de Linux de NCache.
Recursos específicos do ASP.NET
Alguns recursos de cache específicos do ASP.NET.
Sessões, temos sessões multi-site, ASP.NET para ASP.NET Core o compartilhamento de sessão está chegando. ASP.NET e ASP de vários sites.NET Core sessões estão disponíveis. Exibir estado, cache de saída. Redis só tem sessões, o que é muito básico em comparação com NCache. Bloqueio de sessão, compartilhamento de sessão faz parte NCache. O cache de saída é suportado em ambas as extremidades e, adicionalmente, temos SignalR Backplane, ASP.NET Core cache de resposta. Portanto, tudo isso faz um conjunto completo de recursos para seus requisitos de cache específicos da Web. Assim, você pode revisar o conjunto de recursos em detalhes.
Compartilhamento de dados de tempo de execução com eventos
E então temos as mensagens do Pub/Sub.
Temos eventos de nível de item e também temos um sistema de notificação de eventos baseado em critérios, que é muito mais superior em comparação com Redis. Tenho um webinar separado sobre nossas mensagens do Pub/Sub. Então, eu recomendo que você revise isso se houver alguma dúvida. Então, acho que vou concluir neste ponto.
Integrações de terceiros
Por fim, integrações de terceiros.
Temos NHibernate e Entity Framework também. AppFabric invólucro está disponível. Memcached invólucro está disponível. Portanto, se você estiver fazendo a transição desses produtos, poderá fazer a transição sem problemas para NCache em comparação a Redis.
Segurança e criptografia
Alguns detalhes sobre criptografia de segurança e acho que já estamos no marcador de tempo.
Conclusão
Então, é um bom momento para concluí-lo. Então, a primeira coisa é que a qualquer hora vocês, a hora que quiserem, vocês podem acessar www.alachisoft.com e você pode baixar uma versão corporativa do NCache e mostraremos pessoalmente como funciona em seu ambiente. Então, encorajamos você a ir direto ao site, obter a avaliação gratuita de 30 dias da empresa. Agendar uma demonstração será um prazer. Além disso, teremos uma gravação deste webinar disponível para você. Portanto, fique de olho em seus e-mails e nas mídias sociais quando divulgarmos isso a você. Se não respondemos às suas perguntas hoje e sei que teremos muito mais por vir e estamos no limite, por favor, envie um e-mail support@alachisoft.com.
Se você tiver alguma dúvida técnica, teremos uma resposta para você e se você estiver interessado em seguir em frente e se candidatar NCache em seu ambiente só você pode entrar em contato sales@alachisoft.com tão bem.