SQLAlchemy supporta la memorizzazione nella cache?
-
03-07-2019 - |
Domanda
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?
Soluzione
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
Altri suggerimenti
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.
SQLAlchemy supporta due tipi di cache:
-
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 cuimemcached
,redis
e file flat di base.I documenti sono qui: http: // docs. sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching
-
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 chiamatequery al forno
e la cache si chiamaal forno
. Fondamentalmente memorizza nella cache tutte le azionisqlalchemy
PRIMA di colpire il database - non riduce le chiamate al database. I benchmark iniziali mostrano accelerazioni fino al 40% nel tempo di generazione diquery
al compromesso di un leggero aumento della verbosità del codice.I documenti sono qui: http://docs.sqlalchemy.org/ it / ultima / orm / estensioni / baked.html
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