SQLAlchemy supporta la memorizzazione nella cache?

Question

SQLAlchemy supporta un qualche tipo di memorizzazione nella cache, quindi se eseguo ripetutamente la stessa query restituisce la risposta dalla cache invece di interrogare il database? Questa cache viene cancellata automaticamente quando il DB viene aggiornato?

O qual è il modo migliore per implementarlo su un'installazione CherryPy + SQLAlchemy?

Answer 1

Abbiamo una soluzione di memorizzazione nella cache piuttosto completa, ad esempio in combinazione con hook incorporati, in 0.6. È una ricetta per sottoclassare le query, renderle consapevoli di Beaker e consentire il controllo della memorizzazione nella cache delle query per query esplicite e caricatori pigri tramite le opzioni di query.

Lo sto eseguendo in produzione ora. L'esempio stesso è nella dist e la documentazione introduttiva è all'indirizzo http: // www.sqlalchemy.org/docs/orm/examples.html#beaker-caching .

AGGIORNAMENTO: il becher è stato ora sostituito con la memorizzazione nella cache dogpile : http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching

Answer 2

Non una risposta alla tua seconda domanda, ma dai commenti in questo link indica che SQLAlchemy non supporta la cache: http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html

Raven ha detto ...

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 ha detto ...

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 supporta due tipi di cache:

1. La memorizzazione nella cache del set di risultati in modo che l'esecuzione ripetuta della stessa query raggiunga la cache anziché il database. Utilizza dogpile che supporta molti backend diversi, tra cui memcached , redis e file flat di base.

   I documenti sono qui: http: // docs. sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching

2. Memorizza nella cache l'oggetto query in modo che l'interprete Python non debba riassemblare manualmente la stringa di query ogni volta. Queste query sono chiamate query al forno e la cache si chiama al forno . Fondamentalmente memorizza nella cache tutte le azioni sqlalchemy PRIMA di colpire il database - non riduce le chiamate al database. I benchmark iniziali mostrano accelerazioni fino al 40% nel tempo di generazione di query al compromesso di un leggero aumento della verbosità del codice.

   I documenti sono qui: http://docs.sqlalchemy.org/ it / ultima / orm / estensioni / baked.html

Answer 4

O utilizzare una cache a livello di applicazione tramite riferimenti deboli (weakref.WeakValueDictionary), vedere un esempio qui: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject