Classificação de dados (Cache do AppFabric 1.1)

Ao selecionar os tipos adequados de dados para o cache em seu aplicativo, você pode aproveitar o máximo dos recursos de cache do Microsoft AppFabric 1.1 para Windows Server. Os dados podem ter várias formas e residir em diferentes camadas do seu aplicativo. O cache distribuído torna os diversos tipos de dados fáceis de armazenar e recuperar, apesar dos limites de serviço e das diferenças de semântica.

A maioria dos aplicativos usa uma única fonte para qualquer instância de dados. Por exemplo, os dados armazenados em um banco de dados principal do aplicativo requerem um alto grau de consistência e integridade de dados e as etapas são realizadas para garantir que cada parte dos dados seja única. Os dados na camada intermediária e operados pela lógica de negócios são geralmente uma cópia dos dados de origem e podem ser organizados com outras partes dos dados para que sejam úteis na camada de apresentação. São essas cópias de camada intermediária que são apropriadas para o cache.

Noções básicas sobre os vários tipos de dados ajuda a definir os graus de cache possíveis. Como visto na seguinte tabela, há três tipos de dados que são apropriados para o cache distribuído: referência, atividade e recurso.

Tipo de dados	Padrão de acesso
Referência	Leitura compartilhada
Atividade	Gravação exclusiva
Recurso	Compartilhado, simultaneamente lido e gravado em, acessado por um grande número de transações

Dados de referência

Os dados de referência são uma versão dos dados de origem que são alterados raramente. Eles são uma cópia direta dos dados originais ou são agregados e transformados a partir de várias fontes de dados. Os dados de referência são atualizados periodicamente, normalmente em intervalos configurados ou quando os dados são alterados.

Como os dados de referência não são alterados com freqüência, são um candidato ideal para armazenamento em cache. Em vez de usar recursos de computação para agregar novamente e transformar os dados de referência sempre que solicitado, os dados de referência poderão ser salvos no cache e reusados em solicitações subsequentes. Armazenar em cache os dados de referência em vários aplicativos ou usuários dessa maneira pode ajudar a aumentar o dimensionamento e desempenho do aplicativo.

Horários de vôo e catálogos são exemplos de dados de referência. Por exemplo, considere um aplicativo de catálogo que agrega informações de produto em várias fontes de dados e aplicativos. A operação mais comum nos dados de catálogo é uma leitura compartilhada: navegação. Uma operação de navegação em catálogo repete vários dados de produto, filtra, personaliza e apresenta os dados selecionados para um grande número de usuários.

Como as operações de navegação podem exigir muitos recursos, esse tipo de dados de catálogo é ideal para armazenamento em cache. Se não estiverem armazenadas em cache, essas operações poderão lançar a fonte de dados desnecessariamente e afetar de forma significativa o tempo de resposta e a taxa de transferência do aplicativo.

Armazenar em cache os dados mais próximos ao aplicativo pode melhorar significativamente o desempenho e a escalabilidade. Por esse motivo, o AppFabric oferece o recurso de cache local. Para obter mais informações, consulte Clientes de cache e cache local (Cache do AppFabric v1.1)

Dados de atividade

Os dados de atividade serão gerados como parte de uma transação comercial por uma atividade em execução. Os dados originam-se como parte da transação comercial. Assim, no final da transação comercial, os dados são retirados da fonte de dados como informações de log ou histórico.

Exemplos de dados de atividade incluem ordens de compra, estados de sessão do aplicativo ou um carrinho de compras on-line. Considere os dados do carrinho de compras em um aplicativo de compra on-line. Cada carrinho de compras é exclusivo para cada sessão de compra on-line e sua própria coleta de dados individuais. Durante a sessão de compra, carrinho de compras é armazenado em cache e atualizado com os produtos selecionados. O carrinho de compras fica visível e disponível apenas para a transação de compra. No check-out, assim que o pagamento é aplicado, o carrinho de compras é retirado do cache para um aplicativo da fonte de dados para processamento adicional. Depois que a transação comercial é processada pelo aplicativo da fonte de dados, as informações do carrinho de compras são registradas para fins de auditoria e histórico.

Enquanto a sessão de compras está ativa, o carrinho de compra é acessado para atividades de leitura e gravação, mas não é compartilhado. O acesso exclusivo aos dados da atividade o torna apropriado para o cache distribuído.

Os requisitos de dimensão dos dados de atividade de armazenamento em cache distribuído são poder manipular diversas coletas de dados individuais e também oferecer suporte a operações que afetam essas coletas. Para oferecer suporte à escalabilidade do aplicativo, essas coletas de dados devem ser distribuídas no cluster de cache.

Como as coletas de dados não são compartilhadas, as coletas individuais de dados podem ser distribuídas entre o cache distribuído e armazenadas em hosts de cache separados. Ao aumentar dinamicamente o cache distribuído com hosts de cache adicionais, o aplicativo pode ser dimensionado para atender à crescente demanda.

Com os recursos de Cache do AppFabric, você pode criar uma região para cada uma das suas coletas de dados individuais. As regiões oferecem um conjunto rico de operações baseadas em marcas para trabalhar com suas coletas de dados. Para obter mais informações, consulte Métodos baseados em marca.

O AppFabric também permite que você gerencie o estado da sessão em aplicativos da Web ASP.NET. Para obter mais informações, consulte Como: Configurar um provedor de estado da sessão (XML)

Dados de recurso

Os dados de referência (leitura compartilhada) e atividade (gravação exclusiva) são ideais para armazenar em cache. Mas nem todos os dados de aplicativo estão nessas duas categorias. Também há dados que são compartilhados, simultaneamente lidos e gravados e acessados por muitas transações. Esses dados são conhecidos como dados de recurso.

Exemplos de dados de recursos incluem contas de usuário e itens de leilão. Por exemplo, considere um item de leilão. O item de leilão inclui a descrição do item e as informações de apostas atuais (como aposta atual, quem aposta, etc.). As informações de apostas são voláteis, exclusivas para cada aposta e acessadas simultaneamente por um grande número de usuários para operações de leitura e gravação. A lógica de negócios é armazenada em cache perto dos dados de recurso.

Para fins de acompanhamento, os dados de recurso geralmente são armazenados em fontes de dados OLTP (transação online) e armazenados em cache na camada do aplicativo para melhorar o desempenho e liberar recursos de computação para a(s) fonte(s) de dados. No exemplo do leilão, armazenar em cache os dados da oferta em um único computador pode fornecer alguns aprimoramentos de desempenho, mas para leilões de grande escala, um único cache não pode fornecer a dimensão ou disponibilidade necessária. Para essa finalidade, alguns tipos de dados podem ser particionados e replicados em vários caches no cache distribuído. No entanto, como determinados tipos de dados são compartilhados e atualizados simultaneamente, consistência do cache no cluster deve ser preservada.

Para otimizar a capacidade de expansão, espalhe seus dados de recurso ao máximo e limite o uso de regiões. Se você usar regiões, insira seus dados em várias regiões para permitir que eles sejam distribuídos no cluster de cache.

O AppFabric dá suporte às operações de simultaneidade otimista e pessimista. Para obter mais informações, consulte Modelos de simultaneidade (Cache do AppFabric 1.1).

Consulte também

Conceitos

Diagrama de arquitetura física de cache do AppFabric (Cache do AppFabric 1.1)
Diagrama de arquitetura lógica de cache do AppFabric (Cache do AppFabric 1.1)

  2012-03-05