SQLAlchemy - Résultats de base de données sur chaque demande?

Question

Je travaille actuellement avec une application web écrite en Python (et en utilisant SQLAlchemy). Afin de gérer l'authentification, l'application vérifie d'abord un ID utilisateur dans la session, et à condition qu'elle existe, extrait cet enregistrement utilisateur complet de la base de données et le stocke pour le reste de cette demande. Une autre requête est également exécutée pour vérifier les autorisations de l'utilisateur qu'il a stocké. Je suis assez nouveau dans le monde du développement d'applications Web, mais d'après ce que je comprends, il n'est pas efficace d'accéder à la base de données pour quelque chose comme ça sur chaque demande. Ou est-ce considéré comme une chose normale à faire? La seule chose à laquelle j'ai pensé jusqu'ici est d'extraire ces données une fois, et de stocker ce qui est pertinent (la plupart des données ne sont même pas requises pour chaque requête). Cependant, cela soulève le problème de ce qui est supposé se produire si cet enregistrement utilisateur est supprimé entre-temps. Des idées sur la meilleure façon de gérer cela?

Answer 1

Il s'agit d'une base de données, il est donc assez fréquent de "frapper" la base de données pour extraire les données requises. Vous pouvez réduire les requêtes uniques si vous créez des jointures ou des procédures stockées.

Answer 2

"frapper la base de données pour quelque chose comme ça à chaque demande n'est pas efficace."

Faux. Et, vous avez supposé qu'il n'y a pas de mise en cache, ce qui est également faux.

La plupart des couches ORM sont parfaitement capables de mettre en cache des lignes, ce qui permet d'économiser certaines requêtes DB.

La plupart des SGBDR ont une mise en cache étendue, ce qui entraîne des réponses remarquablement rapides aux requêtes courantes.

Toutes les couches ORM utilisent un langage SQL cohérent, ce qui facilite davantage la base de données dans l'optimisation des opérations répétitives. (Plus précisément, l'instruction SQL est mise en cache, ce qui permet d'économiser du temps d'analyse et de planification.)

"Est-ce normal ou non?"

True. Jusqu'à ce que vous puissiez prouver que vos requêtes sont la partie la plus lente de votre application, ne vous inquiétez pas. Construire quelque chose qui fonctionne réellement. Puis optimisez la partie que vous pouvez prouver est le goulot d'étranglement.

Answer 3

Vous parlez essentiellement de la mise en cache des données en tant qu'optimisation des performances. Comme toujours, l'optimisation prématurée est une mauvaise idée. Il est difficile de savoir où sont les goulets d'étranglement à l'avance, d'autant plus si le domaine d'application est nouveau pour vous. L'optimisation ajoute de la complexité et si vous optimisez les mauvaises choses, non seulement vous avez gaspillé l'effort, mais vous avez également rendu les optimisations nécessaires plus difficiles.

La demande de données d'utilisateur est généralement une requête assez triviale. Vous pouvez vous construire un simple benchmark pour voir quel genre de frais généraux il va introduire. Si ce n'est pas un pourcentage important de votre budget-temps, laissez-le simplement.

Si vous souhaitez toujours mettre en cache les données sur le serveur d'applications, vous devez créer un schéma d'invalidation du cache.

Les schémas possibles sont de vérifier les modifications de la base de données. Si vous n'avez pas beaucoup de données à mettre en cache, ce n'est vraiment pas plus efficace que de simplement le recharger.

Une autre option consiste à simplement expirer les données mises en cache. C'est une bonne option si la visibilité instantanée des changements n'est pas importante.

Une autre option consiste à invalider activement les caches lors des modifications. Cela dépend si vous modifiez uniquement la base de données via votre application et si vous avez un seul serveur d'applications ou une solution en cluster.

Answer 4

Pour une connexion utilisateur et des jetons d'autorisation de base dans une application Web simple, je vais certainement stocker cela dans une session basée sur les cookies. Il est vrai que quelques SELECTs par requête ne sont pas du tout un problème, mais si vous pouvez exécuter certaines/toutes vos requêtes Web à partir de données en cache sans aucun accès à la base de données, cela augmente l'évolutivité une application qui prévoit de recevoir beaucoup de chargement.

Le problème du jeton utilisateur modifié sur la base de données est géré de deux manières. L'un est, ignorez-le - pour beaucoup de cas d'utilisation ce n'est pas un gros problème pour l'utilisateur de se déconnecter et de se reconnecter pour obtenir de nouvelles autorisations qui ont été accordées ailleurs (voir unix comme exemple). L'autre est que toutes les mutations de la ligne utilisateur sont filtrées via une méthode qui réinitialise également l'état dans la session basée sur les cookies, mais cela n'est efficace que si l'utilisateur lui-même est celui qui initie les changements via l'interface du navigateur.

Si aucun des cas d'utilisation ci-dessus ne s'applique à OTOH, vous devrez probablement vous contenter d'un peu d'accès à la base de données intégré à chaque requête.