Пул подключений в backend‑разработке
(продолжение предыдущего поста)

Введение

→ Пул подключений — это техника повторного использования подключений с базой данных вместо создания нового соединения для каждого запроса клиента.
→ Это повышает производительность, снижает задержки и оптимизирует использование ресурсов в backend‑системах.
→ Широко применяется в приложениях, обрабатывающих множество параллельных запросов к базе данных.

Как работает пул подключений

→ При запуске приложения создаётся пул (набор) соединений с базой данных.
→ Каждый входящий запрос берёт соединение из пула, выполняет запрос и возвращает соединение после завершения.
→ Свободные соединения повторно используются для будущих запросов, что позволяет избежать затрат на открытие и закрытие новых подключений.

Почему пул подключений необходим

→ Создание и уничтожение подключений с базой данных требует значительных ресурсов.
→ Без пулирования высокий трафик может перегрузить базу данных запросами на подключение.
→ Пул подключений обеспечивает стабильность и эффективность при пиковых нагрузках.

Преимущества пула подключений

→ Повышение производительности → Сокращает время, затрачиваемое на установление новых подключений.
→ Оптимизация ресурсов → Ограничивает количество активных подключений.
→ Масштабируемость → Эффективно обрабатывает множество параллельных запросов.
→ Надёжность → Предотвращает перегрузку базы данных и исчерпание подключений.

Ключевые параметры пула подключений

→ Максимальное количество подключений → Определяет, сколько подключений может одновременно содержать пул.
→ Время ожидания для свободных подключений → Время, по истечении которого свободные соединения закрываются.
→ Срок жизни соединения → Максимальный срок существования соединения до его повторного создания.
→ Политика повторных попыток → Определяет, как обрабатываются неудачные соединения (повторные попытки или замена).

Распространённые инструменты и библиотеки

→ Node.js → pg-pool для PostgreSQL, mysql2 pool для MySQL.
→ Java → HikariCP и Apache DBCP для управления соединениями JDBC.
→ Python → Пул подключений в SQLAlchemy и поддержка пула в psycopg2.
→ .NET → Встроенное пул подключений в ADO.NET.

Рекомендации

→ Настраивайте размер пула исходя из ожидаемой нагрузки и возможностей базы данных.
→ Регулярно отслеживайте использование подключений и показатели производительности.
→ Корректно закрывайте неиспользованные соединения, чтобы предотвратить утечки.
→ Комбинируйте пулирование с логикой повторных попыток для повышения отказоустойчивости.
→ Избегайте длительных запросов, которые удерживают соединения занятыми.

Аналогия

→ Представьте ресторан с ограниченным количеством столиков (подключений).
→ Посетители (запросы) обслуживаются, когда освобождается столик, а после ухода гостей столик повторно используется.
→ Без пулирования каждому посетителю требовалось бы каждый раз готовить новый столик — это неэффективно и медленно.

Наглядно умножение матриц в нейронных сетях

Согласно внутренней утечке, Amazon Web Services уволила до 40% DevOps-инженеров, заменив их экспериментальной AI-системой автоматического управления инфраструктурой с целью снизить расходы и ускорить обслуживание облака. Новая AI-система вроде как способна автоматически исправлять ошибки IAM, восстанавливать виртуальные сети, перезапускать инстансы и даже откатывать неудачные деплои Lambda без участия человека.

Однако через несколько дней после запуска системы AWS столкнулась с масштабным сбоем, который затронул Snapchat, Roblox и другие крупные сервисы. Инженеры утверждают, что именно новая автономная система спровоцировала каскадные ошибки при синхронизации кластеров.

Amazon официально не комментирует ситуацию. Но по cлухам, внутри компании идёт обсуждение — стоит ли давать ИИ слишком много контроля над критической инфраструктурой.
https://80.lv/articles/amazon-allegedly-replaced-40-of-aws-devops-workers-with-ai-days-before-crash

В руководство по языку Java добавлены новые статьи:

Переменные volatile в многопоточных приложениях
https://metanit.com/java/tutorial/8.16.php

Атомарность и Atomics. Потокобезопасность без блокировок в многопоточных приложениях
https://metanit.com/java/tutorial/8.17.php

#java

Рабочий процесс Docker
(подробное описание в следующем посте)

Рабочий процесс Docker
(описание предыдущего поста)

#### Шаг 1: Написание кода приложения

Начните с создания вашего приложения с использованием предпочитаемого языка программирования (например, Node.js, Python или Java).
Убедитесь, что все зависимости проекта чётко определены в конфигурационных файлах, таких как package.json или requirements.txt.

#### Шаг 2: Создание Dockerfile

Dockerfile — это шаблон, определяющий, как будет собираться ваш образ.

Пример:

# Использование базового образа
FROM node:20

# Установка рабочего каталога
WORKDIR /app

# Копирование файлов проекта
COPY . .

# Установка зависимостей
RUN npm install

# Открытие порта приложения
EXPOSE 3000

# Команда для запуска приложения
CMD ["npm", "start"]

Этот файл гарантирует, что ваше приложение будет работать стабильно в любой среде.

#### Шаг 3: Сборка Docker-образа

Выполните команду для сборки вашего образа:

docker build -t myapp:latest .

Флаг -t присваивает вашему образу имя и версию. Docker считывает инструкции из Dockerfile и создаёт повторно используемый образ.

#### Шаг 4: Запуск Docker-контейнера

Используйте образ для запуска контейнера:

docker run -d -p 3000:3000 myapp:latest

Флаг -d запускает контейнер в фоновом режиме.
Флаг -p сопоставляет порт контейнера с портом вашего локального компьютера. Приложение теперь доступно локально по адресу localhost:3000.

#### Шаг 5: Управление контейнерами

- Список запущенных контейнеров:

  docker ps
  

- Остановка контейнера:

  docker stop <id_контейнера>
  

- Удаление контейнера:

  docker rm <id_контейнера>
  

- Удаление образа:

  docker rmi myapp:latest
  

#### Шаг 6: Использование Docker Compose (опционально)

Для приложений с несколькими контейнерами (например, приложение + база данных) используйте файл docker-compose.yml.

Пример:

version: '3'
services:
  app:
    build: .
    ports:
      - "3000:3000"
  db:
    image: mongo
    ports:
      - "27017:27017"

Запуск всех сервисов:

docker-compose up -d

#### Шаг 7: Публикация образов в Docker Hub

- Вход в Docker Hub:

  docker login
  

- Присваивание тега вашему образу:

  docker tag myapp username/myapp:v1
  

- Публикация в Docker Hub:

  docker push username/myapp:v1
  

Это позволяет другим пользователям (или вашему CI/CD конвейеру) загружать и развёртывать ваш образ.

#### Шаг 8: Развёртывание в продакшене

Используйте платформы вроде AWS ECS, Kubernetes или Docker Swarm для развёртывания в масштабе. Эти платформы загружают ваши образы и автоматически управляют оркестровкой контейнеров, сетью и масштабированием.

Студентам самого известного колледжа Екатеринбурга пригрозили отчислением. За отказ установить MAX

В Екатеринбурге студентам колледжа имени Ползунова угрожали отчислениями — под раздачу попали те, кто отказался устанавливать мессенджер MAX.

Один из учащихся рассказал, что 23 октября в их группе провели собрание. Тех, кто не захотел подключаться к новой соцсети, под диктовку заставили написать заявление об отчислении по собственному желанию.

Заведующая одного из отделений колледжа собрала все заявления и дала обучающимся время до понедельника. Для наглядности текст заявления даже написали на доске в аудитории.
https://www.e1.ru/text/education/2025/10/23/76088087/

Как LLM воспринимают мир
(описание в следующем посте)

Как LLM воспринимают мир
(описание к предыдущему посту)

Когда вы вводите фразу "Hello world" в ChatGPT или Claude, модель не обрабатывает эти буквы и пробелы так, как вы читаете этот пост прямо сейчас. Вместо этого она преобразует всё в числа посредством процесса, о котором большинство людей даже не задумывается.

Сначала происходит предварительная обработка. Текст нормализуется: символы Unicode, особенности пробелов и специальные символы очищаются и стандартизируются. Фраза "Hello world" превращается в формат, с которым модель может работать.

Затем наступает очередь токенизации. Здесь начинается самое интересное. Модель разбивает текст на токены, и существует несколько подходов к этому:

1. Посимвольная токенизация разбивает текст на отдельные символы. Фраза "Hello world" становится ["H", "e", "l", "l", "o", " ", "w", "o", "r", "l", "d"]. Этот метод прост, но неэффективен.

