caching - sirve - ¿qué pasa si borro los datos almacenados en caché?

¿Soporta SQLAlchemy el almacenamiento en caché?

Question

¿Soporta SQLAlchemy 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?

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

Answer 1

No es una respuesta a su segunda pregunta, pero de los comentarios en este enlace indica que SQLAlchemy no es compatible con la 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 2

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

Answer 3

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

Answer 4

SQLAlchemy admite dos tipos de cachés:

1. El almacenamiento en caché del conjunto de resultados para que ejecute repetidamente la misma consulta golpea la caché en lugar de 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. Almacenamiento en caché del objeto de query para que el intérprete de Python no tenga que volver a ensamblar manualmente la cadena de consulta cada vez. Estas consultas se llaman baked queries y el caché se llama baked . Básicamente almacena todas las acciones que sqlalchemy lleva 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.

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

Answer 5

Tenemos una solución de caché bastante completa, como ejemplo junto con los 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: Beaker ahora se ha reemplazado por caché de dogpile : http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching