¿Cómo escalar las aplicaciones de EF Core a un rendimiento extremo?
Seminario web grabado
Por Ron Hussain y Zack Khan
EF Core se usa cada vez más en aplicaciones de servidor .NET de alta transacción (ASP.NET, servicios web, microservicios y otras aplicaciones de servidor). Y estas aplicaciones enfrentan cuellos de botella de escalabilidad de las bases de datos que pueden eliminar mediante el uso de almacenamiento en caché distribuido dentro de EF Core.
- Introducción a las nuevas características de EF Core (Modelo, Consulta, Guardar datos)
- Cómo la caché distribuida resuelve los cuellos de botella de la base de datos de EF Core
- Varias formas de usar el almacenamiento en caché distribuido en aplicaciones EF Core
- Detalles sobre el uso de los métodos de extensión de EF Core para el almacenamiento en caché
- Manejo del almacenamiento en caché de colecciones y relaciones de datos
Entity Framework Core o EF Core es el nuevo motor de asignación relacional de objetos liviano y multiplataforma de Microsoft para .NET que elimina la necesidad de la mayor parte del código de acceso a datos que los desarrolladores escriben de otro modo. Similar a .NET Core, EF Core también es multiplataforma, lo que significa que puede usarlo en Windows, Linux, Mac y se está volviendo muy popular dentro de la comunidad de desarrolladores.
¿Cómo escalar su aplicación para lograr un rendimiento extremo y un crecimiento lineal en la capacidad de manejo de solicitudes? Por lo tanto, puede escalar horizontalmente su aplicación, la aplicación Entity Framework Core usando NCache métodos de extensión. Por lo tanto, hemos alineado algunos que puede utilizar. Diferentes escenarios que pintaré y luego, en base a ellos, presentaré NCache métodos de extensión, así como características de almacenamiento en caché de objetos que puede usar dentro de una aplicación típica de Entity Framework Core en su entorno.
¿Qué es Entity Framework/EF Core?
Primero, hablaría sobre Entity Framework y Entity Framework Core en general. Estoy bastante seguro de que todo el mundo sabe acerca de EF y EF Core, pero solo por el bien de la exhaustividad, para construir algunos detalles introductorios.
Entity Framework es un ORM que puede usar para .NET y con EF Core también puede usarlo para .NET y para .NET Core. Entity Framework simplifica la programación de su base de datos. Puede trabajar en el modelo de objetos conceptuales. Por lo tanto, no tiene que trabajar directamente con el modelo de datos y simplifica la programación general de acceso a datos. No necesita escribir código persistente usted mismo. Podría generar mucha interacción entre su capa de objetos dentro de su aplicación con el modelo de datos que tiene y el uso del acceso a la base de datos generado por Entity Framework Core.
Es muy popular para su .NET y .NET Core aplicaciones Puede usarlo en cualquier tipo de aplicación, ya sea una aplicación web, una aplicación de servidor típica, .NET o .NET Core Los servicios web, el caso de uso de IOT o cualquier otra aplicación de servidor pueden utilizar esto debido a su popularidad y también por su facilidad de uso. Es muy fácil de configurar y puede empezar a utilizarlo.
Entity Framework Core es una nueva variante. Esa es la nueva dirección que está tomando Microsoft, en primer lugar de código abierto, es multiplataforma. Entonces, puede ejecutar una aplicación que esté usando .NET Core o sabes .NET. Puede ejecutarse en Windows con .NET y con .NET Core puede ejecutarse tanto en Windows como en entornos Linux y de manera similar Núcleo del marco de la entidad sigue el juego, ¿verdad? Por lo tanto, le permite ejecutar tanto en Windows como en entornos Linux si ese es un requisito y luego es muy liviano y de naturaleza modular. Lo que esencialmente significa que no tiene que pasar por todos los componentes dentro de Entity Framework que solía tener. El EF Core puedes trabajar con el componente que necesites. Solo puede obtener el paquete NuGet para eso y, en función de eso, puede crear complejidad de manera incremental dentro de su aplicación.
Entonces, si necesita, ya sabe, administrar escenarios complejos dentro de su aplicación. Y, además, es súper rápido debido a .NET Core también hay un enfoque específico o un lado del desempeño. Por lo tanto, Entity Framework Core se diseñó con las mismas pautas en las que el rendimiento es uno de los factores clave que podría lograr.
Diagrama arquitectónico de Entity Framework
Entonces, aquí hay un diagrama arquitectónico para Entity Framework Core.
Encontré un diagrama de Entity Framework que aún se aplica, muchas cosas aún se aplican en la arquitectura Entity Framework Core también. Esto es de MSDN. Con EF Core, tiene el proveedor de datos ADO.NET. Usaré SQL Server como ejemplo de fuente de datos y luego tiene un lector de datos de Entity Client que crea árboles de comando, escenario de acceso a datos y luego tiene servicios de objetos y en el lado de la aplicación trabaja con Entity Consulta SQL o LINQ a Entidades. Entonces, nuevamente trabaja con el modelo de objetos y, detrás de escena, Entity Framework Core se encarga de todos los demás detalles.
Hay un comando que ejecuta para generar su mapeo y modelo en tiempo de ejecución, entonces, el modelo conceptual, EDMX, todos esos archivos de mapeo, se han deshecho de aquellos dentro de Entity Framework Core. Por lo tanto, es muy fácil de configurar de nuevo. Una vez más, es modular. Por lo tanto, puede introducir paquetes NuGet y puede crear una aplicación Entity Framework Core muy simple en cuestión de minutos.
¿Qué es la escalabilidad?
A continuación, hablaré de la escalabilidad, ese es otro concepto que quería resaltar. ¿Por qué necesita el almacenamiento en caché en una aplicación que usa Entity Framework Core? En primer lugar, hay un concepto de escalabilidad. Esa es una característica muy buena dentro de una aplicación, donde puede lograr un alto rendimiento de la aplicación y eso también bajo cargas máximas, ¿verdad? Entonces, si puede tener una latencia baja y la latencia más baja posible y mantiene esa latencia baja con una carga de usuarios baja, digamos de cinco a diez usuarios y si tiene un diseño de arquitectura de aplicaciones de tal manera que pueda administrar la misma tipo de baja latencia bajo una gran cantidad de solicitudes de usuarios, entonces esa aplicación se clasificaría como una aplicación muy escalable.
Y, la escalabilidad lineal es otro concepto asociado en el que puede agregar más y más servidores y puede distribuir su carga y al distribuir la carga en varios servidores, más servidores en realidad aumentarían la capacidad de manejo de solicitudes y ese aumento debería crecer de manera lineal. Por lo tanto, si tiene una aplicación que está aumentando su capacidad a medida que agrega más servidores y que hace un banner de aumento lineal, se clasificaría como una aplicación escalable linealmente.
¿Cuáles son las aplicaciones que necesitan escalabilidad?
Por lo tanto, normalmente las aplicaciones que son de naturaleza transaccional como ASP.NET o ASP.NET Core aplicaciones web, servicios web, IOT, aplicaciones de big data o cualquier otro .NET general o .NET Core Las aplicaciones que utilizan el núcleo de Entity Framework exigen una alta escalabilidad, ¿verdad? Por lo tanto, necesitan una alta carga transaccional de capacidad de manejo dentro de su arquitectura.
¿Dónde está exactamente el problema de escalabilidad?
Entonces, ¿dónde está exactamente el problema? ¿Por qué necesita un sistema de almacenamiento en caché para superar ese problema? Siempre puede crear una Granja web y una Granja de aplicaciones donde la aplicación Entity Framework Core puede escalar linealmente sobre sí misma mediante la creación de una Granja web o una Granja de aplicaciones. Puedes poner un balanceador de carga al frente. Entonces, ese no es el principal punto de preocupación. Su nivel de aplicación siempre puede escalar horizontalmente. Así es como un Entity Framework Core y cualquier .NET o .NET Core se diseñan las aplicaciones. Donde puede enrutar solicitudes a múltiples servidores y aún así poder usarlas en combinación entre sí.
El principal problema es su cuello de botella de almacenamiento de datos. Por lo general, si se trata de una base de datos relacional, ese es el ejemplo que estamos usando. Las bases de datos suelen ser una única fuente para todo su almacenamiento de datos. Son muy buenos para el almacenamiento. Eso es algo en lo que son mejores. Pero cuando se trata de manejar una cantidad extrema de cargas de solicitudes, por ejemplo, tiene una gran cantidad de carga de datos transaccionales y de referencia provenientes de sus aplicaciones, la base de datos no está diseñada para manejar esa mayor cantidad de carga de solicitudes. Funcionaría bien con cargas de usuario bajas, pero cuando comienza a consumir capacidad en el lado de la CPU, en el lado de la memoria y luego hay un túnel DBMS donde se enrutan todas las solicitudes. Lo más probable es que su almacenamiento de datos se convierta en un cuello de botella de escalabilidad. Le daría una degradación del rendimiento, donde pondría en cola las solicitudes que se generan en tiempo de ejecución. Por lo tanto, no hay forma de que pueda agregar otro servidor de base de datos.
En primer lugar, es costoso comenzar y luego no hay forma de que pueda usar dos servidores en combinación entre sí. Por lo tanto, no se sumaría al valor de rendimiento, degradaría su rendimiento y eso también afectaría su experiencia de usuario final y, a su vez, también podría afectar su negocio. Porque, si sus aplicaciones tienen un rendimiento lento, a muchos usuarios no les gustaría ese comportamiento lento o lento de su aplicación. Por lo tanto, las aplicaciones necesitan baja latencia y alto rendimiento todo el tiempo y mantener un alto rendimiento conlleva una pérdida de rendimiento y eso es lo que las bases de datos tienden a ver donde simplemente ralentizan sus aplicaciones o tienden a ahogarse por completo en la mayoría de los casos también.
La Solución
En esta sección hablaremos sobre cómo abordar esto. La solución es muy simple. Puedes usar sistema de almacenamiento en caché distribuido por NCache. Es muy rápido porque está en memoria. Es muy escalable porque no es solo una fuente única. Puede tener tantos servidores como necesite, agregados en el clúster de caché y esos servidores en un clúster de caché funcionan en combinación entre sí. Puede distribuir sus datos y luego puede distribuir la carga de manejo de solicitudes y, al agregar más servidores, también logra más escalabilidad fuera del sistema. No es un reemplazo de sus bases de datos relacionales convencionales. Utiliza una caché distribuida dentro de su aplicación EF Core en combinación con una base de datos. Por lo tanto, almacena en caché los datos a los que se accede más fácilmente, sus datos de referencia, o también almacena en caché algunos de sus datos transaccionales.
Y hablaré sobre cómo manejar diferentes escenarios de almacenamiento en caché, estrategias de almacenamiento en caché que puede utilizar dentro de su aplicación.
Arquitectura de implementación
Esta es la arquitectura de implementación que aclararía aún más algunas cosas por las que es una mejor opción en comparación con las bases de datos relacionales.
En primer lugar, la caché distribuida se encuentra entre su aplicación y el nivel de la base de datos. Y, al decir que en el medio, esencialmente su aplicación primero usaría el caché si encuentra datos aquí, debería regresar si no encuentra datos aquí, solo debería ir a la base de datos de back-end, ¿verdad? Entonces, en una ubicación lógica, se encuentra entre su aplicación y la base de datos.
En lo que respecta a la implementación, puede implementar su aplicación en máquinas virtuales, en cajas físicas, en las instalaciones o en la nube. NCache es compatible con Microsoft Azure, así como con AWS en forma de una imagen preconfigurada o cualquier otra nube. Puede usar nuestro instalador que se puede descargar de nuestro sitio web y luego puede comenzar con la instalación, que es muy fácil de configurar. NCache puede estar en su propio nivel respectivo, servidores dedicados separados para NCache o puede ejecutarse en las mismas cajas. Si tiene cajas donde se implementa su aplicación, puede implementar NCache en el mismo nivel también. Recomendamos tener cajas separadas y puede agregar dos o tres servidores para comenzar y luego puede agregar más y más servidores según sus requisitos de manejo de solicitudes.
Si necesita manejar, digamos, 10,000 usuarios y sus solicitudes asociadas se cargan, puede ejecutar algunas pruebas y puede ver cuántos servidores necesita. En general, según pruebas recientes, pudimos lograr dos millones de solicitudes por segundo con solo 4 o 5 NCache servidores, ¿verdad? Por lo tanto, puede ver cuántos servidores necesita para manejar los requisitos de carga de su aplicación. Solo prerrequisito para NCache es .NET o .NET Core. Se ejecuta en Windows, en Windows Nano, así como en servidores Linux. Del mismo modo, sus aplicaciones pueden estar en la plataforma Windows o en la plataforma Linux.
Y también hay algunas potentes funciones de sincronización de bases de datos. Como dije anteriormente, no es un reemplazo de sus bases de datos convencionales. Utiliza su base de datos, se usa junto con su base de datos, ¿verdad? Entonces, algunos datos estarían en caché, pero todos sus datos siempre existirían en su almacén permanente, que es su base de datos relacional. Y hablaré sobre cómo hacer el almacenamiento en caché en un momento.
3 casos de uso de almacenamiento en caché distribuido comúnmente utilizados
Estos son algunos casos de uso comunes. Casos de uso generales para caché distribuida y el más destacado es el almacenamiento en caché de datos de su aplicación. Tenemos Entity Framework Core aquí.
Almacenamiento en caché de datos de aplicaciones
Entonces, el primer caso de uso, que es nuestro caso de uso más común, es nuestro caso de uso de almacenamiento en caché de datos de la aplicación. En esto, normalmente almacena en caché los datos que pertenecen a la base de datos. La motivación aquí es que ahorre costosos viajes a la base de datos tanto como sea posible y los beneficios que obtiene son un alto rendimiento para la recuperación de datos. Debido a que las bases de datos son lentas en comparación con el acceso en memoria, es en memoria, por lo tanto, es súper rápido y luego tiene varios servidores que alojan y atienden su solicitud desde su aplicación. Por lo tanto, obtiene más escalabilidad, más rendimiento del sistema y, al mismo tiempo, mantiene la baja latencia que se otorga para el caché distribuido y, en la mayoría de los casos, también es altamente disponible y confiable según la topología que haya elegido, a diferencia de las bases de datos que pueden no ser replicadas. a través de otros servidores.
Con el almacenamiento en caché de datos de la aplicación, puede almacenar en caché casi cualquier cosa. Puede utilizar API directas. Puede almacenar en caché los objetos de su dominio, colecciones, conjuntos de datos, elementos individuales, resultados, cualquier dato que desee almacenar en caché y necesite esos datos nuevamente, debe considerar usar nuestro almacenamiento en caché de objetos y con Entity Framework Core, nuevamente puede usar API directas o extensión métodos que te mostraré.
Caché de sesiones ASP.NET y SignalR Backplane
Luego, otro caso de uso para NCache es ASP.NET y ASP.NET Core almacenamiento en caché específico. Tenemos nuestra sesión de almacenamiento en caché. Almacenamiento en caché de sesión en ASP.NET Core es a través de IDistributedCache así como a nuestro NCache Proveedor de sesión también. Entonces, esa es la segunda opción y luego tenemos SignalR Backplane. Esa es otra opción que puedes utilizar. Si tiene una aplicación SignalR, puede usar NCache como un plano posterior. Esta es nuevamente una opción sin cambio de código y luego tenemos almacenamiento en caché de respuesta, estado de vista y almacenamiento en caché de salida. Por lo tanto, estas son todas las características que son específicas para ASP.NET y, además de esto, también puede usar el almacenamiento en caché de datos de la aplicación dentro de su aplicación web si es necesario.
Mensajería Pub/Sub y consultas continuas
Y luego, tenemos poderosos mensajes Pub/Sub y eventos de consulta continua o yo diría mensajes y eventos Pub/Sub. Puedes usar NCache como su plataforma de mensajería, donde varias aplicaciones están conectadas y esas aplicaciones pueden comunicarse entre sí mediante nuestra mensajería Pub/Sub. Una aplicación puede publicar mensajes para NCache, que actúa como canal de comunicación. Tiene un concepto de temas y luego estas aplicaciones de suscriptores pueden recibir ese mensaje si están conectadas a ese tema. Por lo tanto, pueden coordinarse entre sí para compartir datos, así como mensajes personalizados si es necesario. Y podemos construir sistemas de redes sociales. Puedes tener un sistema de chat. Puedes tener tablas de clasificación. Puede usarlo en cualquier tipo de industria según sea necesario, donde necesita tener diferentes componentes en su aplicación coordinados entre sí.
Comunicación entre Microservicios
Los microservicios son otro caso de uso, donde necesita tener aplicaciones de microservicios sin servidor, interactuar entre sí y pueden usar NCache para sus necesidades de comunicación y luego también tenemos Eventos de Consulta Continua. Eventos regulares en los que se agregan, actualizan o eliminan sus datos. En lugar de que la aplicación envíe eventos, NCache puede enviar eventos a sus aplicaciones en función de los cambios de datos y esto podría ser en todos los elementos o en elementos selectivos o en función de la consulta continua donde mapea un conjunto de datos en NCache y NCache solo envía eventos para ese conjunto de datos especificado.
También hay un cuarto caso de uso. Tenemos la función de búsqueda de texto completo. Es muy común en las aplicaciones de comercio electrónico. Con NCache hemos implementado la API Lucene .NET. Entonces, si está interesado en la función de búsqueda de texto completo, NCache viene totalmente equipado con eso también.
Almacenamiento en caché de datos de aplicaciones en EF Core
Hablemos de cómo usaría el almacenamiento en caché en una aplicación típica de Entity Framework Core.
Configuración de la aplicación de muestra
Entonces, antes que nada, tengo esta aplicación. Solicitud de muestra alineada aquí. Es una de las muestras que vienen instaladas con NCache también. Entonces, si vas a C:\Program Files\NCache\, estas muestras están disponibles aquí.
.NET y .NET Core las muestras se colocan por separado. Entonces, yo seguiría adelante con .NET Core y Entry Framework, tenemos una muestra de EF Core aquí mismo. Entonces, esa es la muestra que estoy usando.
Lo he cambiado un poco para demostrar algunos de estos escenarios que planeo presentar en este seminario web. De lo contrario, hace el trabajo básico para su POC. Correcto, entonces, esta es la muestra. Lo siguiente que haría sería iniciar sesión en nuestro entorno de demostración y comenzaría creando un clúster de caché para usted para que realmente use un clúster de caché y lo tome desde allí.
Crear una caché en clúster
Entonces, para la creación de caché, tenemos nuestra herramienta de administración web en funcionamiento. Voy a crear uno rápidamente. Entonces, sigamos adelante y agreguemos un caché agrupado. Llamémoslo democache. Voy a agregar algunos números enteros, democache111. Por cierto, puede mantener el formato JSON o binario, en lo que respecta a la serialización. Ahí tienes Por lo tanto, puede tener formato de serialización binario o JSON. Seguiré adelante con Binary, porque esa es la opción predeterminada. Hay cuatro topologías de almacenamiento en caché entre las que puede elegir y tenemos otros seminarios web como NCache arquitectura que están específicamente dirigidas a, ya sabes, explicar NCache arquitectura. Por lo tanto, voy a continuar con la caché de réplica dividida porque funciona muy bien para lecturas, muy bien para escrituras y es muy escalable para la capacidad de solicitud de lectura y escritura, si continúa agregando más servidores y viene equipado con réplicas también. , por lo tanto, tampoco hay tiempo de inactividad ni pérdida de datos para su aplicación.
Entonces, mantendría todo simple, por defecto. Replicación asíncrona entre la partición activa y su copia de seguridad. Entonces, voy a elegir eso, es más rápido. Tamaño del clúster de caché y aquí especifiqué los servidores que alojarán mi clúster de caché. Como dije, voy a crear rápidamente un caché porque nuestro enfoque principal es Entity Framework Core. De lo contrario, en nuestros seminarios web regulares NCache arquitectura o escalar aplicaciones de Azure con NCache, esos seminarios web hablaron sobre todas estas características con gran detalle. Entonces, en este seminario web en particular, voy a seguir adelante y crear un caché rápidamente. Correcto, entonces, especificaría el puerto predeterminado TCP/IP e iniciaría e iniciaría automáticamente este caché para que se inicie automáticamente cuando su servidor se reinicie. Entonces, eso es todo.
Simule estrés y monitoree estadísticas de caché
En lo que respecta a las configuraciones de caché, solo necesita seguir este asistente y eso crearía un caché en varios servidores. Creo que también empezó. Abriría la ventana de estadísticas y luego abriría NCache ventana de monitor que es otra herramienta que viene instalada con NCache. Actualmente no hay actividad, pero puedo continuar y ejecutar una aplicación de herramienta de prueba de esfuerzo. Se llama herramienta de estrés de prueba y simularía alguna actividad ficticia, carga ficticia en mi clúster de caché. Solo para comprobar que todo, se ha configurado correctamente. Correcto, puede ver, ya sabe, de mil a mil quinientas solicitudes por segundo tanto del servidor uno como del servidor dos. Entonces, en total maneja unas tres mil solicitudes por segundo y puedes revisar la latencia. Tenemos una latencia promedio mínima de microsegundos por operación de caché. Creo que está entre cuatro y cinco microsegundos.
Entonces, este gráfico se actualizaría y la unidad bajaría. Una vez que, ya sabes, añadir un poco más de carga. Sigamos adelante y hagamos eso. Derecha. Entonces, tengo otra instancia ejecutándose. Solo para mostrarle que ahora debería mostrar el valor aumentado aquí, ahí lo tiene. Entonces, tenemos aproximadamente, anteriormente estaba manejando alrededor de mil quinientas misiones por segundo por cada servidor. Ahora está en algún lugar entre dos mil y tres mil solicitudes por segundo por cada servidor y puede ver que el promedio de microsegundos por operación de caché es de alrededor de cincuenta a sesenta microsegundos por operación. Esa es una gran ganancia de rendimiento. Teniendo en cuenta que sus aplicaciones no se están maximizando o los servidores no se están maximizando en absoluto. Por lo tanto, puede esperar respuestas de submilisegundos o microsegundos de sus aplicaciones cuando usa NCache. Entonces, nuestro entorno está configurado. Todo está configurado. Creo que estamos listos para irnos. Permítanme detener estas pruebas y sigamos adelante y creemos, revisemos nuestra aplicación de muestra que habla sobre escenarios de almacenamiento en caché.
¿Qué entidades principales de EF almacenar en caché?
En primer lugar, hablemos de cómo realizar el almacenamiento en caché dentro de Entity Framework Core. ¿Qué entidades de EF Core almacenar en caché? Tienes dos opciones, por lo general. Puede tener una sola entidad o tener un resultado de consulta, que es una colección de entidades, ¿verdad? Entidad única devuelta o podría ser una colección. La entidad única se almacena tal cual. La colección se puede almacenar como un solo elemento o cada elemento de la colección también se puede agregar individualmente en el caché y hablemos sobre cómo hacerlo.
Opciones de almacenamiento en caché de entidad central de EF
Directo NCache API. Hay dos enfoques. En primer lugar, puede utilizar NCache API directamente, ¿verdad? Entonces, eso es algo que también puede usar en Open Source, Enterprise o Professional. Y luego tenemos Entity Framework Core Extension Methods en los que pasaré un tiempo.
Almacenamiento en caché de una sola entidad de EF Core: NCache API directas
API directas. Aquí hay un detalle de las API directas. Déjame mostrarte esto desde aquí, ¿verdad?
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;
}
}Por lo tanto, normalmente este es su método de obtención de clientes. Si está utilizando API directas, es probable que tenga una identificación de cliente. Entonces, antes que nada, necesita construir una clave de caché, ¿verdad? Entonces, eso es algo que debes hacer como una obligación. porque, dentro NCache todo se almacena en un par de valores clave. Clave es su clave de cadena, para identificar un objeto. Una parte del objeto es el valor real, la propiedad real que desea agregar en el caché. Datos reales que desea almacenar en caché para su aplicación.
Entonces, se me ocurrió esta organización clave, donde tengo cliente como palabra clave y luego ID de cliente y luego proporciono un parámetro de tiempo de ejecución que se me pasa, ¿verdad? Entonces, eso identificaría a este cliente en particular aquí mismo, con la identificación del cliente algo único, ¿verdad? Entonces, eso le permitiría identificar a esos clientes de manera única y luego llamar a la memoria caché. Consiga recuperar elementos de la memoria caché. ¿Derecha? Entonces, antes que nada, si está usando el almacenamiento en caché, debe asegurarse de tener la clave construida y luego verificar primero que los datos estén disponibles en el caché llamando a cache. Get y este identificador de caché es algo eso se devuelve cuando inicializas el caché, ¿verdad?
Entonces, estoy usando este caché aquí mismo, NCache.Inicializar caché. Le permite inicializar el caché y conectarse a él. Si encuentra los artículos en el caché, lo que significa que el cliente no era nulo, simplemente regresa desde aquí. Te ahorras costosos viajes a la base de datos y esa es la principal motivación de usar el sistema de almacenamiento en caché donde NCache tendría sus datos. Por lo tanto, guarda sus costosos viajes a través de la base de datos de back-end. No tienes que ir a la base de datos. Pero, dado que es la primera vez que inicia esta aplicación. Entonces, en ese caso, el caché no tendría los datos.
Entonces, en ese caso, ejecutaría Entity Framework Core, enlace dentro de Entity Framework Core. Devolvería un solo artículo o una colección. Es un escenario de un solo elemento y luego llama a cache.Insert para agregar esto para el uso la próxima vez y devolver al cliente también. Entonces, la próxima vez siempre encontrará estos datos en el caché, siempre que no se cambien o no se sincronicen con los datos. Entonces, ese es nuestro único uso de Entity, Direct API.
Almacenamiento en caché de la colección de entidades principales de EF: NCache API directas
En el caso de las colecciones, las API directas son muy similares.
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;
}
} Tenemos clientes por ciudad. La ciudad de los clientes es un parámetro de tiempo de ejecución. Construiremos una lista de clientes e intentaremos obtener esa lista de colección de NCache cache.Get, obtener una lista de clientes. Si eso no es un retorno nulo desde aquí, si es nulo, debemos recuperarlo de la base de datos back-end y también agregarlo en el caché para el uso la próxima vez. Entonces, así es como es y si desea almacenar estos elementos de clientes individualmente, también puede iterar a esta custList y llamar individualmente a la memoria caché. Inserte proporcionando claves únicas para cada elemento de colección también. Entonces, esa es otra opción que puede utilizar.
Pero verá, primero debe construir una clave, obtener el elemento del caché. Si está allí, realice el manejo nulo y luego, si no está allí, lo obtiene de la base de datos, ejecuta la lógica de datos y luego también lo agrega. Entonces, eso es algo que tienes que hacer con Direct NCache API. Es el caso de uso más común para cualquier almacenamiento en caché de base de datos típico. Para el almacenamiento en caché de datos de la aplicación, esto es lo que normalmente haría.
Almacenamiento en caché de una sola entidad de EF Core: métodos de extensión de EF Core
Pero hay otro enfoque, que es a través de nuestros métodos de extensión y ese es el aspecto principal. Puede almacenar en caché toda la colección como un elemento o volver a almacenar en caché cada elemento de la colección por separado, pero a través de métodos de extensión.
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;
} Aquí está nuestro primer método de extensión que quiero mostrarles. Muy bien, entonces, se llama From Cache pero hace mucha automatización por ti, ¿verdad? Funciona de tal manera que, en primer lugar, te permite construir algunas opciones de almacenamiento en caché, ¿verdad? Entonces, en primer lugar, crea opciones de almacenamiento en caché y uno de los atributos que estoy introduciendo en este punto es Almacenar como. Asi que, NCache le permitiría elegir si es necesario almacenar una colección como un solo elemento, como elementos individuales, elementos de colección. Digamos que había 10 artículos en la colección. Entonces, esos se agregarían como 10 elementos separados en NCache o quieres guardarlo como una colección que está justo aquí, ¿verdad? Entonces, esa es la segunda opción. En este caso, se almacenaría como un elemento en el caché.
Entonces, estoy usando entidades separadas. Entonces, si ejecuto este código aquí, tengo un método de extensión que dice From Cache y si les muestro la definición de esto viene NCache Alachisoft .NCache.EntityFrameworkCore. Ese es el espacio de nombres principal y vengo aquí y les muestro los paquetes NuGet. En Instalado tenemos Alachisoft .NCachePaquete .EFCore NuGet. Entonces, ese es el paquete NuGet que debe presentar y luego puede comenzar con estos métodos de extensión. En primer lugar, es una clave de caché de referencia externa, por lo que la clave de caché será generada por NCache y dado a ti. Entonces, esa es la flexibilidad y luego solo toma las opciones como parámetro, correcto. Entonces, hace mucha automatización y detrás de escena está haciendo mucho trabajo para ti. FromCache funciona de tal manera que primero verifica automáticamente los datos en el caché, ese es el comportamiento, si encuentra, no va a la base de datos.
Pero, si no está en el caché y luego iría a la base de datos como regla y ejecutaría la consulta, recuperaría el conjunto de resultados y luego lo agregaría en el caché utilizando esta clave de caché que se completa y luego estas opciones de almacenamiento en caché configuradas para ese elemento . Entonces, si lo compara con este, no tiene que construir la clave de caché. No es necesario que verifique el manejo de nulos o la obtención del caché usted mismo. No tienes que insertarlo en el caché. Solo necesita usar este método de extensión. Entonces, eso hace que muchas cosas sean automatizadas y su modelo de programación muy simplificado también para sus aplicaciones.
Almacenamiento en caché de la colección de entidades de EF Core: métodos de extensión de EF Core
Y, en el mismo caso en el que le gustaría almacenarlo como una colección, simplemente proporciona las opciones de almacenamiento en caché para que sea una colección y, en este caso, tiene una lista de clientes que devolvería. Entonces, solo ejecuta la consulta y luego vuelve a llamar a FromCache. Entonces, eso completa nuestro primer método de extensión y la introducción a él.
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;
} ¿Qué datos almacenar en caché en EF Core?
A continuación, hablaré sobre los datos de referencia y transaccionales. Este es el segmento principal.
Estaría tratando con aplicaciones que tienen muchas lecturas, datos con muchas lecturas que escrituras y luego podría haber escenarios de aplicaciones en los que tenemos lecturas y escrituras, ¿verdad? Entonces, por ejemplo, busque productos de datos, empleados, que no cambian con tanta frecuencia pero no son datos estáticos, es algo que cambia pero la frecuencia de cambio no es tan grande y los datos completos deberían existir en el caché. En este escenario en particular, explicaré por qué y debería expirar después de algunas horas o días. Así es como mantener el caché actualizado, ese es otro segmento.
Luego tenemos datos transaccionales. Hablaré sobre cómo manejar el almacenamiento en caché de datos transaccionales. Se crea dinámicamente. Órdenes, cuentas, esos son ejemplos. Cambia con mucha frecuencia y, por lo general, históricamente no se preferían los datos transaccionales para el almacenamiento en caché. Debido a que se suponía que debía cambiar y desaparecer de su aplicación mientras su usuario está activo, solo se necesita en ese momento. Pero según nuestra experiencia, le recomendamos encarecidamente que también habilite el almacenamiento en caché para los datos transaccionales. Porque, si bien no lo está cambiando, esos datos aún están activos, puede leerlos muchas veces y si tiene millones de usuarios conectados, eso daría como resultado millones de solicitudes para que esos datos regresen a la base de datos y si está en caché e incluso podría ser de dos a tres solicitudes mientras va a cambiar, seguirá siendo beneficioso desde el punto de vista del rendimiento. Por lo tanto, le recomendamos encarecidamente que considere almacenar en caché algunas de sus transacciones, si no todas.
Almacenamiento en caché de datos de referencia en EF Core
Muy bien, ¿cómo manejar el almacenamiento en caché de datos de referencia en EF Core?
Tengo un proceso de dos pasos para esto. Puede cargar datos completos en el caché, eso es imprescindible. Por lo tanto, todos sus datos de referencia deben cargarse en el caché, eso es lo que recomendamos como imprescindible. ¿Por qué? Porque no quieres ir a la base de datos en absoluto, ¿verdad? Debe continuar y comenzar a cargar todos sus datos de la base de datos en NCache y tenemos un método de extensión que se encargaría de esto de inmediato y luego solo usaría el caché y evitaría los viajes de la base de datos.
El paso dos es siempre almacenar en caché como entidades separadas. Ese es otro consejo que te daría que no deberías cachear todos los productos o cualquier otro, todos los productos como una colección, ¿no? Podrían ser miles de productos o millones de productos. Pero almacenarlos individualmente le permitiría obtener subconjuntos de los datos en una etapa posterior, ¿verdad? Entonces, por ejemplo, carga todos los productos, pero en un momento posterior desde el caché solo necesita productos descontinuados. Entonces, si los has almacenado individualmente en el caché, digamos, sesenta mil productos, ese es el ejemplo que te mostraré. Solo puede encontrar los que necesita en ese momento. Por lo tanto, no necesita lidiar con todo el conjunto de datos del producto y, nuevamente, ahorrar costosos viajes a la base de datos.
Almacenamiento en caché de datos de referencia en EF Core: caché de carga previaEntonces, tenemos un método de extensión llamado LoadIntoCache, eso es lo siguiente que les mostraré y también les mostraré un ejemplo práctico de esto.
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();
}
Ahora, LoadIntoCache, en primer lugar, las opciones de almacenamiento en caché deben configurarse como 'almacenar como entidades separadas' y luego debe ejecutar una consulta que debe cargar todos los productos y luego debe llamar a LoadIntoCache y luego proporcionar las opciones y nuevamente solo crearía claves de caché para todos ellos individualmente, automáticamente. Y seguiría cargando todos esos elementos en el caché y luego puede ejecutar consultas LINQ como esta y esta consulta LINQ está en contra NCache. No está usando ningún método de extensión. Está llamando producto en productos de base de datos donde producto. Descontinuado y solo tenemos FromCache. No va a la base de datos en absoluto. lo está obteniendo de NCache .
Almacenamiento en caché de datos de referencia en EF Core: buscar datos de referencia solo en cachéSi tiene datos de referencia, primero debe cargar entidades separadas. Use cargar en caché para cargar todos los productos en NCache. Una vez que haya hecho eso, no tiene que ir a la base de datos. Luego usa FromCacheOnly en lugar de FromCache. El primer método de extensión fue FromCache, que verifica el caché y luego va a la base de datos si no está en el caché. Pero, LoadIntoCache cargaría todos los productos y luego FromCacheOnly se aseguraría de que solo se comunique con el caché asumiendo que todos los datos están cargados en el caché.
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;
}Déjame ejecutar este código, para que lo veas en acción. Tengo un caché que está configurado aquí mismo para esta prueba y les voy a mostrar estadísticas. He estado jugando con eso. Se cargan 60,000 productos. Entonces, permítanme seguir adelante y borrar el contenido. Bien, entonces, revisemos las estadísticas. ¿Dónde está mi caché? Ahí tienes Correcto, entonces, son cero elementos y luego continuaré y ejecutaré esto. Simplemente almacenaría en caché el elemento único, luego recopilaría todos los ejemplos de código que le he mostrado, pero me gustaría mostrarle cómo funciona LoadIntoCache y, en base a eso, también pondré un punto de interrupción allí, ahí lo tiene.
Entonces, los primeros dos ejemplos cargaron un solo elemento y luego cargaron una colección, el código inicial que les mostré y luego esto aquí está cargando todos los productos para mostrarle el escenario de datos de referencia. En primer lugar, se almacena como entidades separadas y se establecen algunas prioridades, algunas dependencias, es elaborado en términos de eso y luego continuará y cargará todos los productos, los obtendrá de la base de datos y le recomiendo que siga ejecutando cargar el producto, cargado en caché después de algunos intervalos, por lo que tener datos recuperados de la base de datos y cargar en caché siempre funciona contra la base de datos. Siempre irá a la base de datos y lo que sea que tenga en la base de datos, se ejecutará contra la base de datos y recuperará esos datos. NCache y luego use FromCacheOnly después.
Entonces, así es como se manejan los datos de referencia. En primer lugar, los almacena individualmente, por separado. LoadIntoCache, utilizando este método de extensión LoadIntoCache, que siempre se ejecuta contra la base de datos. No tiene caché como prioridad. Siempre se ejecutaría contra la base de datos y luego traería todo de vuelta a NCache y luego use FromCacheOnly. Así de sencillo es.
Almacenamiento en caché de datos transaccionales en EF Core
Datos transaccionales. Solo puede cargar el conjunto de trabajo. Es para el almacenamiento en caché del conjunto de resultados, ¿verdad?
Personalmente, recomiendo que si está interesado en clientes por ciudad, pedidos basados en un producto, debe tener algún tipo de almacenamiento en caché del conjunto de resultados y eso es lo que debe hacer. Debe almacenarlos como una colección o entidades separadas según el tamaño de los resultados, es decir, si una colección no es tan grande, digamos que se trata de 100 o 200 elementos como máximo, guárdelos como una colección, y pero si hay son múltiples productos, múltiples pedidos o información de clientes, que se clasificarían como datos transaccionales. Guárdelos como una entidad separada. Entonces, puede obtener un subconjunto de eso y puede maximizar su uso del almacenamiento en caché.
Almacenamiento en caché de datos transaccionales en EF Core - Recuperar y almacenar en caché como colecciónEl caso de uso para esto es muy simple nuevamente. Simplemente lo almacena como una colección o usa FromCache, no usa FromCacheOnly porque le gustaría ir a la base de datos si no está en el caché.
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;
}Hasta ahora, hemos introducido tres métodos de extensión. FromCache, que funciona con el caché y la base de datos automáticamente y no en el caché, lo obtendría de la base de datos. LoadIntoCache siempre se ejecutaría contra la base de datos. Obtenga objetos y llévelos a la memoria caché y FromCacheOnly siempre ejecutándose contra la memoria caché y esa es la única fuente verdadera de datos. No iría a la base de datos. Entonces, espero que eso aclare muchas cosas.
Mantener el caché actualizado
El siguiente segmento se basa en cómo mantener el caché actualizado en Entity Framework Core y ese es otro concepto importante que deben comprender cuando se trata de dos fuentes diferentes.
Tienes el almacenamiento en caché habilitado. Tiene una base de datos de back-end que es su principal fuente de datos, un almacén de datos persistente y luego tiene un almacenamiento en caché que también tiene una copia de los datos. Entonces, cómo asegurarse de que el caché esté actualizado en comparación con la base de datos. Entonces, pasemos un tiempo aquí.
Mantener la memoria caché actualizada: datos de referencia
En primer lugar, debe, ya que tiene un conjunto de datos completo en el caché, ¿qué sucede si hay un cambio en la base de datos, verdad?
Por lo tanto, debe hacer caducar los datos del caché y para eso le recomendamos que use la caducidad y luego la recarga automática de datos, podría ser una opción. Por lo tanto, la primera estrategia es usar la caducidad pero sin recargar. Entonces, cada vez que caducan los datos, también se recargan automáticamente en el caché y para eso tenemos esta configuración aquí, Cargar todos los productos.
Estrategia 1: Usar caducidad pero con 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();
}Déjame mostrarte esto desde aquí, a la derecha. Entonces, antes que nada, los almacena como entidades separadas porque ese es el caso de uso de datos de referencia. Los carga como todos los productos y luego configura algún tipo de vencimiento y luego options.SetResyncProvider, debe haber un proveedor de recarga y luego configure options.IsSyncEnabled a verdadero. Entonces, recarga automática, para que se recargue automáticamente en el caché en caso de que caduque, correcto. Por lo tanto, estas son las dos propiedades junto con, si SetResyncProviderName establecería automáticamente el indicador de recarga automática en verdadero.
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();
}
}
}Y luego necesita ResyncProvider aquí mismo, es decir, nuestra implementación de muestra está justo aquí que estoy mostrando.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}Ahí tienes Debe implementar nuestro IReadThruProvider. Inicialice su fuente de datos, deséchela al final y luego LoadFromSource le permite obtener la clave y, en función de esa clave, construye un comando SQL y obtiene los elementos de la base de datos y he proporcionado una implementación de muestra aquí donde construimos un Consulta SQL de la clave de caché que tenemos.
Correcto, entonces, esa clave, en esta implementación de muestra, también está disponible en GitHub. Por lo tanto, funcionará de tal manera que sus elementos que están cargados en el caché, si ejecuto la carga en el caché una vez más, tendrían un vencimiento adjunto. Por lo tanto, caducarían después de cinco a diez horas, cualquiera que sea el período de vencimiento y después de eso, este proveedor se activaría y llamaría a LoadFromSource usando el controlador de lectura automáticamente y los datos actualizados se traerían a NCache. Correcto, por lo que su caché se actualizará automáticamente después de que caduquen los elementos.
Estrategia 2: no use la caducidad, recargue manualmenteEl segundo enfoque que recomiendo personalmente es no usar expresión, recargar manualmente llamando a LoadIntoCache. Y, eso es algo que es muy simple que deberías encontrar con este método LoadIntoCache, si te lo muestro una vez más. Siga llamando a este método después de algunos intervalos y no use ninguna expresión. Deshagámonos de estos.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Entonces, sabe que estos serán los datos de referencia solo válidos para, digamos, una hora, dos horas, cinco días, semana, mes. En base a eso sigue repitiendo esta carga todos los productos. Esto debería llamarse después de algunos intervalos, ¿verdad?
Entonces, esa es la idea de que debe recargar los datos manualmente en función de una suposición inteligente realizada en el intervalo de vencimiento, ¿verdad? Por lo tanto, debe establecer un tiempo de trabajo establecido, después del cual debe llamar automáticamente a cargar todos los productos. Entonces, obtiene automáticamente los datos de la base de datos back-end y sus datos de referencia se mantienen actualizados.
Por lo tanto, voy a reiterar estos. Entonces, hay dos opciones. Si está utilizando datos de caducidad, se eliminarán de la memoria caché. Por lo tanto, terminaría con conjuntos parciales, por lo que necesita una recarga automática como una obligación. Pero, si no usa la caducidad, tendría todos los datos en el caché todo el tiempo como datos de referencia y luego puede volver a cargar manualmente esos datos después de ciertos intervalos. Espero que eso aclare.
Mantenga la memoria caché actualizada: datos transaccionales
A continuación, hablaría sobre mantener la memoria caché actualizada para los datos transaccionales y eso es bastante simple. Siempre debe usar caducidad corta sin recarga automática. Porque, nuevamente, se trata de datos de corta duración que pueden ser válidos solo de cinco a diez minutos y debe usar FromCache, de modo que si no está en el caché, siempre debe obtenerlo de la base de datos de back-end.
Y, aquí hay un ejemplo de ello, donde tenemos pedidos de clientes, almacenarlos como una colección o artículos individuales, depende totalmente de usted. Caducidad corta si es necesario o no use una caducidad, o use la caducidad y luego no use ninguna recarga automática para el caso. Para que se recupere de la base de datos tan pronto como caduque. Personalmente, recomiendo usar una caducidad configurable o crear una caducidad que sepa con certeza que es un tiempo de trabajo para este conjunto de datos. Para que después de eso no sea necesario. Por lo tanto, debería caducar automáticamente y luego, en ese momento, aplicaría un acceso a la base de datos y lo obtendría automáticamente de la base de datos de back-end.
Caducidad corta, sin 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;
}Entonces, hemos cubierto cómo manejar los datos de referencia, así como los datos transaccionales. Luego, también cubrimos cómo mantener el caché actualizado para referencia, así como los datos transaccionales.
Manejo de relaciones en caché
Uno a muchos
Algunas otras cosas que puede encontrar con el almacenamiento en caché. Manejo de relaciones en caché para EF Core. Una vez más, es muy simple. Se admite incluir, por lo que si tiene una región con regiones de base de datos y luego obtiene una región. Territorios junto a ellos, ¿verdad? Por lo tanto, puede llamar a FromCache y almacenará regiones y territorios por separado y formulará una relación entre región y territorios. Entonces, si te muestro, obtienes una región con territorios.
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;
}Ese es un ejemplo aquí mismo. Derecha. Entonces, los detalles de esta región incluyen y luego estamos usando FromCache. Por lo tanto, almacenaremos regiones y territorios de regiones por separado, elementos separados y luego construiremos una dependencia basada en claves. Si las regiones pasan por un cambio, los territorios también serán invalidados y viceversa. Entonces, así es como manejaría las relaciones de uno a uno o de uno a muchos.
Almacenamiento en caché de operaciones agregadas
Las operaciones agregadas también son compatibles. Por lo tanto, puede ejecutar estos métodos de extensión con un primero diferido o predeterminado, FromCache. Puede basarse en Recuento diferido, FromCache. Entonces, los almacenaría como conjunto de resultados, ¿verdad? Por lo tanto, no importa si los almacena como colección o elementos individuales porque esto es solo el resultado de operaciones agregadas. Entonces, esa es otra posibilidad con nuestro Entity Framework.
Almacenamiento en caché de operaciones agregadas: entidades de devolución
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Almacenamiento en caché de operaciones agregadas: valores devueltos
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}Arquitectura de almacenamiento en caché distribuida
Entonces, hacia el final, me gustaría hablar sobre algunos detalles arquitectónicos sobre el almacenamiento en caché distribuido. Por qué deberías considerarlo. Tiene alta disponibilidad, es súper confiable, con replicación. Es un caché con arquitectura peer-to-peer. No hay un único punto de falla. Puede agregar o eliminar cualquier servidor en tiempo de ejecución y los clientes tienen soporte de conmutación por error de conexión integrado. Por lo tanto, es altamente disponible y súper confiable con un 100 % de tiempo de actividad. Viene con muchas topologías de almacenamiento en caché, caché de cliente, replicación WAN, réplicas particionadas y particionadas y puedo hablar específicamente sobre los detalles arquitectónicos si hay alguna pregunta, de lo contrario, en este punto concluye nuestra presentación.
Alta disponibilidad
Topologías de almacenamiento en caché
Caché del cliente (caché cercano)
Replicación WAN de caché
Conclusión
Me gustaría hacer un resumen rápido de esto. En este seminario web, hablamos sobre las opciones de almacenamiento en caché, las API directas y los métodos de extensión del núcleo de Entity Framework. Entonces, tenemos opciones de elegir entre estos. Estábamos más enfocados en Entity Framework Core Extension Methods porque eso es lo que nos gustaría proyectar. Es más fácil de usar. Cómo abordar los datos de referencia y transaccionales. Entonces, hablamos sobre los enfoques de cargar datos completos para datos de referencia y luego usar el enfoque de entidades separadas y luego usar el caché solo para todos los datos que tiene en el caché. Para los datos transaccionales, recomendamos almacenar en caché solo en el conjunto de resultados y luego usar el método de extensión FromCache para que pueda ir a la base de datos si no está en el caché. Y luego, para mantener el caché actualizado, hablamos de que debe usar la caducidad con recarga automática para datos de referencia o no usar la caducidad sino recargar manualmente después de ciertos intervalos y para los datos transaccionales, asegúrese de usar la caducidad, ¿verdad? Eso debería ser una caducidad breve pero sin recarga automática, por lo que puede volver a la base de datos y actualizar su caché en el próximo uso.
Siempre puede comunicarse con nosotros en support@alachisoft.com. Si tiene alguna consulta técnica, también puede comunicarse con nosotros en sales@alachisoft.com. Si desea echar un vistazo al producto, puede descargar NCache Enterprise para una prueba gratuita de 30 días.