Preguntas sobre el almacenamiento en caché en el sitio web de alto tráfico

Question

Supongamos que estamos construyendo un sitio de comercio electrónico que permite a los consumidores a buscar productos tecleando palabras clave. Digamos que hay como máximo 200.000 productos, y hay millones de consumidores que utilizan el sistema. Digamos que la tabla de productos se actualiza con bastante frecuencia. Dado que el número de productos no es tan alto y que probablemente puede almacenar toda la tabla de productos en la memoria y la búsqueda en contra de ella en lugar de golpear la base de datos. Estamos con la esperanza de crear cachés distribuidos que almacenan los mismos datos, pero residen en distintos servidores (para una alta disponibilidad y la razón de rendimiento) y tenemos que ser capaces de sincronizar los datos entre estos cachés e invalidar cachés cuando se modifica tabla de productos.

Nuestra aplicación está construida usando ASP.NET MVC y NHibernate. Estoy tratando de entender si NHibernate de nivel 2 de almacenamiento en caché ayudaría con mi situación. Realmente agradecería si ustedes pueden arrojar algo de luz sobre esto.

Yo entiendo que el nivel de almacenamiento en caché-2 ayudará resultado de la consulta caché por lo que si dos usuarios diferentes están buscando usando la misma palabra clave, la caché L2 servirá el resultado de la caché en lugar de partir de la base de datos. Pero no nos ayuda mucho desde la tabla de productos se actualiza con frecuencia y el resultado será almacenado en caché rancio. Mi pregunta es ¿Estoy entendiendo el almacenamiento en caché L2 es correcta y existe nada que ayudan a administrar la memoria caché de la manera que me gustaría hacer (múltiples cachés, los mismos datos, se sincronizan entre el caché y invalidan caché). Cualquier pensamiento es muy apreciada.

Answer 1

Tener tanto el caché de segundo nivel utilizado (con el proveedor de memcached) y el complemento NHibernate.Search me parece que podría beneficiarse de ambos.

El componente NHibernate.Search depende de Lucene.Net búsqueda por palabra clave y se desacopla de la base de datos en sí. Un archivo de índice diferente es creado por clase asignada y optimizaciones se puede establecer en el nivel de establecimiento a través de atributos, que le da un nivel adicional de granularidad. Además, se puede implementar mejor opción y proposiciones (marque Lucene en acción y / o Hibernate Buscar en acción). Como nota, usted no tiene que mantener el índice (a menos que solicite explícitamente una reconstrucción de índices); la aplicación maneja todo detrás de las escenas, aunque se puede manipular el índice si desea hacerlo. Por lo tanto, añadir / borrar / actualizar un producto se actualizará automáticamente según el índice.

Para el caché de segundo nivel se consiguen aumento de rendimiento instantáneo. En un entorno de prueba con un conjunto de datos de aproximadamente 2 mil filas tuve% de mejora más del 20 incluso en un recuento extremadamente bajo petición. El aumento de rendimiento es gradualmente más grande que la solicitud se aumenta el recuento de - la aplicación golpea primero en el segundo nivel de caché y si no lo encuentra a continuación, golpea la base de datos en busca de las filas requeridas y los inserta en la caché para futuras consultas. Una vez más usted puede manejar cosas como duración de la caché y otros ajustes de configuración, así como explícitamente claro que el caché (todos de la misma, una parte de ella, o entradas en particular) si desea hacerlo. Tenga en cuenta que el estado cache es gestionado por la aplicación durante guardar / actualizar / borrar.

Para scallability * La segunda caché de nivel depende del proveedor (es decir memcached es altamente performant y escalable y admite instancias distribuido). * Para la Lucene.Net/NHibernate.Search tendrá que establecer un lugar específico que los índices residirán y ese lugar deben ser accesibles para lectura / escritura por todas las instancias de aplicaciones web. Nótese aquí que el enlace sensible es I / O y la contención de archivos, por lo que la creación de una máquina con un más rápido que el sistema de archivos de la luz y evitará que suceda (estoy hablando para su escenario con muchos miles de solicitudes de búsqueda por segundo)

Como nota al margen que recomendaría altamente NHibernate.Search ya que es extremadamente rápido que consultas con LIKE y es más fácil de usar que la aplicación de búsqueda de texto completo de SQL Server dentro de la aplicación (que he hecho).

Answer 2

El que una caché de segundo nivel le ayudará depende de exactamente qué frecuencia su mesa productos se actualiza en relación con aciertos de caché. Si añade 100 nuevos productos por hora, pero recibe 10.000 consultas por hora, incluso una caché tasa de éxito del 10% hará una gran diferencia. Si las tasas se invierten, una caché de segundo nivel será de casi ningún valor.

Le sugiero que configura un entorno de prueba de esfuerzo que se aproxima mucho a su entorno de producción y llevar a cabo la evaluación comparativa de los distintos proveedores de caché de segundo nivel.

Compruebe también que su base de datos está configurado correctamente para un escenario de actualizar pesada.

Answer 3

NHibernate.Search w / Lucene. Funciona junto con el segundo nivel de caché. Lucene puede hacer sofisticada búsqueda de texto rasgadura rápida y después vuelva de nuevo las claves de entidad a NHibernate, que tira de la entidad completo fuera de su segunda caché de nivel. La extensión NHibernate.Search hace el trabajo de mantener su índice de Lucene en sincronía.

TekPub hizo un episodio reciente de su situación exacta de buscar descripciones de los productos. El episodio se compara consultas SQL NHibernate, la indización de texto y Lucene w / NHibernate.Search.