¿SQLAlchemy admite el almacenamiento en caché?

Question

¿SQLAlchemy admite algún tipo de almacenamiento en caché, por lo que si ejecuto repetidamente la misma consulta, devuelve la respuesta del caché en lugar de consultar la base de datos? ¿Esta memoria caché se borra automáticamente cuando se actualiza la base de datos?

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

Answer 1

Tenemos una solución de almacenamiento en caché bastante completa, como un ejemplo junto con enlaces integrados, en 0.6. Es una receta para hacer una subclase de consultas, informarle de Beaker y permitir el control del almacenamiento en caché de consultas para consultas explícitas, así como para cargadores diferidos mediante 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: Beaker ahora se ha reemplazado por el almacenamiento en caché dogpile : http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching

Answer 2

No es una respuesta a su segunda pregunta, pero a partir de los comentarios en este enlace indica que SQLAlchemy no admite el almacenamiento en caché: http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html

Raven 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

SQLAlchemy admite dos tipos de cachés:

1. El almacenamiento en caché del conjunto de resultados para que la ejecución repetida de la misma consulta llegue a la memoria caché en lugar de a la base de datos. Utiliza dogpile que admite muchos backends diferentes, incluidos memcached , redis y archivos planos básicos.

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

2. Almacenar en caché el objeto query para que el intérprete de Python no tenga que volver a ensamblar manualmente la cadena de consulta cada vez. Estas consultas se denominan consultas horneadas y la caché se llama baked . Básicamente, almacena en caché todas las acciones que sqlalchemy toma ANTES de golpear la base de datos, no reduce las llamadas a la base de datos. Los puntos de referencia iniciales muestran aceleraciones de hasta un 40% en el tiempo de generación de query en la compensación de un ligero aumento en la verbosidad del código.

   Los documentos están aquí: http://docs.sqlalchemy.org/ es / latest / orm / extensions / baked.html

Answer 4

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