Memcached vs SQL Server caché
sql-server performance (3)
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 golpear la base de datos directamente. Reducirá la cantidad de visitas a 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 los 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 Memcached externo (o similar)?
La mayoría de los artículos que he estado leyendo están relacionados con sitios de redes sociales, que en su mayoría usan MySql. Sin embargo, un article sobre MySpace, que usa 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.
Entonces, si SQL Server tiene su propio caché, ¿cuál es el beneficio de un servidor Memcached externo (o similar)?
Sí, SQL Server tiene su propio caché, pero él solo almacena en caché:
- Planes de consulta.
- Páginas de los archivos de la base de datos.
pero él no lo caché:
- resultados de una consulta
por ejemplo, tiene una consulta compleja que utiliza cierta agregación en una gran cantidad de datos (piense en: cuántos países diferentes tenemos en nuestra base de datos de clientes: SELECCIONAR DISTINCIÓN país de Clientes GRUPO POR país)
SQL Server escaneará TODA la tabla de clientes, pero su conjunto de resultados solo tendrá unas pocas entradas de largo. Cuando vuelva a emitir su consulta, SQL Server reutilizará el plan de consulta y volverá a explorar la tabla de clientes (y, si tiene suerte, las páginas aún están en la memoria)
Cuando utiliza memcached, puede almacenar las pocas filas de su conjunto de resultados y reutilizarlos una y otra vez sin conectarse al servidor de base de datos. Así que toma algo de carga de su servidor de base de datos.
NOTA: ¡Tenga cuidado con algunos datos obsoletos, si sus datos cambian en el servidor SQL!
Otro beneficio también puede ser que SQL Server es costoso de escalar, mientras que agregar un nuevo servidor web / caché puede ser más barato de lograr.
Utilizamos 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 al caché, por ejemplo.
Incluso puede almacenar el marcado si es necesario (almacenamiento en caché de salida).
En un día, al usar el almacenamiento en caché, movimos nuestro sitio para que no sea capaz de manejar 150 sesiones simultáneas, mientras que las pruebas de estrés superaron las 800. ¡Recomiendo usarlo!
Velocity, y otros, son GRANDES, especialmente cuando su servidor SQL vive en su propia caja. Hemos estado usando el almacenamiento en caché integrado 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 la reducción de la carga de SQL.