Compartir vía


Clasificación de datos (Almacenamiento en caché de AppFabric 1.1)

La selección de los tipos de datos adecuados para almacenar en la caché de su aplicación permite beneficiarse en mayor medida de las características de almacenamiento en caché de Microsoft AppFabric 1.1 para Windows Server. Los datos pueden adoptar muchas formas y residen en diferentes niveles de la aplicación. Un almacenamiento en caché distribuido hace que los diversos tipos de datos sean más fáciles de almacenar y recuperar, a pesar de los límites de límite de servicio y las diferencias de semántica.

La mayoría de las aplicaciones usan un único origen para cualquier instancia de datos. Por ejemplo, los datos almacenados en la base de datos principal de una aplicación requieren niveles elevados de coherencia e integridad y deben tomarse medidas para garantizar que todos los datos son exclusivos. Los datos del nivel intermedio, empleados por la lógica empresarial, son generalmente una copia de los datos de origen y pueden estar organizados con otros datos con el fin de ser útiles en el nivel de presentación. Son estas copias de nivel intermedio las más adecuadas para el almacenamiento en caché.

La comprensión de los distintos tipos de datos ayuda a definir los grados de almacenamiento en caché posibles. Tal como se muestra en la tabla siguiente, hay tres tipos de datos adecuados para el almacenamiento en caché distribuido: referencias, actividades y recursos.

Tipo de datos Patrón de acceso

Referencia

Lectura compartida

Actividad

Escritura exclusiva

Recurso

Compartido, de lectura y escritura simultánea, con accesos por parte de un gran número de transacciones

Datos de referencia

Los datos de referencia son una versión de los datos de origen que raramente se modifica. Pueden ser una copia directa de los datos originales o haberse agregado y transformado a partir de varios orígenes de datos. Los datos de referencia se actualizan periódicamente, normalmente a intervalos configurados o cuando cambian los datos.

Puesto que los datos de referencia no cambian con frecuencia, son un candidato ideal para el almacenamiento en caché. En lugar de consumir los recursos informáticos necesarios para volver a agregar y transformar los datos de referencia cada vez que se solicitan, estos datos pueden guardarse en caché y volver a usarse en futuras solicitudes. El almacenamiento en caché de los datos de referencia de varias aplicaciones o los usuarios puede ayudar, de este modo, a aumentar el rendimiento y la escala de la aplicación.

Las programaciones de vuelo y los catálogos son ejemplos de datos de referencia. Por ejemplo, piense en una aplicación de catálogo que agrega información de productos a través de múltiples orígenes de datos y aplicaciones. La operación más común en los datos de catálogo es la lectura compartida: exploración. La operación de exploración en catálogos procesa iteraciones sobre gran número de datos de productos, los filtra, los personaliza y presenta los seleccionados a un gran número de usuarios.

Debido a que las operaciones de exploración requieren muchos recursos, este tipo de datos de catálogo son ideales para el almacenamiento en caché. Si no se almacenan en la caché, estas operaciones pueden poner innecesariamente a prueba los datos originales y pueden afectar significativamente el tiempo de respuesta y el rendimiento de la aplicación.

El almacenamiento en caché de los datos más cerca de la aplicación puede mejorar el rendimiento y la escalabilidad. Por este motivo, AppFabric ofrece la característica de caché local. Para obtener más información, vea Clientes de caché y caché local (Almacenamiento en caché de AppFabric 1.1).

Datos de actividad

Los datos de actividad se generan como parte de una transacción de negocios mediante la ejecución de una actividad. Los datos se originan como parte de la transacción de negocios. Luego, al finalizar dicha transacción, estos se guardan en el origen de datos como información de registro o historial.

Entre los ejemplos de datos de actividad se incluyen los pedidos de compra, los estados de sesión de las aplicaciones o los carros de compra en línea. Examinemos con más detalle el caso de los datos de un carro de compra de una aplicación de compra en línea. Cada carro de compra es exclusivo de cada sesión de compra en línea y constituye su propia colección de datos individuales. Durante la sesión de compra, el carro se almacena en caché y se actualiza con los productos seleccionados. El carro de la compra es visible y está disponible sólo para la transacción de compra. Una vez finalizada esta, tan pronto como se aplica el pago, el carro de la compra se retira de la caché a una aplicación de orígenes de datos para su procesamiento adicional. En cuanto la aplicación de orígenes de datos ha terminado de procesar la transacción de negocio, la información del carro de la compra se registra con fines de auditoría e historial.