2. Пословная токенизация разбивает текст на целые слова. ["Hello", "world"]. Такой подход выглядит более чистым, но сталкивается с трудностями при обработке редких слов и создаёт огромные словари.

3. Подсловная токенизация — это то, что фактически используют современные LLM. GPT, Gemini, Claude — все они полагаются на этот метод. Фраза "Hello world" преобразуется примерно так: ["Hell", "o", "world"]. Этот метод обеспечивает баланс между эффективностью и гибкостью, обрабатывая редкие слова путём разбиения их на известные подсловные части.

Последний шаг — это присвоение идентификаторов токенов. Эти подсловные части сопоставляются с числами, например, [15496, 345, 995]. Каждый идентификатор токена соответствует вектору встраивания внутри модели. Именно эти векторы обрабатывает нейронная сеть.

Трехслойная нейронная сеть. Она состоит из трех основных слоев: входного, скрытого и выходного. Каждый слой включает несколько нейронов, которые соединены между собой с помощью весов (обозначены как W).

Основные элементы сети:
- Входной слой: Принимает входные данные P и передает их на первый скрытый слой.
- Скрытый слой: Выполняет обработку данных с использованием весов W1 и смещений b1. Результат обработки передается на второй скрытый слой.
- Выходной слой: Генерирует итоговый результат, используя веса W3 и смещения b3.

Формулы:
1. Для первого слоя: a1 = f1(W1p + b1).
2. Для второго слоя: a2 = f2(W2a1 + b2).
3. Для третьего слоя: a3 = f3(W3a2 + b3).

Обозначения:
- P — входные данные.
- W1, W2, W3 — матрицы весов для каждого слоя.
- b1, b2, b3 — смещения для каждого слоя.
- f1, f2, f3 — функции активации.

Фантомные чтения
(подробное описание в следующем посте)

#sql #mysql #postgresql #database

Фантомные чтения
(описание к предыдущему посту)

В PostgreSQL и MySQL возможно, что одинаковые запросы SELECT в рамках одной транзакции могут возвращать разные результаты.

Рассмотрим пример с базой данных, в которой работают два клиента. Клиент A начинает транзакцию и выполняет SELECT всех заказов с общей ценой > 100 долларов. Пока он продолжает выполнять другие запросы, клиент B вставляет в таблицу новый заказ и фиксирует изменения (COMMIT). Наконец, клиент A снова запрашивает заказы с общей суммой > 100 долларов, но на этот раз видит новую строку, добавленную клиентом B!

Допускается ли такое поведение, зависит от настроенного уровня изоляции.

По умолчанию PostgreSQL использует уровень READ COMMITTED, который допускает фантомные чтения. Отдельные запросы получают согласованное представление базы данных, но между запросами в рамках одной транзакции могут наблюдаться изменения, зафиксированные другими транзакциями.

Как и PostgreSQL, MySQL имеет четыре настраиваемых пользователем уровня изоляции. Использование строгого уровня, такого как SERIALIZABLE, предотвращает фантомные чтения, в то время как более свободные уровни, такие как READ COMMITTED, допускают их (по умолчанию в MySQL используется REPEATABLE READ).

Почему бы не установить везде уровень SERIALIZABLE? Всё дело в производительности! Более строгие уровни требуют большего количества блокировок и снижают производительность, в то время как более свободные уровни обеспечивают более высокую производительность за счёт возможных несоответствий.

#sql #mysql #postgresql #database

Переписанные на Rust версии GNU Core Utils (uutils) стали причиной проблем в недавно выпущенной Ubuntu 25.10.
Так, портированная на Rust команда «date» имела серьезные проблемы, из-за которых не срабатывали автоматические проверки обновлений Ubuntu.

Стоит отметить, что клон «date» на базе Rust проходит только 2 из 8 тестов утилиты — это 75% отказов. А некоторые другие клоны Core Utils на базе Rust показывают ещё худшие результаты.

Команда Ubuntu знала, что частота сбоев Rust «uutil» была настолько критической, когда они решили заменить хорошо проверенную GNU Core Utils. К счастью, эта проблема была исправлена.

Но учитывая большое количество известных сбоев тестов «uutils» на Rust — и тот факт, что эти существующие тесты охватывают лишь малую часть общей функциональности GNU Core Utils, которую эти версии Rust призваны заменить (то есть большинство отсутствующих функций и ошибок не будут обнаружены тестами), можно предположить, что это только начало проблем, с которыми Ubuntu столкнется в ближайшее время