web-dev-qa-db-fra.com

Connexion à la base de données vs Raw TCP Connection

J'ai quelques questions fondamentales sur la façon dont les clients de bases de données et la base de données interagissent

  1. Les bases de données prennent-elles en charge plusieurs transactions simultanément sur une seule connexion de base de données à partir du client? Sinon, pourquoi pas? (car le multiplexage permettrait d'économiser sur la surcharge de ressources par connexion et les pools de connexions sont une source de conflits lorsque des milliers de requêtes simultanées doivent être exécutées simultanément, ce que le multiplexage évite à coup sûr)
  2. Quelle est la relation entre la connexion au niveau du client de la base de données et la connexion physique brute TCP. Est-ce plusieurs-à-un [multuplexage] (ou) un-à-un? Si non multiplexé, pourquoi pas?
  3. S'il est multiplexé, le serveur de base de données conserve-t-il une seule connexion logique à partir de sa fin (ou) plusieurs connexions logiques

PS: Je comprends que certains de ces détails varient d'une base de données à l'autre, mais je veux savoir en général comment les implémentations populaires telles que Postgres, Mysql, Oracle, SQL Server et DB2 les implémentent

sql-servermysqlpostgresqloracleconnections
4
Ashok Koyi

Les bases de données prennent-elles en charge plusieurs transactions simultanément sur une seule connexion de base de données à partir du client?

Pour SQL Server, non.

Sinon, pourquoi pas? (car le multiplexage permettrait d'économiser sur la surcharge de ressources par connexion)

Cela compliquerait sérieusement le protocole réseau, qui doit être implémenté sur plusieurs plates-formes clientes, créant une source possible de bogues et de problèmes de performances.

Et la surcharge de ressources causée par plusieurs connexions est faible et largement atténuée par le pool de connexions, où un ensemble de connexions à longue durée de vie est partagé entre tous les threads d'un programme client.

10
David Browne - Microsoft

Oracle

C'est un fait peu connu, que dans Oracle, on peut avoir 0, 1 ou même plusieurs sessions dans la même connexion TCP.

Ceci est discuté dans le livre Expert Oracle Database Architecture (ISBN 978-1-4302-6299-2, Authors: Kyte, Thomas, Kuhn, Darl) in Chapter 5 - Oracle Processes.

https://books.google.com/books?id=NG4RpD8aLEIC&pg=PA17

Connexions vs sessions

Il surprend beaucoup de gens de découvrir qu'une connexion n'est pas synonyme de session. Aux yeux de la plupart des gens, ce sont les mêmes, mais la réalité est qu’ils n’ont pas à l'être. Une connexion peut avoir zéro, une ou plusieurs sessions établies sur elle. Chaque session est distincte et indépendante, même si elles partagent toutes la même connexion physique à la base de données. Une validation dans une session n'affecte aucune autre session sur cette connexion. En fait, chaque session utilisant cette connexion peut utiliser des identités d'utilisateur différentes! Dans Oracle, une connexion est simplement un circuit physique entre votre processus client et l'instance de base de données - une connexion réseau, le plus souvent. La connexion peut être établie avec un processus serveur dédié ou avec un répartiteur. Comme indiqué précédemment, une connexion peut avoir zéro ou plusieurs sessions, ce qui signifie qu'une connexion peut exister sans session correspondante.

Démo:

Connectez-vous à la base de données:

[Oracle@o71 ~]$ sqlplus bp/bp@\'localhost:1521/min18\'

SQL*Plus: Release 18.0.0.0.0 - Production on Thu Dec 27 21:20:03 2018
Version 18.4.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.

Last Successful login time: Thu Dec 27 2018 21:07:47 +01:00

Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0

SQL>

Dans une autre session, démarrée ailleurs, interrogez les sessions de BP:

SQL> select sid, process, port, paddr from v$session where username = 'BP';

       SID PROCESS                        PORT PADDR
---------- ------------------------ ---------- ----------------
       395 31251                         35298 0000000066E75338

Activez maintenant le suivi automatique dans la session d'origine:

SQL> set autotrace on

Et vérifiez à nouveau les sessions, depuis l'autre session:

SQL> select sid, process, port, paddr from v$session where username = 'BP';

       SID PROCESS                        PORT PADDR
---------- ------------------------ ---------- ----------------
       395 31251                         35298 0000000066E75338
       399 31251                         35298 0000000066E75338

SQL> !Sudo netstat -tanlp | grep 35298
tcp        0      0 127.0.0.1:35298         127.0.0.1:1521          ESTABLISHED 31251/sqlplus
tcp        0      0 127.0.0.1:1521          127.0.0.1:35298         ESTABLISHED 31253/oracleMIN18

Nous avons 2 sessions, utilisant les mêmes processus client et serveur et la même TCP également (et c'est la partie habituellement surprenante). Maintenant, si nous disconnect, mais quittons sqlplus en cours d'exécution lors de la première session:

SQL> disconnect
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0
SQL>

Et vérifiez à nouveau la base de données de l'autre session:

SQL> select sid, process, port, paddr from v$session where username = 'BP';

no rows selected

SQL> select spid from v$process where addr = '0000000066E75338';

SPID
------------------------
31253

SQL> !Sudo netstat -tanlp | grep 35298
tcp        0      0 127.0.0.1:35298         127.0.0.1:1521          ESTABLISHED 31251/sqlplus
tcp        0      0 127.0.0.1:1521          127.0.0.1:35298         ESTABLISHED 31253/oracleMIN18

SQL> select sid, process, port, paddr from v$session where paddr = '0000000066E75338';

no rows selected

Nous avons toujours le processus de serveur de base de données, nous avons toujours le processus client, nous avons toujours une connexion TCP entre eux, mais nous avons 0 sessions qui leur sont associées. Une fois que vous quittez sqlplus avec exit, c'est-à-dire lorsque les processus et la connexion se terminent:

SQL> exit
[Oracle@o71 ~]$

Et:

SQL> select spid from v$process where addr = '0000000066E75338';

no rows selected

SQL> !Sudo netstat -tanlp | grep 35298
tcp        0      0 127.0.0.1:35298         127.0.0.1:1521          TIME_WAIT   -

C'est donc possible, mais je n'ai jamais vu cela en pratique à part le livre ci-dessus et les démos construites sur cette base.

5
Balazs Papp

Le parallélisme auquel vous faites allusion au premier trimestre est survendu. Même lorsque vous pouvez faire des choses en parallèle, le système s'embourbe pour plusieurs raisons:

  • Frappez un mur de briques d'une ressource: CPU/réseau/E/S disque/etc.
  • Il y aura des "sections critiques" et d'autres verrouillages pour éviter de marcher les uns sur les autres. Pour "quelques" connexions/transactions/etc, ce n'est pas un gros problème. Mais même à quelques dizaines, le système commence à trébucher sensiblement sur lui-même.
  • Certaines applications multithreads frappent un mur de briques d'algorithme. Le tri est un exemple classique. Vous pouvez peut-être lancer une centaine de threads (et obtenir une accélération presque cent fois) pour calculer les éléments dans une grande liste, mais si vous avez besoin que l'ensemble de résultats soit trié, l'application pas pourra obtenir n'importe où près de l'accélération centuple dans cette phase. Et puis vous devez canaliser toutes les données en un seul flux pour les livrer!

Les bases de données sont plus faciles à concevoir si vous vous arrêtez à la condition requise: les clients séparés ne doivent pas marcher les uns sur les autres. Ensuite, au sein d'un même client, il est plus facile de se concentrer sur une seule chose à la fois.

En savoir plus sur KISS.

Quant à la couche TCP - Vous avez la possibilité de concevoir un routeur qui peut réaliser ce que vous suggérez. Vous pourriez faire des millions. Mais il appartient à un bas niveau, pas dans le moteur de base de données.

3
Rick James