Comment les lectures simultanées affectent-elles Postgres?

Question

Je suis en train de concevoir une application basée sur Postgres pour gérer de gros volumes de données avec de nombreux utilisateurs. Les données sont modélisées de sorte que la plupart des lectures utilisent seulement trois tables, ce qui signifie que tous les utilisateurs regardent les mêmes enregistrements en même temps. En ce qui concerne les lectures (pas les écritures) - est-ce que de nombreuses lectures simultanées ralentissent la DB, ou est-ce qu'une fois en mémoire, Postgres affiche la même vue pour tous les utilisateurs simultanés sans trop de retard ou de consommation de ressources?

Existe-t-il un point où le nombre de lectures du même enregistrement ralentit Postgres ou, une fois en mémoire, l'affichage des données ne coûte plus rien?

grâce,

Alex Glaros

Answer 1

faire beaucoup en même temps se lit vers le bas db lent, ou est le cas qu'une fois en mémoire, Postgres affiche la même vue à tous les utilisateurs simultanés sans beaucoup de retard ou d'une ressource consommation?

Si les mêmes données sont demandé maintes et maintes fois, alors oui, il sera conservé en mémoire (à condition Postgres possède suffisamment de mémoire disponible pour le faire).

Y at-il un point où le nombre de lectures du même enregistrement Postgres lent vers le bas

Rien ne vient gratuitement, donc oui, il y a les frais généraux impliqués lorsque les transactions simultanées demandent les mêmes données à exactement en même temps. L'accès aux blocs de données en mémoire doit être synchronisé à l'aide de verrous (quoique très légers), de verrous et de sémaphores.

Dans un système où les données complètes sont en mémoire, la CPU obtient le facteur limitant. Les versions récentes de Postgres se sont considérablement améliorées en termes d'évolutivité avec plusieurs sessions simultanées, alors assurez-vous d'utiliser la dernière version (9.6 ou même 10.0).

Cela fait référence à plusieurs transactions demandant le même bloc de données à exactement la même nanoseconde cependant. Si les transactions (sessions, connexions) requièrent généralement différentes parties de ces trois tables, vous ne verrez que des problèmes dus à la synchronisation sur des blocs de mémoire sous une charge très, très lourde.