Regroupement de connexions pour une application Android qui se connecte à une base de données Postgresql

Comment faire un regroupement de connexions

Chaque plate-forme a une interface de regroupement de connexions différente. Vous devrez lire la documentation de la plate-forme spécifique que vous utilisez (Ruby + Rails ou autre), ou utiliser une couche intermédiaire de regroupement générique comme PgBouncer.

Les réponses relatives à un outil (par exemple, PHP avec Zend Framework) n'auront rien à voir avec les réponses relatives à un autre outil (comme Ruby on Rails). Même si vous choisissez quelque chose comme PgBouncer, il y a toujours des détails liés à la façon dont la plate-forme gère les durées de vie des transactions, le mode de regroupement à choisir en fonction des besoins de l'application, etc.

Vous devez donc d'abord déterminer ce que vous utilisez et ce que vous devez en faire. Alors étudier comment mettre en place sa mutualisation de connexion. (Avec de nombreux outils, c'est juste automatique).

Si vous êtes toujours bloqué après avoir lu la documentation de la plateforme que vous avez choisie , demandez une nouvelle détaillée et précise question balisée de manière appropriée pour la plate-forme.

Mise en commun et middleware

Ne connectez pas votre application directement à PostgreSQL. Surtout si c'est sur Internet à partir de clients aléatoires.

Utilisez un serveur Web près du serveur PostgreSQL et faites-le accepter les demandes de service Web pour négocier l'accès à la base de données via une API Web bien définie avec des transactions courtes qui sont limitées à la demande dans la mesure du possible.

Ce n'est pas seulement un cas de sagesse reçue - il y a de bonnes raisons de le faire, et de sérieux problèmes avec l'exécution de PostgreSQL à partir d'appareils aléatoires sur Internet.

Application Android parlant directement à Pg

Les problèmes rencontrés pour parler à Pg directement sur Internet à partir de nombreux clients incluent :

• Chaque backend PostgreSQL a un coût, qu'il soit inactif ou non. PgBouncer en mode de regroupement de transactions aide à cela dans une certaine mesure.

• Les connexions se perdent de manière aléatoire lorsque vous travaillez sur Internet. Chutes de WiFi, changements d'adresse IP sur les services IP dynamiques, service mobile qui s'estompe ou atteint sa capacité maximale ou s'échelonne simplement avec une perte de paquets élevée. Cela vous laisse avec beaucoup de connexions PostgreSQL dans des états indéterminés, probablement avec des transactions ouvertes, vous donnant <IDLE> in transaction problèmes et la nécessité d'autoriser beaucoup plus de connexions qu'il n'en faut vraiment.

• C'est transactionnel - si quelque chose ne se termine pas, vous pouvez mettre fin à la transaction et savoir que cela n'aura aucun effet.

Avantages d'avoir une couche intermédiaire

Un serveur répondant aux demandes de service Web HTTP de votre application sur les appareils Android pour agir en tant que courtier pour l'accès à la base de données peut être un gros avantage.

• Vous pouvez définir une API versionnée, de sorte que lorsque vous introduisez de nouvelles fonctionnalités ou que vous devez modifier l'API, vous n'avez pas à casser les anciens clients. Ceci est possible avec Pg en utilisant des procédures stockées ou de nombreuses vues, mais cela peut devenir maladroit.

• Vous contrôlez strictement la portée de l'accès à la base de données et la durée de vie des transactions.

• Vous pouvez définir une API idempotente, où l'exécution de la même requête plusieurs fois n'a qu'un seul effet. (Je recommande fortement de le faire à cause du point suivant).

• Tout est sans état et peut avoir de courts délais d'attente. Si quelque chose ne fonctionne pas, réessayez simplement.

• Chaque connexion à la base de données passe par un pool, vous n'avez donc pas de sessions inactives. Chaque backend de base de données travaille dur pour un débit maximal.

• Vous pouvez faire la queue plutôt que d'essayer d'en faire des tonnes simultanément et de battre le serveur. (Vous pouvez également le faire avec PgBouncer en mode de regroupement de transactions).

... et validez votre modification pour modifier le sens de la question :

Performances

Votre "Aussi" concernant la performance est vraiment une question totalement différente (et devrait de préférence être publiée en tant que telle). La version très courte :totalement impossible à prédire sans beaucoup plus d'informations sur la charge de travail, comme le nombre de requêtes db par requête d'application cliente, le type de données, le type de requêtes, la taille des données, la fréquence des requêtes, l'aspect pratique de la mise en cache, .. .... sans cesse. Quiconque prétend répondre définitivement à cette question est soit le premier vrai médium de l'histoire, soit complètement rempli de celui-ci.

Vous devez déterminer approximativement la taille de vos données, les modèles de requête, etc. Déterminez combien vous pouvez vous permettre de mettre en cache dans un cache de couche intermédiaire comme redis/memcached, à quel point vous pouvez le laisser obsolète, de quel niveau d'invalidation de cache vous avez besoin. Déterminez si votre ensemble de données "chaud" (auquel vous accédez beaucoup) tiendra dans la RAM ou non. Déterminez si les index des tables fréquemment interrogées tiennent ou non dans la RAM. Déterminez quel est votre solde approximatif de lecture/écriture et combien vos écritures sont susceptibles d'être des insertions uniquement (ajout) ou des OLTP plus réguliers (insertion/mise à jour/suppression). Dummy un ensemble de données et certaines charges de travail client. Alors vous pouvez commencer à répondre à cette question - peut-être. Pour le faire correctement, vous devez également simuler des clients bloqués/disparus, etc.

Voyez pourquoi ce n'est pas juste un "Aussi ?".