SQLAlchemy prend-il en charge la mise en cache?
-
03-07-2019 - |
Question
SQLAlchemy prend-il en charge une sorte de mise en cache? Par conséquent, si j’exécute la même requête à plusieurs reprises, elle renvoie la réponse à partir de la mémoire cache au lieu d’interroger la base de données. Ce cache est-il automatiquement effacé lors de la mise à jour de la base de données?
Ou quel est le meilleur moyen d'implémenter cela dans une configuration CherryPy + SQLAlchemy?
La solution
Nous avons une solution de mise en cache assez complète, à titre d'exemple en liaison avec les points d'ancrage intégrés, en 0.6. C'est une recette pour sous-classer Query, le rendre conscient de Beaker et permettre le contrôle de la mise en cache des requêtes pour les requêtes explicites ainsi que pour les chargeurs différés via les options de requête.
Je l'exécute en production maintenant. L'exemple lui-même est dans la distribution dist et la documentation d'introduction à l'adresse http: // www.sqlalchemy.org/docs/orm/examples.html#beaker-caching .
UPDATE: le bécher a été remplacé par la mise en cache de dogpile
: http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching
Autres conseils
Ce n'est pas une réponse à votre deuxième question, mais d'après les commentaires de ce lien, SQLAlchemy ne prend pas en charge la mise en cache: http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html
Raven a dit ...
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 a déclaré ...
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 prend en charge deux types de caches:
-
Mise en cache du jeu de résultats afin que l'exécution répétée de la même requête atteigne le cache au lieu de la base de données. Il utilise
dogpile
qui prend en charge de nombreux moteurs différents, y comprismemcached
,redis
et les fichiers plats de base.Les documents sont ici: http: // docs. sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching
-
Cachez l'objet
query
afin que l'interpréteur Python n'ait pas à réassembler manuellement la chaîne de requête à chaque fois. Ces requêtes sont appeléesrequêtes cuites
et le cache est appelécuit
. Fondamentalement, il met en cache toutes les actions quesqlalchemy
effectue AVANT de frapper la base de données - il ne réduit pas les appels à la base de données. Les benchmarks initiaux montrent des accélérations jusqu’à 40% en temps de génération derequête
, moyennant un léger accroissement de la verbosité du code.Les documents sont ici: http://docs.sqlalchemy.org/ en / latest / orm / extensions / baked.html
Vous pouvez également utiliser un cache au niveau de l'application via des références faibles (faiblesref.WeakValueDictionary). Voir un exemple ici: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject