2012-02-09 24 views
14

Tengo un servidor Debian con aproximadamente 16 GB de RAM que estoy usando con nginx y varias bases de datos pesadas de mysql, y algunas aplicaciones de PHP personalizadas. Me gustaría implementar una memoria caché entre Mysql y PHP, pero las bases de datos son demasiado grandes para almacenar todo en la memoria RAM. Estoy pensando que un caché LRU puede ser mejor por lo que investigo. ¿Esto descarta a Redis? Couchbase es también una consideración.Memcached, Redis o Couchbase

Respuesta

15

Supongamos que hay un servidor único ejecutando nginx + php + mysql instancias con algo de RAM libre restante, la forma más fácil de usar esa memoria RAM para almacenar en caché los datos es simplemente aumentar las memorias caché de las instancias mysql. Las bases de datos ya usan mecanismos similares a LRU para manejar sus buffers.

Ahora, si necesita mover parte del procesamiento fuera de las bases de datos, entonces el precaching puede ser una opción. Antes de hablar sobre memcached/redis, una caché de memoria compartida integrada con php como APC será eficiente siempre que se considere solo un servidor (en realidad más eficiente que redis/memcached).

Tanto Memcached como Redis pueden considerarse para realizar el almacenamiento en caché remoto (es decir, para compartir el caché entre varios nodos). No descartaría redis para esto: se puede configurar fácilmente para este propósito. Ambos permitirán definir un límite de memoria y manejar el caché con un comportamiento tipo LRU.

Sin embargo, no utilizaría couchbase aquí, que es un almacén de claves/valores elástico (es decir, se supone que se utiliza en varios nodos) NoSQL (es decir, no es un caché). Probablemente puedas mover algunos datos de tus instancias de mysql a un cluster de base de datos, pero usarlo solo para almacenarlos en la memoria caché es sobre-ingeniería de la IMO.

+0

He utilizado APC, pero los scripts de php cli que estamos utilizando con la aplicación web no pueden acceder a los mismos datos. Ahí es donde Memcached se convirtió en el primer paso lógico siguiente. Estaba buscando en couchbase porque leí que era un reemplazo no volátil (si es necesario) de reemplazo para memcached más o menos. – Poe

+19

Couchbase debe tenerse en cuenta ya que tiene un modo de operación de memoria simple y antiguo (llamado cubo) pero facilita la administración, administra estadísticas, etc. Divulgación completa: trabajo para Couchbase. –

1

Usamos memcached inicialmente para almacenar en caché los datos. En los datos de particionamiento de memcahed para diferentes aplicaciones en diferentes cubos era un problema real. También tenemos un requisito para eliminar datos de un solo contenedor. El monitoreo de datos es otro requisito. Nos mudamos a CouchBase y use el cubo de estilo memcahed. Supongo que es mucho más flexible y eficiente usar el cubo de estilo memcache de la base de sofá para el almacenamiento en caché en lugar de usar memcahe.

+0

Este es un caso de uso común para que los usuarios de caché/Memcache se muevan a Couchbase (con cubo de Memcache, y algunas veces con Couchbase uno).Te invito a mirar http://www.couchbase.com/memcached –

0

Como señaló Matt Ingenthron y Hari señaló que Couchbase admite el trabajo como reemplazo directo de Memcached. Couchbase utiliza memcached de forma no elástica, ya que cada nodo que participa en el clúster de Memcache es discreto, sin persistencia, es decir, solo un caché pero couchbase también ofrece tipos de cubetas "Couchbase" que proporcionan persistencia. Membase también forma parte del código, por lo que Couchbase no solo sirve datos del disco sino también de la memoria RAM y la conserva allí mientras se replica en otros nodos y persiste en el disco a medida que se aplican los cambios. Recomiendo encarecidamente Couchbase 3.x tanto para el almacenamiento en caché como para la persistencia en una huella, o múltiples huellas si solo desea una capa de almacenamiento en caché separada de la capa de persistencia.

1

¿Alguna vez ha considerado mover sus bases de datos totalmente a la memoria RAM utilizando una de las soluciones en memoria NoSQL con persistencia? Podría tomar menos almacenamiento que su base de datos MySQL original, porque muchas soluciones NoSQL generalmente tienen menos espacio que las bases de datos SQL. Además, si la lógica del lado del servidor es muy importante para usted, intente con Tarantool ya que tiene una secuencia de comandos Lua a bordo y debería tener una huella de memoria bastante pequeña. En mi caso, los mismos datos en Tarantool ocuparon dos veces menos que en MySQL. Esto se debe a que tienen una sobrecarga pequeña por fila y por campo y usan el paquete de mensajes para el almacenamiento de datos.