Архитектура исполняемого файла проекта: подключение к СУБД и пул соединений

1. Сетевое взаимодействие клиентского приложения и СУБД

Любая современная реляционная база данных (PostgreSQL, MySQL, Microsoft SQL Server) в архитектуре информационной системы функционирует как независимый сетевой сервис. Исполняемый файл клиентского приложения (Desktop GUI, Web API Backend, консольная утилита) взаимодействует с СУБД по сетевому протоколу поверх стека TCP/IP.

Для того чтобы клиентская программа могла выполнить хотя бы один SQL-запрос, в операционной системе должен быть пройден сложный многоступенчатый процесс инициализации сетевого канала:

В отсутствие пула соединений шаги (1)–(3) повторяются на каждый запрос, отнимая от 80 до 200 миллисекунд процессорного времени и сетевых задержек. При высокой нагрузке сервер СУБД тратит все ресурсы на создание процессов и падает.

2. Строка подключения (Connection String) и её параметры

Connection String — это стандартизированная строка, содержащая полную метаинформацию, необходимую драйверу для установления физического сокета с базой данных.

postgresql://user:password@hostname:5432/dbname?sslmode=verify-full&connect_timeout=5

host=hostname port=5432 dbname=dbname user=user password=password sslmode=verify-full connect_timeout=5

Детальная анатомия параметров

• Driver / Scheme: определяет сетевой протокол (postgresql://, mysql://, sqlserver://).
• Host: сетевое имя хоста (DNS) или IP-адрес сервера (например, 127.0.0.1 или db.corp.internal).
• Port: номер сетевого порта, который слушает СУБД (PostgreSQL: 5432, MySQL: 3306, MS SQL: 1433).
• Database (dbname): конкретная база данных в инстансе СУБД, к которой привязывается сессия.
• User & Password: учетные данные пользователя базы данных для проверки прав.
• SSL Mode: режим шифрования трафика:
  • disable: шифрование отключено (трафик передается в открытом виде);
  • require: трафик шифруется, но подлинность сертификата сервера не проверяется (уязвимо к MitM);
  • verify-ca: проверяется, что сертификат подписан доверенным удостоверяющим центром (CA);
  • verify-full: максимальный уровень защиты: проверяется доверенная подпись CA и совпадение имени хоста с CN/SAN в сертификате.
• Connect Timeout: предельное время ожидания ответа сервера при рукопожатии (в секундах). Предотвращает зависание потоков приложения при сетевой изоляции.

3. Архитектура и принципы работы пула соединений (Connection Pool)

Пул соединений — это программный кэш открытых физических соединений с СУБД, управляемый клиентом или выделенным прокси-сервером (pgBouncer, HikariCP, c3p0, SQLAlchemy Pool).

# Python: контекстный менеджер гарантирует возврат в пул даже при падении!
with db_pool.connection() as conn:
    with conn.cursor() as cur:
        cur.execute("SELECT 1")
        result = cur.fetchone()

// C#: блок using гарантирует вызов Dispose() и возврат в пул
using (var conn = new NpgsqlConnection(connString)) {
    conn.Open();
    // выполнение операций
}

4. Синтаксис и форматы файлов конфигурации

В соответствии с методологией 12-Factor App (пункт III. Config), параметры подключения строго отделяются от исходного кода программы.

{
  "database": {
    "host": "127.0.0.1",
    "port": 5432,
    "name": "warehouse_db",
    "user": "app_user",
    "password": "SecurePassword123!",
    "pool": {
      "min_size": 2,
      "max_size": 5,
      "idle_timeout_sec": 300
    },
    "ssl": {
      "mode": "verify-full",
      "ca_path": "/etc/ssl/ca.crt"
    }
  }
}

database:
  host: "127.0.0.1"
  port: 5432
  name: "medical_records"
  user: "registry_svc"
  password: "RegistrySecretKey#2026"
  pool:
    min_connections: 2
    max_connections: 10
    idle_timeout: 300
  ssl:
    mode: "verify-full"
    ca_cert: "./certs/root-ca.crt"
    client_cert: "./certs/client.crt"
    client_key: "./certs/client.key"

DB_HOST=127.0.0.1
DB_PORT=5432
DB_NAME=college_portal
DB_USER=portal_admin
DB_PASSWORD=StrongPortalPassword2026!
DB_POOL_MIN=2
DB_POOL_MAX=8
DB_CONNECT_TIMEOUT=5
DB_SSLMODE=verify-full

5. Диагностика и логирование сетевых ошибок

При запуске исполняемого модуля первоочередной задачей является выполнение Health Check (тестового пинга) базы данных запросом SELECT 1;. Если СУБД недоступна, приложение должно перехватить исключение и записать событие в лог:

[2026-10-01 10:15:32.418] [ERROR] [DB_CONN] Failed to connect to PostgreSQL at 127.0.0.1:5432.
Error Code: ECONNREFUSED (SQLState: 08001).
Message: Connection refused. Is the database server running on host "127.0.0.1" and accepting TCP/IP connections?
Action: Retrying in 5 seconds (Attempt 1 of 3)...

6. Вопросы для самопроверки студентов