¿SQLAlchemy admite el almacenamiento en caché?

Question

¿SQLAlchemy es compatible con algún tipo de almacenamiento en caché, por lo que si ejecuto repetidamente la misma consulta, se devuelve la respuesta desde el caché en lugar de consultar la base de datos? ¿Este caché se borra automáticamente cuando se actualiza el DB?

¿Cuál es la mejor manera de implementar esto en una configuración CherryPy + SQLAlchemy?

Answer 1

Tenemos una solución bastante completa de almacenamiento en caché, como un ejemplo en conjunción con ganchos incrustados, en 0,6 . Es una receta para crear una subclase de Query, informarle sobre Beaker y permitir el control del almacenamiento en caché de consultas para consultas explícitas, así como cargadores perezosos a través de opciones de consulta.

Lo estoy ejecutando en producción ahora. El ejemplo en sí está en dist y la documentación de introducción está en http://www.sqlalchemy.org/docs/orm/examples.html#beaker-caching.

ACTUALIZACIÓN: Cubilete ahora ha sido sustituido por dogpile almacenamiento en caché: http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching

Answer 2

No

una respuesta a su segunda pregunta, pero a partir de los comentarios en este enlace indica que SQLAlchemy no soporta Cacheing: http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html

Cuervo dijo ...

Does SQLAlchemy do any kind of internal caching? 

For example, if you ask for the same data twice (or an obvious subset 
of the initially requested data) will the database be hit once or twice? 

I recently wrote a caching database abstraction layer for an 
application and (while fun) it was a fair bit of work to get it to a 
minimally functional state. If SQLAlchemy did that I would seriously 
consider jumping on the bandwagon. 

I've found things in the docs that imply something like this might be 
going on, but nothing explicit. 
4:36 PM 

Jonathan Ellis dijo ...

No; the author of SA [rightly, IMO] considers caching a separate concern. 

What you saw in the docs is probably the SA identity map, which makes it so 
if you load an instance in two different places, they will refer 
to the same object. But the database will still be queried twice, so it is 
not a cache in the sense you mean. 

Answer 3

No, pero puede hacer el almacenamiento en memoria caché con Memcache.

Answer 4

O utilizar una memoria caché de nivel de aplicación a través de referencias débiles dicts (weakref.WeakValueDictionary), ver un ejemplo aquí: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject

Answer 5

SQLAlchemy admite dos tipos de cachés:

1. almacenamiento en caché el conjunto de resultados de manera que se ejecuta repetidamente la misma consulta acierta en la caché en lugar de la base de datos. Utiliza dogpile que admite muchos backends diferentes, incluidos memcached, redis, y archivos planos básicos.

   Docs están aquí: http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching

2. El almacenamiento en caché el objeto query modo que Python intérprete no tiene que volver a montar manualmente la cadena de consulta cada vez. Estas consultas se llaman baked queries y el caché se llama baked. Básicamente, almacena en caché todas las acciones que toma sqlalchemy ANTES de acceder a la base de datos, no reduce las llamadas a la base de datos. Los puntos de referencia iniciales muestran aceleraciones de hasta 40% en el tiempo de generación de query a cambio de un ligero aumento en la verbosidad del código.

   Docs están aquí: http://docs.sqlalchemy.org/en/latest/orm/extensions/baked.html