Redis vs NCache
Seminario web grabado
Por Ron Hussain y Zack Khan
NCache es un caché distribuido nativo de .NET Open Source que es muy popular entre .NET de alta transacción, .NET Core y aplicaciones Java. Redis is developed by Redis Labs y actualmente lo usa Microsoft en Azure. En este seminario web, aprenda cómo NCache y Redis comparar entre sí. El objetivo de este seminario web es hacer que su tarea de comparar los dos productos sea más fácil y rápida, especialmente en aspectos cualitativos como características, rendimiento, escalabilidad, alta disponibilidad, confiabilidad de datos y administración.
Esto es lo que cubre este seminario web:
- Rendimiento y escalabilidad
- Elasticidad de caché (alta disponibilidad)
- Topologías de caché
- SQL y LINQ buscando en la memoria caché
- Integraciones de terceros (EF, EF Core, NHibernate, etc.)
Hoy, tenemos el tema de comparar dos productos que son muy similares pero también diferentes en muchos aspectos. Entonces tenemos NCache que es nuestro principal producto de almacenamiento en caché distribuido para .NET y .NET Core aplicaciones y luego las compararemos desde el punto de vista de las funciones con Redis. Entonces, tenemos mucho que cubrir en esto. Voy a repasar muchos detalles técnicos a partir de la plataforma y la pila de tecnología. Luego hablaremos de la agrupación. Cómo se comparan estos dos productos con respecto al agrupamiento de caché y cuáles son los diferentes beneficios que obtiene al usar estos productos y, en comparación, cómo NCache es mejor y luego voy a hablar de diferentes características. Iremos comparación característica por característica con respecto a los diferentes casos de uso en los que puede usar estos productos y luego cómo estos dos productos se comparan desde el punto de vista de comparación de características.
Para este seminario web, he elegido NCache Enterprise 5.0.2, en la medida en que Redis en lo que respecta, nos centraremos principalmente en Azure Redis. Eso es código abierto Redis 4.0.1.4. Pero, también le daría detalles sobre el Redis proyecto de código abierto, así como, Redis lab que es la variante comercial de Redis. Entonces, compararemos NCache con todos estos sabores, pero nuestro enfoque principal sería Microsoft Azure Redis, el modelo alojado de Redis que puede obtener en Microsoft Azure.
El problema de la escalabilidad
Entonces, antes de comenzar, principalmente voy a repasar los detalles introductorios sobre estos dos productos. Entonces, ¿por qué exactamente necesita una solución de almacenamiento en caché distribuida?
Entonces, y después de eso, continuaría y compararía diferentes productos. Por lo tanto, normalmente es el desafío de la escalabilidad y el rendimiento lo que puede estar experimentando dentro de su aplicación. Podría ser que su aplicación esté recibiendo una gran cantidad de carga de datos y, aunque su nivel de aplicación es muy escalable, siempre puede crear una granja web, puede agregar más recursos en el nivel de la aplicación, pero todas esas instancias de la aplicación deben retroceder y comunicarse. -Fuentes de datos finales. Y, cuando necesita regresar y hablar con esas fuentes de datos, ahí es donde ve problemas de rendimiento porque las bases de datos, generalmente las bases de datos relacionales, son lentas en términos de manejo de la carga transaccional.
Hay un problema de rendimiento asociado con ellos y luego en términos de escalamiento horizontal, por ejemplo, si necesita tener mucha capacidad de manejo de solicitudes o requisitos en torno a eso, necesitamos manejar muchas solicitudes y sus aplicaciones están generando una gran cantidad de carga de usuario, la base de datos no está diseñada para manejar esa carga transaccional extrema. Es muy bueno para el almacenamiento que es donde puede almacenar una gran cantidad de datos, pero tener una carga transaccional en esos datos es algo para lo que la base de datos no sería un buen candidato. Puede ahogarse. Le daría lentitud y la experiencia del usuario final puede degradarse.
Por lo tanto, puede tener un impacto en el rendimiento y no tiene la capacidad de aumentar la capacidad dentro de la arquitectura de la aplicación.
La solución: caché distribuida en memoria (NCache)
La solución es muy simple, utiliza un sistema de almacenamiento en caché distribuido en memoria como NCache que es súper rápido porque está en la memoria. Entonces, en comparación con una base de datos relacional o un sistema de archivos o cualquier otra fuente de datos que no esté basada en la memoria, si proviene de un disco en comparación con el almacenamiento de sus datos en la memoria, en la memoria, lo hará super- rápido. Entonces, el primer beneficio que obtiene es que obtiene un rendimiento súper rápido de NCache.
El segundo beneficio es que es un clúster de caché. No es una sola fuente. Puede comenzar con un servidor, pero por lo general le recomendamos que tenga al menos dos servidores y cree un clúster de caché y, tan pronto como cree ese clúster de caché, mejoraría si solo distribuyéramos la carga en todos los servidores y usted continúa. agregando más servidores en tiempo de ejecución.
Por lo tanto, puede escalar su capacidad, puede, ya sabe, aumentar la capacidad en tiempo de ejecución agregando más servidores y también lo usa en combinación con sus bases de datos relacionales de back-end. No es un reemplazo de sus bases de datos relacionales convencionales y hablaremos sobre algunos casos de uso más adelante.
Implementación de caché distribuida (NCache)
Esta es una implementación típica.
Estoy usando NCache como ejemplo por ahora, pero más adelante en esta presentación compararemos cómo Redis se despliega y cómo NCache se implementa y cuáles son las flexibilidades disponibles dentro de estos productos.
Entonces, para NCache, es muy flexible. Puede optar por implementarlo tanto en Windows como en un entorno Linux. Está disponible en las instalaciones y es compatible con entornos de nube. Está disponible en Azure, así como AWS marketplaces. Entonces, puede obtener una imagen preconfigurada de NCache y empezar con él. Los contenedores Docker para Windows y Linux están disponibles, que puede usar en cualquier plataforma, donde necesite usar esto.
Por lo general, sus aplicaciones, ya sea que estén alojadas en las instalaciones o en la nube, podría ser un servicio de aplicaciones, podría ser un Cloud service, podría ser un microservicio, podría ser un sitio web de Azure, cualquier tipo de aplicación puede conectarse a él en el modelo cliente-servidor y se ubica entre su aplicación y su base de datos back-end y ese es el modelo de uso típico. La idea aquí es que almacenaría datos dentro NCache y, como resultado, ahorraría costosos viajes a la base de datos de back-end. Ahorraría los viajes a la base de datos tanto como sea posible y cada vez que necesite ir a la base de datos, siempre iría a la base de datos, buscaría datos y los traería al caché para que la próxima vez que existan datos y no tenga para ir a la base de datos. Y, como resultado, el rendimiento de sus aplicaciones y la escalabilidad general mejoran porque ahora tiene acceso a la memoria, lo que mejora el rendimiento. Tiene varios servidores que alojan y atienden sus solicitudes, sus solicitudes de datos. Por lo tanto, es más escalable en comparación. Y luego, hay funciones de alta disponibilidad y confiabilidad de datos que también están integradas en NCache protocolo.
NCache se pueden alojar en las mismas cajas, donde se ejecutan sus aplicaciones. O podría ser simplemente un nivel separado. En la nube, el enfoque preferido sería que use un nivel de caché dedicado separado y luego sus aplicaciones, las instancias de la aplicación se ejecutan en su nivel respectivo. Pero, ambos modelos son compatibles en la medida en que NCache está preocupado.
Algunos números de escalabilidad. Recientemente realizamos estas pruebas en nuestro laboratorio de AWS, donde simulamos la carga de solicitudes de lectura y escritura y seguimos aumentando la carga y, después de cierto punto, cuando vimos que los servidores estaban al máximo, aumentamos la cantidad de servidores en el clúster de caché. Entonces, de 2 a 3 servidores y luego de 3 a 4, pudimos lograr un rendimiento de 2 millones de solicitudes por segundo con solo 5 NCache servidores y esto no es, esto no era un dato de toque y listo. Estos eran datos de una aplicación de la vida real pero simulados en nuestro laboratorio de AWS dentro de nuestras aplicaciones. Y, el factor de latencia también fue muy optimizado. Pudimos lograr todo esto con una latencia de microsegundos. Por lo tanto, el rendimiento de las solicitudes individuales no se degradó cuando pudimos lograr toda esta carga.
Casos de uso comunes: caché distribuida
Algunos casos de uso y esto es algo que es común para Redis también pero hablaré de cómo NCache compararía.
Almacenamiento en caché de datos de aplicaciones
Donde almacena en caché casi todo lo que normalmente obtiene de la base de datos de back-end y los datos existen en su base de datos y ahora desea almacenarlos en caché. Entonces, se ahorra costosos viajes a la base de datos y ya hemos establecido que la base de datos es lenta y luego no es muy óptima en términos de manejo de carga de transacciones. Tenemos muchas funciones de sincronización de bases de datos en esta línea, pero aquí simplemente se conecta a NCache y usar básicamente nuestras API para hacer conexiones, ya sabes, hacer cualquier llamada de datos a NCache. Por lo tanto, puede almacenar en caché casi cualquier cosa. Podrían ser sus objetos de dominio, colecciones, conjuntos de datos, imágenes, cualquier tipo de datos relacionados con la aplicación pueden almacenarse en caché utilizando nuestro modelo de almacenamiento en caché de datos.
ASP.NET/ASP.NET Core Almacenamiento en caché
Luego tenemos nuestro ASP.NET y ASP.NET Core almacenamiento en caché específico. Ese es nuevamente un caso de uso técnico, donde puede usarlo para ASP.NET o ASP.NET Core almacenamiento en caché del estado de la sesión. ASP.NET o ASP.NET Core SignalR Backplane. NCache se puede enchufar como backplane. Para ASP.NET Core también puede usarlo para el almacenamiento en caché de respuestas. Interfaz IDistributedCache y sesiones a través de IDistributedCacheIDistributedCache interfaz, estas dos características también son compatibles con NCache y para aplicaciones heredadas, también puede usarlo para Ver estado y Caché de salida. Quería lanzarte una pregunta rápida, Ron.
Entramos, la pregunta es si NCache y Azure admiten un modelo de programación sin servidor?
Absolutamente. Esto es algo que, en términos de implementación de Azure, puede implementar sus aplicaciones en servidores o su aplicación, en lo que respecta a la parte de su aplicación, también podrían ser aplicaciones sin servidor. Simplemente puede incluir nuestros paquetes NuGet dentro de su aplicación y esas aplicaciones pueden hacer NCache llama cada vez que lo necesitan. Ni siquiera tienen que tener ninguna instalación de NCache o tener una configuración de servidor en lo que respecta a los recursos de la aplicación. Pero, en cuanto, NCache la implementación del lado del servidor en sí misma está preocupada porque NCache es la fuente de datos, por lo tanto, debe tener una VM o un conjunto de VM, donde sus aplicaciones se conectan y recuperan y agregan datos.
Entonces, desde los servidores, NCache punto de vista del servidor de caché, como fuente que necesita NCache servidores, pero en lo que respecta a sus aplicaciones, podrían ser estrictamente sin servidor y no hay problemas. Incluso arquitectura de microservicios. Ese es un ejemplo muy común, donde hay microservicios, hay muchos microservicios. Podría haber una función de Azure, que solo se está ejecutando y que maneja una gran cantidad de datos y esos datos pueden provenir de NCache. Entonces, tratas NCache como fuente de datos. Mientras que sus aplicaciones pueden ser sin servidor y NCache es totalmente compatible con ese modelo.
Pub/Sub Mensajería y Eventos
Entonces otro caso de uso está alrededor Mensajes de publicación/suscripción y eso gira en torno a los microservicios porque ese es uno de los casos de uso impresionantes en los que puede usar la mensajería para aplicaciones sin servidor. Los microservicios son aplicaciones sin servidor acopladas libremente y construir una comunicación entre ellos es un gran desafío. Por lo tanto, puede usar nuestra plataforma de mensajería Pub/Sub, donde puede utilizar nuestro mecanismo de propagación de eventos asincrónicos controlado por eventos. Donde varias aplicaciones pueden publicar mensajes para NCache y los suscriptores pueden recibir esos mensajes.
Dado que se basa en un mecanismo asíncrono impulsado por eventos, las aplicaciones de los editores no tienen que esperar el reconocimiento o la entrega de los mensajes y, de manera similar, los suscriptores no tienen que esperar ni recibir mensajes. Reciben notificaciones a través de devoluciones de llamada cuando reciben notificaciones. Entonces, es muy flexible y ese es otro caso de uso en el que puede usar NCache como una plataforma de mensajería Pub/Sub para sus aplicaciones.
NCache Historia
Algunos detalles más y luego hablaremos de las diferencias entre NCache y Redis. NCache fue lanzado en 2005. Ha estado en el mercado por más de 15 años. Versión actual de NCache es 5.0, versión 15. Tenemos montones y montones de clientes. NCache también está disponible en edición Open Source. Que puedes descargar desde nuestra web así como desde el repositorio de GitHub.
Algunas de nuestras NCache Clientes
Algunos de nuestros clientes. También puede obtener una lista detallada.
Plataforma y Tecnología
A continuación hablaremos de cómo NCache se compara con Redis y el primer segmento se basa en algunos detalles introductorios sobre la tecnología en general. Esta va a ser información sobre la tecnología de almacenamiento en caché distribuida. Ahora nos centraremos directamente en cómo NCache se compara con Redis y tengo algunos segmentos que he formulado.
Entonces, la primera sección que definimos es plataforma y tecnología, e inicialmente mencioné que estamos apuntando NCache 5.0.2. Entonces, NCache 5.0 SP2 es la versión principal en NCache sitio y desde Redis desde el punto de vista, usaremos Azure Redis como comparación y también hablaremos sobre Open Source y Redis Laboratorio como parte de eso. La mayoría de estos detalles son comunes para diferentes sabores de Redis.
Caché nativo de .NET
Entonces, viniendo de un fondo de Azure, si planea elegir un producto, lo primero sería la compatibilidad con la plataforma.
¿Entonces NCache en sí está escrito en 100% .NET. Es un .NET nativo o.NET Core producto, en lo que respecta a sus aplicaciones, correcto. Entonces, básicamente, está escrito en .NET y principalmente para aplicaciones .NET y se implementa en Windows Server 2016, 2019 e incluso 2012. Solo se requiere un requisito previo para NCache is .NET framework or .NET Core para esa materia. Considerando que, por Redis, está escrito en C++. NCache está escrito en .NET. Está desarrollado al 100%, en realidad C# es el principal lenguaje de tecnología que estamos usando y es 100% nativo .NET y .NET Core. Mientras Redis es una solución basada en C++ Linux.
Entonces, desde la perspectiva de Windows, el fondo de Windows y si tiene sus aplicaciones escritas en .NET, la elección natural sería usar un producto que también esté escrito en .NET para que esté en la misma pila de tecnología. No tiene que tener muchas variaciones dentro de la pila de desarrollo de aplicaciones. Entonces, ese es un problema o una diferencia entre estos dos productos.
El segundo aspecto es Windows versus Linux y luego sabes lo que está disponible en NCache y lo que está disponible en Redis lado. Windows, desde un punto de vista de NCache implementación, que es una implementación preferida, pero también tenemos una implementación de Linux disponible con la ayuda de nuestro .NET Core Lanzamiento del servidor. Por lo tanto, somos totalmente compatibles con Windows 2012, 2016 y 2019. Nuestras imágenes de Docker también están disponibles para la variante de Windows. una variante de NCache. Entonces, puede simplemente descargar nuestra imagen de Docker y girar la imagen de Windows de NCache según sea necesario y lo apoyamos completamente en el entorno de producción. Es un soporte oficial de nuestra parte. Considerando que, si se compara Redis incluso en Microsoft Azure el Redis está alojado en Linux. El enfoque preferido, el modelo de implementación preferido es Linux para Redis. La variante de Windows es un proyecto de terceros. Microsoft Open Tech tiene una versión portada. No hay apoyo oficial de Redis sí mismo. El proyecto en sí está archivado. Tiene errores, es inestable e incluso el Azure Redis, como se discutió anteriormente, usa la versión de Linux y el gran problema con esto es que no tiene un soporte oficial del Redis, Los fabricantes de Redis o desde un punto de vista, si desea utilizar el proyecto de código abierto y desea implementarlo en sus propias instalaciones, ahí es donde vería muchos problemas.
Como parte de esto, también me gustaría resaltar otro aspecto, si usa NCache on-premise y ahora quiere migrar desde on-premise y le gustaría usar en Azure, el mismo software funciona como está. Por lo tanto, no se necesita ningún cambio al mudarse NCache desde local hasta Azure. Del mismo modo, dentro de los proveedores de la nube, si planea usar NCache en Azure, puede migrar a AWS, si es necesario. Porque exactamente el mismo software está disponible en todos los ámbitos en todas las plataformas. Considerando que, en la medida en que, Redis está preocupado, Azure Redis es un modelo alojado que se implementa en Linux en lo que respecta a la implementación de back-end, pero no tiene la misma variante disponible en las instalaciones. Entonces, tienes que lidiar con el código abierto Redis o algún proveedor externo. Incluso tienes que optar por una variante comercial, que es un producto completamente diferente.
Entonces, el punto principal que me gustaría resaltar aquí es que Redis on-premise que es de código abierto o alguna versión comercial versus Redis en azul o Redis en AWS, que es Elastic Cache. Estos son productos completamente separados. Entonces, hay una transición, hay muchos cambios. no puedes portar Redis de un entorno a otro sin pasar por algunos cambios. Faltan algunos conjuntos de funciones. Algunas API son diferentes. El modelo de implementación cambia completamente entre estos productos. Entonces, no hay cambios si mantienes NCache on-premise en Windows o Linux y ahora quiere migrar e ir a Azure, sería exactamente el mismo producto y ahora quiere cambiarlo de Azure a AWS, quiere cambiar el proveedor de la nube, es más flexible en comparación para Redis. Asi que, NCache es mucho más flexible.
soporte de linux, NCache es totalmente compatible, con soporte oficial. Incluso se prueba el rendimiento y el rendimiento de Linux es súper rápido a la par con NCache en Windows Tenemos imágenes de Docker disponibles. Totalmente respaldado en producción y tenemos herramientas de administración y monitoreo totalmente integradas que puede usar, estas son herramientas de gestión y monitorización web que se puede acceder desde cualquier lugar. Por lo tanto, incluso sus implementaciones de Linux se pueden administrar y monitorear como implementaría, administraría y monitorearía sus implementaciones de Windows con NCache. Linux también es compatible con Redis. Por lo tanto, su soporte de producción disponible por Redis Laboratorio. Azur Redis también está alojado en la versión de Linux. Por lo tanto, es compatible con el propio proveedor.
El segundo aspecto después de la plataforma es nuevamente .NET y .NET Core, la pila de tecnología. Tenemos un Cliente oficial disponible. Lo hemos implementado. Lo apoyamos completamente y si hay algún conjunto de características y es por eso que NCache es compatible en todos los ámbitos. Por lo tanto, si elige entornos locales, Azure o AWS, tendrá el mismo sabor de NCache y su Cliente disponible en todos los ámbitos. Y, si es necesario realizar algún cambio, proporcionaremos esos cambios oficialmente porque somos dueños de todo, así como del proyecto. Considerando que, por Redis es un tercero. Entonces, para diferentes idiomas, el soporte que viene de diferentes idiomas también viene de diferentes proveedores. Por lo tanto, podría haber una diferencia en el conjunto de características. Podría haber una diferencia en el ciclo de lanzamiento. Por lo tanto, debe confiar en los clientes de terceros en lo que respecta a la tecnología en lo que respecta a los requisitos del cliente.
Entonces, quiero resaltar algunos aspectos en torno a NCache siendo nativo .NET y .NET Core producto. NCache es totalmente compatible con Windows, así como con Linux. Mientras, Redis no es muy estable en Windows. Es la versión portada de terceros y el soporte de Linux está disponible y ese es el, por lo tanto, debe confiar en el soporte de Linux en la medida de lo posible. Redis está preocupado Entonces, viniendo de un fondo de tecnología de Microsoft, esto es algo en lo que debe confiar.
Rendimiento y escalabilidad de caché
El segundo aspecto es nuestro rendimiento de caché. Ese también es un aspecto muy importante.
Ambos productos son muy rápidos y esa es la idea aquí, el principal beneficio de NCache y Redis, la razón principal por la que elegiría un producto de este tipo es el aspecto de mejora del rendimiento. Ya hemos establecido que las bases de datos son lentas y no son muy escalables. Estos productos son rápidos y muy escalables en comparación. Entonces, no le quitaría nada Redis. Solo que la versión de Windows no es estable y hay problemas de rendimiento, pero si tiene una versión de Linux, también es muy rápida y escalable y es extremadamente rápida y NCache también es muy rápido. Es muy escalable. Tenemos nuestro propio protocolo de agrupamiento basado en TCP/IP implementado, que está muy optimizado y tiene un rendimiento muy robusto.
Sin embargo, aquí también hay algunas diferencias. Dentro de NCache Tenemos muchas funciones de mejora del rendimiento. Recientemente también realizamos un seminario web, en el que abordamos seis formas diferentes en las que puede mejorar NCache actuación. si configuras NCache de forma predeterminada, le brindará un rendimiento muy bueno, pero además, según sus casos de uso, puede habilitar diferentes funciones y puede mejorar aún más el rendimiento y una de esas funciones es nuestra caché de cliente.
NCache: Caché del cliente (caché cercano)
Client Cache es una función exclusiva de NCache. Redis no tiene esta característica.
Es un caché local del lado del cliente, que nuevamente es posible incluso para aplicaciones sin servidor, donde puede tener una copia InProc dentro del proceso de su aplicación y/o para, ya sabe, aplicaciones basadas en servidor, puede usar un caché de cliente fuera de proceso . La idea aquí es que ahorraría costosos viajes a través de la red a su clúster de caché. Este caché ya estaba guardando viajes a las fuentes de datos de back-end. Ahora puede tener caché en el medio y suponer que tiene 100 elementos en el caché, si alimentó algunos elementos en el lado de la aplicación, ya sabe, digamos 10 elementos, esos 10 elementos se devolverán automáticamente al caché del cliente y la próxima vez su aplicación encontraría esos datos más cerca de su aplicación y, como resultado, ahorraría costosos viajes de red.
Y, este es un caché de cliente sincronizado. La sincronización es gestionada por NCache. Cualquier cambio en el caché del cliente se propaga en la memoria caché del servidor porque esa es la copia maestra. Este es un subconjunto de los datos y ese cambio también se propaga a otros cachés de clientes. Si tiene un escenario de datos de referencia. Si tiene muchas lecturas y luego escrituras, le recomendamos encarecidamente que active la memoria caché del cliente, ya que le ofrecería un rendimiento muy bueno en comparación con una memoria caché que se ejecuta en nuestra base de datos.
Recientemente hicimos una prueba de concepto con uno de nuestros clientes, uno de nuestros clientes más importantes. Donde tenían un flujo de trabajo, que tardaba unos 46 segundos con las configuraciones predeterminadas. Estaban haciendo un montón de NCache llamadas y recuperación de datos. Entonces, fue principalmente un caso de uso intensivo de lectura. Activamos el caché del cliente fuera del proceso, por cierto, hay dos tipos, puede mantenerlo fuera del proceso, lo que significa que se ejecuta un proceso de caché separado en el cuadro de la aplicación o puede tener InProc donde el caché del cliente se ejecuta dentro del proceso de su aplicación. InProc no tiene serialización o proceso para procesar la sobrecarga de comunicación. Entonces, es extremadamente rápido. Incluso en comparación con OutProc es más rápido. Entonces, con ese cliente, el flujo de trabajo tardaba unos 46 segundos en comenzar. Luego activamos el caché del cliente fuera del proceso, lo redujo a 3 o 4 segundos y luego lo volvimos a activar en el caché del cliente InProc y pudimos lograr todo esto en 400 a 500 milisegundos. De 46 segundos a 400 a 500 milisegundos, ese es el tipo de mejora del que estamos hablando y esta función no está disponible en ningún otro producto ni en ningún otro sabor de Redis, incluyendo Redis Labs, incluido el proyecto de código abierto y Azure Redis.
Por lo tanto, puede ajustar el rendimiento utilizando la memoria caché de nuestro cliente y no es un trabajo de cambio de código. Es solo una configuración que enciendes.
Las operaciones masivas se admiten en ambos lados, pero con NCache Es decir, nuestras operaciones masivas funcionan en todo el clúster de caché, lo que significa que si tiene diez servidores y tiene datos completamente distribuidos, una llamada masiva recuperaría los datos de todos esos servidores y se recuperaría el resultado consolidado. Entonces, todos ellos trabajan en combinación entre sí para formular un resultado y luego se obtiene un resultado que es de naturaleza completa. Mientras Redis las operaciones masivas están en un nivel de fragmento. Por lo tanto, debe lidiar con los datos en un fragmento determinado. Entonces, esa es la limitación. Si tiene, digamos varios nodos en el clúster de caché y tiene fragmentos maestros que están disponibles, por lo que podría realizar operaciones masivas en un fragmento determinado.
Entonces, esa es la limitación. De lo contrario, esta es una buena función de mejora del rendimiento en la que, en lugar de ir y venir por solicitudes individuales, envía una gran solicitud y obtiene todos los datos a la vez y, como resultado, prueba su rendimiento.
La serialización, esa es otra característica y hay otro aspecto porque la mayor parte de su tiempo se gastaría en serializar y deserializar datos y eso es cierto para NCache como también para Redis. Por defecto, ambos productos serializarían y deserializarían pero con NCache hay una forma de mejorar la sobrecarga de serialización y deserialización. Contamos con una serialización rápida y compleja, que optimizaría su tiempo de serialización, que normalmente tomaría su aplicación. Tus objetos se vuelven complejos. Entonces, sin ningún cambio de código, puede definirlos como tipos compactos y NCache aseguraría que ejecuta la serialización compacta en ellos en tiempo de ejecución y mejoraría su sobrecarga de serialización y deserialización.
Finalmente, también tenemos la función de compresión. La compresión se realiza en el extremo del cliente. Por lo general, si se trata de objetos más grandes, digamos, 2 MB, 3 MB o digamos 500 kilobytes, ese es un objeto más grande. Por lo tanto, normalmente recomendamos que trabaje con objetos más pequeños, pero si tiene objetos más grandes, hay una gran utilización de la red y luego el rendimiento también se degrada. Con NCache puede activar la compresión. Esa es una opción sin cambio de código, que no está disponible en el Redis lado y comprimiría automáticamente los elementos mientras los agregaba a la memoria caché. Por lo tanto, se agregan objetos más pequeños y se transfieren, viajan entre su aplicación y el caché y, de manera similar, el mismo objeto más pequeño también se recupera en el extremo de la aplicación. Tratar con una carga útil más pequeña mejora el rendimiento de sus aplicaciones. Por lo tanto, el rendimiento general de la aplicación aumentaría si tiene activada la compresión.
Por lo tanto, recomendamos cualquier objeto mayor que, digamos, 100 kilobytes, definitivamente debe activar la compresión y hay un umbral que puede habilitar y solo se comprimen los objetos más grandes, los objetos más pequeños se dejan como están.
Por lo tanto, todas estas funciones de mejora del rendimiento, caché del cliente, operaciones masivas, serialización compacta, compresión, no están disponibles o Redis. Por ejemplo, la memoria caché del cliente no está disponible. Las operaciones masivas están disponibles pero son limitadas. No hay opciones de optimización de serialización y la compresión es algo que no está disponible. Entonces, ahí es donde tienes una clara diferencia entre NCache y Redis, Donde NCache es un paquete completo en el que tenemos muchas características centradas en el rendimiento integradas.
Alta disponibilidad
El siguiente segmento es el de alta disponibilidad y ahí es donde verá una gran diferencia en el conjunto de características entre NCache y Redis. La alta disponibilidad es otro aspecto en el que se pueden comparar estas piezas. Para aplicaciones de misión crítica, este es un aspecto muy importante que necesita una fuente. Ahora está trayendo sus datos que normalmente están en la base de datos y dentro de la base de datos tendría algún tipo de duplicación, algún tipo de respaldo, ¿verdad?
Entonces, con los datos que se mueven en un producto que es caché distribuido, aunque mejora su rendimiento, es muy escalable, pero la alta disponibilidad es un aspecto muy importante. Para aplicaciones de misión crítica, cualquier tiempo de inactividad no es aceptable. Afectaría su negocio y la experiencia del usuario puede verse afectada. Entonces, no es asequible. Por lo tanto, es muy importante que su aplicación siempre pueda obtener una respuesta del caché donde se encuentran los datos. Entonces, aquí tenemos un gran conjunto de diferencias de características.
Clúster de caché
NCache es un clúster de caché con arquitectura 100% peer-to-peer.
Es dinámico y autocurativo y hablaré sobre cómo funciona, pero en comparación Redis utiliza maestro/esclavo. Entonces, ser una arquitectura peer-to-peer NCache le permite agregar y quitar servidores automáticamente y es perfecto para sus aplicaciones. Puede continuar y agregar tantos servidores como necesite. Por ejemplo, ha comenzado con 2 servidores. Ahora que desea agregar un tercer servidor, puede hacerlo sobre la marcha. No tiene que detener el caché o las aplicaciones cliente que están conectadas a ese caché. Se observa una experiencia perfecta. Por lo tanto, sus aplicaciones pueden continuar funcionando sin tener ningún tiempo de inactividad o pérdida de datos con nuestras funciones de alta disponibilidad y confiabilidad de datos. Mientras en Redis no puede agregar fragmentos nuevos automáticamente. Porque no hay reequilibrio automático de datos. Ese es el núcleo de la naturaleza dinámica de nuestro clúster de caché. Dentro de NCache, reequilibra automáticamente los datos si desea agregar nuevos servidores.
Entonces, hay dos escenarios. Uno en el que agrega un nuevo servidor para brindar capacidad, para brindar más escalabilidad y el otro escenario es que derriba un servidor.
Entonces, primero abordemos el escenario del nodo que se está agregando. Se une un nuevo nodo. Con NCache, sus datos se distribuirán automáticamente.
Por ejemplo, de 2 a 3 servidores, si agrega 2 más, tenía 6 elementos aquí y agrega otro servidor al que se transmitirían los datos existentes, se equilibrarán con el servidor recién agregado. Entonces, ese servidor tomaría una parte de los datos de los servidores existentes y eso se hará automáticamente. Es de naturaleza dinámica. Por lo tanto, se produce un reequilibrio automático de datos. Con Redis, es un reequilibrio manual de datos y esto es cierto para Azure Redis porque hay diferentes conjuntos de niveles disponibles en Azure. Hay un básico, hay un nivel medio y hay un avanzado. El agrupamiento solo entra en juego aquí con avanzado, que también es costoso y, además, necesitan al menos un mínimo de 3 servidores, lo que nuevamente es una limitación.
Con NCache incluso puede tener la agrupación en clúster completamente en funcionamiento con solo 2 servidores y, además, agregar un nuevo servidor requiere un reequilibrio manual de datos. Ese es un gran problema. Por lo tanto, tendría algún tipo de limitación en la aplicación y cuando planea agregar capacidad. Considerando que, con NCache puede lograr esto en tiempo de ejecución. Puede agregar más servidores sobre la marcha.
El segundo aspecto es un servidor que se cae. Entonces, tenemos, dentro Redis tenemos un concepto de amo y esclavo. Un maestro replica los datos en un esclavo. Hay un fragmento de esclavo. Por lo tanto, el maestro tiene que replicar los datos y puede ser de forma sincronizada o asíncrona. En Redis, si un fragmento esclavo deja de funcionar, el maestro mismo se detiene, el clúster se vuelve inutilizable. Entonces, ese es un gran problema y eso puede suceder todo el tiempo. Estrictamente en implementaciones locales donde tiene un código abierto o Redis Despliegue de laboratorio de Redis. En ese caso, si un servidor deja de funcionar y resulta que es el esclavo de un fragmento maestro, el clúster mismo quedaría inutilizable. Entonces, debe involucrarse y hacer una intervención manual para recuperarse de ese escenario. mientras que dentro NCache es automatico Entonces, cualquier servidor puede caer, el nodo sobreviviente y podría estar activo o de respaldo.
Por ejemplo, este servidor se cae, esta es una partición activa, también tiene una partición de respaldo. Si todo este servidor se cae, la copia de seguridad promueve el activo. La partición de respaldo se promueve a activa y obtiene todos los datos del nodo superviviente y hay una conmutación por error de conexión que está integrada. Cualquier servidor que deje de funcionar, los clientes detectarían eso en el tiempo de ejecución y decidirían y conmutarían por error a los nodos sobrevivientes y aquí me gustaría reforzar ese concepto de que con el Redis necesitas como mínimo 3 servidores. Este es el concepto de regla de la mayoría. El coordinador del grupo tiene que ganar una elección. Ese no es el caso con NCache. Puede comenzar a trabajar completamente en un clúster de caché con solo 2 nodos y le brindará funciones completas de alta disponibilidad. Cualquier servidor que se caiga, un nodo sobreviviente es totalmente capaz de funcionar sin ningún problema y ese no es el caso con Redis.
Configuraciones dinámicas. Puede cambiar las configuraciones del clúster en tiempo de ejecución y esto implica agregar nuevos servidores, eliminar servidores o cambiar algunas configuraciones en el clúster de caché. Eso es algo que puede aplicar en un clúster de bloqueo completo en tiempo de ejecución sin detenerlo. mientras que para Redis, es limitado. Hay muchas configuraciones que debe aplicar manualmente y luego hay muchos eventos de estado del clúster que están disponibles en NCache lado, al que puede suscribirse. Además, puede utilizar herramientas de supervisión y gestión. Mientras, Redis no tiene esas caracteristicas.
Entonces, este es un concepto muy importante. Déjame resumirlo para ti. Adición y eliminación de un servidor en Redis es algo que le daría muchos problemas. Para agregar datos, no se reequilibraría automáticamente. Por lo tanto, no es una arquitectura cien por cien de igual a igual. Por lo tanto, el clúster de caché tiene una capacidad limitada. Del mismo modo, si un fragmento esclavo deja de funcionar, el propio clúster se vuelve inutilizable. Porque hay un problema de distribución que ahora debe administrar manualmente. La conmutación por error también es manual, ¿verdad? Por lo tanto, si un servidor falla, debe realizar la conmutación por error manualmente y comenzar a usar los nodos supervivientes. Si agrega nuevos servidores, tendría que cambiar manualmente a los servidores recién agregados.
Por lo tanto, estas son todas las limitaciones que tendría y, ya sabe, me sorprendería ver el uso de una implementación de producción de tal naturaleza y ahora necesita aumentar la capacidad o necesita desactivar los servidores para el mantenimiento. Entonces, eso sería muy difícil con un producto como Redis. Mientras, NCache le brinda una experiencia perfecta. Donde puede agregar o eliminar servidores sobre la marcha sin afectar nada.
Particiones/fragmentos dinámicos
Ahora, otro concepto dentro, ya sabes, el grupo es el mecanismo de autocuración.
NCache Tiene particiones dinámicas. Agregas más servidores, los datos se obtienen redistributadas, se formulan nuevas particiones en tiempo de ejecución. De manera similar, deshabilita un servidor, el clúster pondría a disposición la copia de seguridad y se repararía solo y formularía un clúster de caché de 2 nodos saludable si lo redujera de 3 a 2 y luego el aspecto de confiabilidad. Tiene derecho de particiones de replicación, que también está disponible en Redis como forma de esclavos, pero su alta disponibilidad depende de la replicación. no tienen con Redis no tendría alta disponibilidad, si no tiene fragmentos esclavos configurados. Por lo tanto, debe tener fragmentos de esclavos disponibles. Considerando que, con el NCache, tenemos topologías.
Por ejemplo, Caché Particionado, donde tenemos fragmentos maestros, particiones maestras. Si este servidor deja de funcionar, todavía tiene alta disponibilidad porque los clientes lo detectarían y fallarían y comenzarían a usar el nodo de supervivencia. Tendrían pérdida de datos y eso es cierto para Redis así como. Pérdida de datos porque no hay replicación, pero todavía está altamente disponible y luego tenemos una mejora en esto, donde también tenemos soporte de replicación. Si este servidor deja de funcionar, no solo la copia de seguridad del servidor está disponible, sino que los clientes se recuperan automáticamente. Asi que, Redis está limitado. Su alta disponibilidad depende de la replicación. No tiene alta disponibilidad, si la replicación no está activada, lo que también es un factor limitante.
Y luego el mecanismo de autorreparación, aunque no se necesita intervención manual.
Si comienza con 3 servidores, derriba un servidor, usaría una partición activa, un maestro y luego también perdería un esclavo de otro servidor. Entonces, en ese caso, la copia de seguridad del servidor 3 estaba en el servidor 1, entonces, esto se activa. Se une a las particiones activas en tiempo de ejecución. No se necesita intervención. Se necesita trabajo manual y luego el servidor de partición 2 formularía una partición saludable en el servidor 1. Entonces, el clúster se repararía automáticamente y esta es la naturaleza dinámica de NCache en comparación con Redis. para donde Redis, los fragmentos no se pueden reajustar en tiempo de ejecución. El clúster se detiene si el fragmento esclavo deja de funcionar. Los datos redisLa tributación no es dinámica. La alta disponibilidad depende de la replicación, que no es el caso con NCache. NCache le proporciona alta disponibilidad incluso sin replicación.
Entonces, todos estos beneficios que obtienes de NCache, hace que sea un producto mucho más superior porque estas características están completamente ausentes o limitadas en Redis y esto es cierto para Azure Redis. Esto también es cierto para el código abierto porque estos son productos muy comparables y esto también es cierto para Redis labs Redis ofreciendo también.
NCache De demostración
Ahora voy a dedicar algo de tiempo a, ya sabes, mostrar el producto real en acción para que tengas una idea de cómo NCache se configura. Entonces, este es nuestro entorno de demostración. He estado trabajando con eso. Entonces, simplemente crearé un nuevo caché. Esta es nuestra herramienta de administración web que viene instalada con NCache. El modo de serialización puede ser binario o JSON. Depende completamente de ti. Solo nombraré el caché y le mostraré cómo crear un clúster de caché, conectar una aplicación cliente y monitorearlo y administrarlo también.
Por lo tanto, mantendré todo simple porque el enfoque principal de este seminario web es NCache vs Redis, así que mantendré todos los detalles simples. Réplica con particiones, esa es nuestra topología más recomendada. Replicación asíncrona entre activo y respaldo. Por lo tanto, puede elegir Sincronizar. Async es más rápido, así que voy a ir con eso. Tamaño del clúster de caché. Luego voy a especificar estos nodos de servidor donde NCache ya está instalado. puerto tcp NCache es un protocolo de comunicación base TCP/IP. Entonces, mantendré todo simple y en esto solo habilitaré el desalojo para que el caché se llene. Por lo tanto, elimina automáticamente algunos elementos del caché y, como resultado, deja espacio para los elementos más nuevos. Inicia este caché y finaliza. Inicie esto automáticamente en el inicio del servicio, por lo tanto, cada vez que mi servidor se reinicia, se une automáticamente al clúster de caché y eso es todo. Así de sencillo es configurar un clúster de caché y luego lo usas, que te voy a mostrar a continuación.
Soporte en la nube (Azure y AWS)
Entonces, nuestro modelo de servicio administrado se acerca. Nuestro próximo lanzamiento se centra en lo que creo que está dentro de dos o tres semanas. Entonces, tendremos una gestión completa NCache software como modelo de servicio en Azure y en AWS.
Por el momento, será el modelo VM. Si tiene en las instalaciones, puede usar cajas físicas o de VM. Si elige Azure, debe configurar su máquina virtual a través del mercado o simplemente puede configurar una máquina virtual y luego instalarla. NCache software descargándolo de nuestro sitio web. Y luego también tenemos un entorno en contenedores. Tenemos imágenes de Docker y somos totalmente compatibles con Azure Kubernetes Service, EKS - Elastic Kubernetes Service y cualquier otra, por ejemplo, la plataforma OpenShift Kubernetes, NCache ya está totalmente integrado y es totalmente compatible con esas plataformas. En lo que respecta al aspecto administrado, eso es algo que está surgiendo. Entonces, en el futuro, dentro de dos o tres semanas, estaría completamente disponible.
Entonces, le mostraré la ventana de estadísticas, que es un contador de rendimiento y, por cierto, estas opciones de monitoreo están disponibles para NCache, en términos de NCache tanto en Windows como en el entorno Linux, ¿verdad?
Entonces, voy a ejecutar una herramienta de prueba de estrés. Creo que ya hay uno ejecutándose para otro caché. Entonces, continuaré y ejecutaré uno más y esto simularía nuestra carga ficticia en nuestro clúster de caché. Simplemente especifica el nombre y descubre automáticamente los servidores mediante el uso de los archivos de configuración y simplemente se conecta a ellos.
Por lo tanto, tenemos el estado del clúster completamente conectado, las solicitudes por segundo que muestran el rendimiento, la latencia por microsegundo promedio por operación de caché, adiciones, recuperaciones, actualizaciones, eliminaciones, tamaño de caché, CPU, memoria. Entonces, obtiene una vista de monitoreo centralizada. Puedes usar esta herramienta. También puede usar Windows perfmon.
Para Linux tenemos nuestra monitorización personalizada. Por lo tanto, también puede usar nuestra herramienta de monitoreo directamente para servidores Linux y también puede usar cualquier herramienta de terceros para monitorear NCache así como. Entonces, ese fue un vistazo rápido a nuestro proceso de creación de caché. Algunos aspectos de seguimiento y gestión.
Entonces, volviendo. Ya comentamos algunos detalles. Lo siguiente que me gustaría discutir es la oferta de nube/soporte de nube. Ahora Redis en sí mismo, puede elegir un caché no administrado, también puede elegir un caché administrado y luego hay un servicio alojado que está disponible y la opción de administración es de proveedores externos. La opción alojada es de Azure Redis, donde puede tener una variante de código abierto de Redis personalizado por Microsoft y que está disponible como un modelo alojado. Considerando que, en el NCache lado, tenemos modelo de servidor de caché, modelo VM. Ya he discutido el enfoque del contenedor. Es totalmente compatible con Windows y con los contenedores de Linux. Tenemos demostraciones en video disponibles para Azure Service Fabric para contenedores de Windows, detalles de la arquitectura de microservicios. Tenemos el servicio Azure Kubernetes que usa contenedores de Linux. EKS: Elastic Kubernetes Service y luego creo que también hicimos Red Hat OpenShift Containers a través de Kubernetes.
Entonces, esas son todas las opciones de implementación de contenedores disponibles y es flexible, su plataforma, ya sabes, no es específica de la plataforma. Por lo tanto, puede implementarlo en cualquier tipo de plataforma en contenedores sin ningún problema. El servicio administrado se acerca, así que ya lo discutimos. Entonces, eso es algo en lo que NCache habría administrado el servicio, pero eso está en nuestra próxima versión.
Un aspecto importante es el beneficio de usar un modelo de VM, aunque debe conectarse a una VM en lugar de a un servicio, pero usted controla todo. Puede ejecutar el código del lado del servidor que cubriré a continuación, pero el aspecto más importante es el aspecto del rendimiento. Ya comentamos que hay muchas características de rendimiento dentro NCache, que faltan en Redis. Si elige tener Azure Redis, tendría que conectarse a la infraestructura de Azure. Entonces, esas son máquinas virtuales, esas se ejecutan en una red virtual separada. Estos están ubicados cerca pero nuevamente están lejos. Es diferente a su propia red virtual que tiene en Microsoft Azure y donde tiene todas sus implementaciones de aplicaciones.
Con NCache Puedes elegir nuestro NCache implementación en la misma red virtual que las redes virtuales de su aplicación. Por ejemplo, su servicio de aplicaciones, su sitio web de Azure, sus microservicios de Azure, se ejecutan en una red virtual de Azure. Puede optar por implementar máquinas virtuales de Azure en la misma red virtual y mejorar el rendimiento de su aplicación. Según nuestras propias pruebas en nuestro laboratorio, NCache era de cuatro a cinco veces más rápido que el modelo SaaS de Redis que normalmente obtiene en Microsoft Azure. Entonces, ese es un aspecto muy importante que me gustaría resaltar.
Además, obtienes mucho control sobre tu máquina virtual. Tiene control total sobre cómo iniciar un caché, aumentar el tamaño, obtener la capacidad total. No hay límite en las unidades de solicitud, no hay límite en el tamaño, no hay huella de uso y no se le cobra como parte de eso. Usted trae su propia licencia y eso también podría ser perpetuo, también podría ser una licencia de suscripción, eso podría ser muy flexible en términos de licencias. Además, puede ejecutar código del lado del servidor encima de su NCache servidores. Puedes manejar esto completamente. Puedes optimizar esto completamente. Puedes escribir muchas interfaces. Tales como lectura simultánea, escritura simultánea, escritura diferida, cargador de caché y algunas funciones de cuadrícula de cómputo, como MapReduce, Aggregator, procesadores de entrada, y esto solo es posible con NCache. Incluso nuestro modelo SaaS, que sería un modelo alojado que tendría todas estas ofertas disponibles, lo cual no será el caso con Redis. Entonces, esa es nuestra plataforma.
Mantener el caché actualizado
Siguiente segmento, los próximos 15 minutos los pasaría en la comparación del nivel de características y para eso tengo algunos segmentos definidos. Entonces, comenzaré si necesita mantener el caché actualizado y eso es muy importante, debería haber un seminario web separado solo sobre esto, cómo mantener el caché actualizado específicamente con respecto a las fuentes de datos de back-end, con respecto al uso de su aplicación. casos.
Entonces, en comparación con Redis, sabes, NCache tiene muchas características en este lado también.
Tenemos la caducidad de la base de tiempo, que es absoluta y deslizante, pero también tenemos un mecanismo de recarga automática disponible para eso. Redis solo tiene caducidad absoluta y deslizante sin ningún mecanismo de recarga. Para recargar, le permitimos implementar una interfaz, llamada controlador de lectura, que es un código del lado del servidor. Una vez más, eso es posible porque NCache le permite dar, tener acceso completo a sus máquinas virtuales donde NCache está alojado. Por lo tanto, puede implementar código del lado del servidor encima de NCache y use NCache poder computacional para respaldarlo.
Puede sincronizar su caché con la base de datos. NCache es muy fuerte en la sincronización de bases de datos. Tenemos dependencia de SQL. Tenemos una dependencia de DB que solo es compatible con DB. Tenemos Procedimientos Almacenados .NET CLR. Entonces, todas estas características le permiten sincronizar su caché con la base de datos. Y la idea aquí es que si hay un cambio en la base de datos, un registro en la base de datos cambia y tenía ese registro almacenado en caché, estas dos fuentes pueden no estar sincronizadas. Entonces, con NCache, si hay un cambio en la base de datos, puede invalidar o volver a cargar automáticamente esos datos en NCache en tiempo de ejecución. Esta es una característica exclusiva de NCache. Ningún otro producto tiene esta función. Por lo tanto, puede tener un caché totalmente sincronizado con su base de datos back-end y esto no solo es cierto para las bases de datos relacionales, también tenemos características en el lado de las fuentes de datos no relacionales.
La dependencia de archivos es otra característica en la que puede hacer que los elementos dependan del archivo. Contenido del archivo, si el contenido cambia, los elementos se eliminan o recargan automáticamente. Y dependencia personalizada, puede usarla con cualquier fuente. podría ser un NoSQL database, podría ser un sistema de archivos o relacional, cualquier conector, cualquier servicio web. Por lo tanto, puede validar artículos en función de sus requisitos flexibles. Hemos proporcionado una implementación de esta dependencia con Cosmos DB. Entonces, hemos implementado la sincronización de NCache con Cosmos DB. Si estás usando NCache junto con cosmos DB, puede usar la dependencia personalizada y creo que también hice un seminario web sobre esto.
Manejo de datos relacionales. Entonces, los datos relacionales tienen relaciones. Los elementos en el caché son un par de valores clave, por lo que puede establecer relaciones entre diferentes elementos y eso es algo que no está disponible en Redis lado. Por lo tanto, tendría que lidiar con los elementos por separado. Considerando que, con NCache puede combinar elementos en grupos uno a uno, uno a muchos o muchos a muchos. El elemento principal pasa por un cambio, el elemento secundario se puede invalidar o recargar automáticamente, según sea necesario.
Agrupación de datos, búsqueda SQL y LINQ
Otro aspecto es la agrupación y búsqueda de datos, donde NCache es muy fuerte & Redis no tiene ninguna característica. Y nuevamente, esto es cierto para Azure Redis que es muy limitado de todos modos. el código abierto Redis está un poco por delante, pero aún es limitado en términos de características. Incluso el Redis Lab, la versión comercial de Redis, que no está equipado con estas características.
La búsqueda SQL está disponible. Puede buscar artículos dentro de NCache en función de sus atributos de objeto. Los objetos se agregan en el caché. Puede definir índices para sus atributos. Por ejemplo, los productos pueden estar en el índice por su ID, su precio, sus categorías y ahora puede ejecutar la búsqueda de esos productos utilizando estos atributos. Un ejemplo típico sería seleccionar un producto donde la categoría del punto del producto es algo o el precio del punto del producto es superior a 10 y el precio del punto del producto es inferior a 100 y NCache ejecutaría la búsqueda en memoria en todos los elementos, en todos los servidores, consolidaría los resultados y le devolvería el conjunto de resultados. Por lo tanto, ya no tiene que lidiar con las llaves. Los datos se recuperan en función de un criterio.
Las búsquedas LINQ también están disponibles. Tenemos .NET y .NET Core aplicaciones Si está utilizando, ya sabe, la búsqueda LINQ, puede ejecutar la búsqueda LINQ en NCache así como. Entonces, esa es una característica única para NCache donde Redis no tiene ningún apoyo. Redis cualquiera, todos los sabores de Redis, no tiene este soporte.
Puedes tener grupos, subgrupos. Lógicamente puedes hacer colecciones dentro NCache. Eso no está disponible en Redis y puede recuperar, actualizar y eliminar datos en función de esos grupos.
Se pueden atribuir etiquetas y etiquetas con nombre. Por ejemplo, puede usar palabras clave que se pueden adjuntar a sus artículos. Un ejemplo típico sería que puede etiquetar a todos los clientes con una etiqueta de cliente. Todos los pedidos con una etiqueta de pedido y los pedidos de un determinado cliente también pueden tener un ID de cliente adjunto como etiqueta. Cuando necesite pedidos, simplemente diga obtener por etiqueta y proporcione los pedidos como una etiqueta, para que obtenga todos los pedidos. Cuando necesita pedidos de un determinado cliente, dice obtener por cualquier etiqueta o obtener por etiqueta y proporciona la identificación del cliente, obtendrá todos los pedidos, pero solo para esa identificación de cliente. Entonces, esa es la flexibilidad de usar etiquetas y etiquetas con nombre que tiene con NCache. Redis no es compatible con estos.
Código .NET del lado del servidor
Ya hemos discutido que, por lo general, usamos un patrón de caché aparte, donde primero verifica los datos en el caché, si se encuentran allí, regresa, si no encuentra datos en el caché, iría a la base de datos de back-end en su aplicación y luego obtener esos datos y llevarlos al caché. Entonces, hay un valor nulo, recuperas el valor nulo y luego vas a la base de datos. Puede automatizar eso con la ayuda del controlador Read-Thru. Es un código del lado del servidor que se ejecuta en su NCache servidores. Nuestro servicio administrado también tendría esta característica. Entonces, implementa esta interfaz que le permite conectarse a cualquier fuente de datos. Podría ser un servicio web, podría ser una fuente de datos relacionales o una fuente de datos no relacionales y hay un montón de métodos que se llamarían tan pronto como se encuentre un valor nulo en la memoria caché.
Entonces, llame al método Cache.Get, habilite el indicador Read-Thru. Si el elemento no está en el caché, la llamada se pasa a su controlador de lectura y, como resultado, obtendrá datos de la base de datos de back-end al pasar por ese código de controlador. ¿Cuál es su código de usuario que se ejecuta en NCache lado del servidor. Entonces, sin problemas, puede pasar NCache y obtenga los datos que necesita.
Write-through es lo opuesto, que también es compatible y Redis no tiene estas funciones donde puede actualizar algo en el caché y ahora desea actualizar la base de datos, puede actualizar la base de datos llamando a su controlador de escritura simultánea. Usted implementa y registra este controlador de escritura simultánea y NCache lo llamaría para actualizar la base de datos back-end y escribir detrás es lo opuesto. Cualquier actualización en el caché, las devoluciones de la aplicación cliente y NCache actualizaría la base de datos back-end de forma asíncrona en segundo plano. Asi que, NCache incluso puede mejorar su rendimiento para operaciones de escritura en la base de datos, lo que no es posible con Redis o cualquier otro producto, si no tiene la capacidad de ejecutar código del lado del servidor. Y este es un .NET puramente nativo y .NET Core bibliotecas de clases que puede implementar y registrar como interfaces de lectura y escritura, lo cual es posible con NCache.
El cargador de caché es otra característica. Donde puede completar previamente el caché implementando una interfaz y registrándose con NCache. Entonces, cada vez que reinicia su caché, carga automáticamente algunos de sus datos importantes dentro NCache y esto se ejecuta en todos los servidores simultáneamente. Entonces, es súper rápido. Por lo tanto, puede completar previamente todos sus datos y nunca más tendrá que ir a la base de datos. Siempre encontrará esos datos porque los cargó previamente.
Dependencia personalizada, procesador de entrada, estas son nuevamente características que solo son exclusivas de NCache y el motivo principal por el que no se pueden utilizar estas funciones. En primer lugar, Redis no tiene estas características, los módulos no son compatibles con Azure Redis o incluso en código abierto Redis. El lado del servidor, el código no es posible con Azure Redis. Principalmente, porque no tiene acceso a las máquinas virtuales subyacentes y esta fue la razón principal por la que me refería anteriormente con NCache en un modelo de VM en este momento, tiene acceso completo donde lo implementa, cómo lo controla, cómo lo administra. Por lo tanto, usted tiene el control total. No es una caja negra como Redis .
Replicación WAN para múltiples centros de datos
Unos pocos detalles más y luego concluiré esto. La replicación WAN es otro aspecto.
Activo-pasivo es compatible con Redis, donde puede transferir todo el centro de datos, caché de un centro de datos a otro. En NCache, tenemos activo-pasivo. Entonces, transición unidireccional de datos de un centro de datos a otro. También tenemos activo-activo, que es un caso de uso muy apremiante y muy importante en el que puede tener ambos sitios activos. Necesita las actualizaciones del sitio uno en el sitio dos y viceversa. Entonces, esa no es una habilidad en Redis lado. No tiene esa capacidad, por lo que no puede ejecutar sitios activos-activos con Redis. Con NCache esto es cierto para el caso de uso de almacenamiento en caché de datos de su aplicación en el que tiene datos en ambos sitios que se actualizan y esto también es posible a través de nuestras sesiones de sitios múltiples. Entonces, ese es otro espacio donde NCache es un claro ganador.
Topologías de caché
Luego algunos otros detalles. Topologías de almacenamiento en caché. Tenemos una enorme lista de topologías de almacenamiento en caché en comparación con Redis.
Entonces, en función de diferentes casos de uso, tenemos Mirrored, Replicated, Partitioned y luego Partition Replica y luego ya debatimos, discutimos cómo NCache el agrupamiento es mejor en general y tenemos muchas más opciones en comparación con Redis Ofertas
Herramientas GUI - Administración y monitoreo de caché
Luego tenemos herramientas GUI. Aquí hay una comparación. Gerente, monitor.
Mientras que tenemos herramientas de PowerShell, tenemos herramientas de volcado y recarga, administración completa, aspectos de monitoreo integrados. Mientras, Redis también está limitado en ese frente y, como parte de eso, les he mostrado algunos detalles y esto es cierto tanto para Windows como para las implementaciones de Linux de NCache.
Características específicas de ASP.NET
Algunas funciones de almacenamiento en caché específicas de ASP.NET.
Sesiones, tenemos sesiones multisitio, ASP.NET a ASP.NET Core se acerca el uso compartido de sesiones. ASP.NET y ASP multisitio.NET Core Hay sesiones disponibles. Ver estado, almacenamiento en caché de salida. Redis solo tiene sesiones, lo cual es muy básico en comparación con NCache. El bloqueo de sesiones, el uso compartido de sesiones es parte de NCache. El almacenamiento en caché de salida es compatible con ambos extremos y, además, tenemos SignalR Backplane, ASP.NET Core almacenamiento en caché de respuestas. Por lo tanto, todo esto constituye un conjunto completo de características para sus requisitos de almacenamiento en caché específicos de la web. Por lo tanto, puede revisar el conjunto de funciones en detalle.
Intercambio de datos en tiempo de ejecución con eventos
Y luego tenemos la mensajería Pub/Sub.
Tenemos eventos a nivel de artículo y también tenemos un sistema de notificación de eventos basado en criterios, que es mucho más superior en comparación con Redis. Tengo un seminario web separado sobre nuestros mensajes de Pub/Sub. Por lo tanto, le recomiendo encarecidamente que lo revise si tiene alguna pregunta. Entonces, creo que concluiré en este punto.
Integraciones de terceros
Finalmente, integraciones de terceros.
También tenemos NHibernate y Entity Framework. AppFabric el envoltorio está disponible. Memcached el envoltorio está disponible. Por lo tanto, si está pasando de esos productos, puede pasar sin problemas a NCache en comparación con Redis.
Seguridad y cifrado
Algunos detalles sobre cifrado de seguridad y creo que ya estamos en el marcador de tiempo.
Conclusión
Entonces, es un buen momento para concluirlo. Entonces, lo primero es que cuando quieran, cuando quieran, pueden ir a www.alachisoft.com y puede descargar una versión empresarial de NCache y le mostraremos personalmente cómo funciona en su entorno. Por lo tanto, lo alentamos a que vaya directamente al sitio web y obtenga esa prueba gratuita de Enterprise de 30 días. Programar una demostración será un placer. Además de eso, tendremos una grabación de este seminario web disponible para usted. Por lo tanto, mantente atento a tus correos electrónicos y redes sociales cuando te lo comuniquemos. Si no respondimos a sus preguntas hoy y sé que tenemos muchas más por venir y estamos justo en el límite, envíe un correo electrónico support@alachisoft.com.
Si tiene alguna consulta técnica, tendremos una respuesta para usted y si está interesado en seguir adelante y aplicar NCache en tu entorno solo puedes contactar sales@alachisoft.com .