caché Memcached vs SQL Server

Question

He estado leyendo muchos artículos que sugieren que poner un Memcached (o Velocity, etc.) frente a una base de datos es más eficiente que tocar la base de datos directamente. Reducirá el número de visitas en la base de datos al buscar los datos en un caché de memoria, que es más rápido que llegar a la base de datos.

Sin embargo, SQL Server tiene su propia memoria caché para objetos en la base de datos. Cuando se recuperan datos, SQL Server mantiene su caché y, si es necesario, extrae la fila de su memoria y no golpea el disco.

Entonces, si SQL Server tiene su propio caché, ¿cuál es el beneficio de un servidor externo Memcached (o similar)?

La mayoría de los artículos que he estado leyendo se refieren a redes sociales, que en su mayoría usan MySql. Sin embargo, un article sobre MySpace, que utiliza SQL Server, sugiere que el almacenamiento en caché también se usa en ese sistema.

Este article explica cuándo se debe usar el almacenamiento en caché y este article es un contrapunto.

Answer 1

Entonces, si SQL Server tiene su propio caché, ¿cuál es el beneficio de un servidor externo Memcached (o similar)?

Sí SQL Server tiene su propia caché pero se almacena en caché única:
- planes de consulta
- páginas de los archivos de base de datos

pero no lo hace caché:
- resultados de una consulta

por ej. usted tiene una consulta compleja que utiliza cierto grado de agregación en una gran cantidad de datos (pensar: ¿cuántos países diferentes que tenemos en nuestra base de datos de clientes: SELECT DISTINCT País de clientes del grupo por país)

SQL Server examinará º TODO tabla de clientes, pero su conjunto de resultados solo tendrá unas pocas entradas. Cuando se vuelve a emitir la consulta, SQL Server reutilizará el plan de consulta y volverá a explorar la tabla de clientes, (y si tienes suerte, las páginas están todavía en la memoria)

Cuando se utiliza el MemCached puede almacenar las filas de su conjunto de resultados y reutilizarlos una y otra vez sin conectarse al servidor de la base de datos. Por lo tanto, lleva algo de carga desde su servidor de base de datos.
NOTA: ¡Tenga cuidado con algunos datos obsoletos, si sus datos cambian en el servidor SQL!

Answer 2

Velocity, et al, son geniales especialmente cuando su servidor SQL vive en su propia caja. Hemos estado utilizando el almacenamiento en caché incorporado de ASP.NET, pero esperamos pasar a Velocity. Varios servidores web hablan con un clúster de SQL y el almacenamiento en caché realmente ayuda con la escalabilidad y reduce la carga de SQL.

Answer 3

Otro beneficio también puede ser que SQL Server es costoso de escalar, mientras que agregar un nuevo servidor de caché/web puede ser más barato de lograr.

Usamos el almacenamiento en caché a nivel de aplicación para almacenar todo tipo de cosas, no todas ellas desde una base de datos. Puede manipular objetos de datos en su código y luego agregarlos a la memoria caché, por ejemplo.

Incluso puede almacenar marcado si es necesario (salida de almacenamiento en caché).

En un día, al usar el almacenamiento en caché, cambiamos nuestro sitio de 150 sesiones concurrentes mientras que las pruebas de resistencia superaban las 800. ¡Recomiendo usarlo!