Mientras la sesión de compra permanece activa, se obtiene acceso al carro de la compra para actividades de lectura y escritura, pero nunca son accesos compartidos. El acceso exclusivo a los datos de la actividad hace que estos sean apropiados para el almacenamiento en caché distribuido.

Los requisitos de escala para los datos de actividad de almacenamiento en caché distribuido deben posibilitar la administración de un gran número de recolecciones de datos individuales, así como admitir las operaciones que afecten a estas recolecciones. Para admitir una gran escalabilidad de la aplicación, estas recolecciones de datos deben distribuirse por todo el clúster de caché.

Puesto que las recolecciones de datos no son compartidas, las recolecciones de datos individuales pueden distribuirse por toda la caché distribuida y almacenarse en distintos hosts de caché. Al aumentar dinámicamente la caché distribuida con hosts de caché adicionales, la aplicación dispone de mayor escalabilidad para satisfacer la creciente demanda.

Con las características de Almacenamiento en caché de AppFabric, puede crear una región para cada una de las recolecciones de datos individuales. Las regiones ofrecen un amplio conjunto de operaciones basadas en etiquetas para trabajar con las recolecciones de datos. Para obtener más información, vea Métodos basados en etiquetas.

AppFabric también le permite administrar el estado de la sesión de las aplicaciones web ASP.NET. Para obtener más información, consulte Procedimiento: configuración de proveedores de estado de sesión (XML)

Datos de recursos

Tanto los datos de referencia (lectura compartida) como los de actividades (escritura exclusiva) son ideales para el almacenamiento en caché. Pero no todos los datos de las aplicaciones pueden dividirse en estas dos categorías. También hay datos que se comparten, se leen y escriben simultáneamente y a los cuales una gran cantidad de transacciones obtienen acceso. Dichos datos se conocen como datos de recursos.

Entre los ejemplos de datos de recursos se incluyen las cuentas de usuario y los artículos de subastas. Por ejemplo, pensemos en un artículo de subasta. El artículo de subasta incluye la descripción del artículo y la información de la oferta actual (el importe de la oferta, su autor, etc.). La información sobre la oferta es volátil, única de cada oferta, y recibe accesos simultáneos de un gran número de usuarios para operaciones de lectura y escritura. La lógica empresarial se almacena en caché cerca de los datos del recurso.

Con fines de rastreo, los datos de los recursos se almacenan a menudo en orígenes de datos de procesamiento de transacciones en línea (OLTP) y se almacenan en caché en el nivel de la aplicación, para mejorar el rendimiento y liberar recursos para los orígenes de datos. En el ejemplo de la subasta, el almacenamiento de los datos de las ofertas en un único equipo puede aportar alguna que otra mejora en el rendimiento, pero cuando se trata de subastas a gran escala, una única caché no es suficiente para proporcionar la escalabilidad y la disponibilidad necesarias. Para este propósito, algunos tipos de datos se pueden particionar y replicar en distintas cachés de la caché distribuida. Sin embargo, dado que determinados tipos de datos se comparten y se actualizan simultáneamente, se debe conservar la coherencia de caché en todo el clúster.

Para optimizar la escalabilidad, reparta los datos de recursos tanto como pueda y limite el uso de las regiones. Si usa regiones, coloque los datos en distintas regiones para permitir que se distribuyan por todo el clúster de caché.

AppFabric admite ambas operaciones de concurrencia optimista y pesimista. Para obtener más información, vea Modelos de simultaneidad (Almacenamiento en caché de AppFabric 1.1).

Vea también

Conceptos

Diagrama de la arquitectura física de AppFabric (Almacenamiento en caché de AppFabric 1.1)
Diagrama de la arquitectura lógica de almacenamiento en caché de AppFabric (Almacenamiento en caché de AppFabric 1.1)

  2012-03-05