💡 Полезные Советы

WAL (Write-Ahead Logging), или журналирование с упреждающей записью - это один из самых популярных и надежных механизмов работы баз данных. Его главная задача - обеспечить сохранность данных при сбоях (например, отключении электричества) и значительно ускорить работу при одновременном чтении и записи.

Чтобы понять WAL, давайте сравним его со старым классическим подходом.

Простая аналогия: Бухгалтерская книга
Представьте, что база данных - это огромная бухгалтерская книга, с которой работают несколько человек.

• Стандартный режим (Rollback Journal): Когда бухгалтер хочет изменить запись на странице 10, он берет чистый лист (журнал откатов), переписывает туда старые данные со страницы 10, прячет в сейф, а затем стирает старые данные в самой книге и пишет новые. Если в этот момент придет начальник и захочет почитать страницу 10, ему скажут: "Подождите, я еще не закончил писать!". Чтение блокируется записью.
• Режим WAL: Бухгалтер не трогает саму книгу. Он берет стикер (WAL-файл), пишет на нем новые данные и приклеивает поверх страницы 10. Если приходит начальник, бухгалтер говорит: "Читай страницу 10, а если там есть стикер - читай данные со стикера". В итоге бухгалтер может клеить новые стикеры, а начальник может одновременно читать книгу со стикерами. Никто никого не ждет. Периодически (например, ночью, когда никого нет) данные со стикеров аккуратно переписываются в саму книгу.

Как это работает технически?

В традиционном подходе каждое изменение напрямую модифицирует основной файл базы данных. Это медленно и требует строгих блокировок.

В режиме WAL процесс выглядит так:

• Запись: Когда вы обновляете или добавляете данные, база данных не трогает основной файл (db.sqlite3 или аналогичный). Вместо этого она дописывает изменения в конец специального файла - WAL-журнала (db.sqlite3-wal). Дописывать в конец файла (последовательная запись) жесткому диску гораздо проще и быстрее, чем искать нужное место в гигантском основном файле (случайная запись).
• Чтение: Когда кто-то делает SELECT-запрос, база данных сначала смотрит в основной файл, а затем сверяется с WAL-файлом. Если нужные данные были недавно изменены, она берет свежую версию из WAL.
• Чекпоинт (Checkpoint): Со временем WAL-файл разрастается. База данных автоматически (или по вашей команде) запускает процесс "чекпоинта" - она берет все накопленные изменения из WAL-файла и переносит их в основной файл базы данных. После этого WAL-файл можно перезаписывать заново.

Главные преимущества WAL

• Параллельность (Concurrency): Это главная фишка WAL. Читатели не блокируют писателей, а писатели не блокируют читателей. В веб-разработке это критически важно: пользователи могут просматривать сайт, пока фоновый процесс обновляет базу данных.
• Скорость записи: Как уже упоминалось, Append-only (запись только в конец файла) работает намного быстрее, особенно на классических HDD дисках, да и на SSD снижает износ.
• Надежность (ACID): Так как изменения сначала гарантированно записываются в лог на диск, при внезапном отключении сервера база данных после перезагрузки просто прочитает WAL-файл и применит изменения, которые не успели попасть в основной файл.

Есть ли у WAL минусы?

Да, идеальных решений не бывает:

• Сетевые диски: Режим WAL требует использования разделяемой памяти (тот самый файл *-shm). Это значит, что он не работает (или работает с риском поломки данных), если файл базы лежит на сетевой файловой системе (NFS, SMB). База и приложение должны быть на одном физическом сервере/контейнере.
• Немного замедляется чтение: Так как базе нужно проверять два места (основной файл и WAL), чтение может стать микроскопически медленнее, особенно если WAL-файл сильно разросся до чекпоинта.
• Много файлов: Вместо одного аккуратного файла у вас появляется три (.sqlite3, .sqlite3-wal, .sqlite3-shm).

Где это используется?

WAL - это не эксклюзив SQLite. Это фундаментальный концепт.

• PostgreSQL использует WAL в качестве основы своей архитектуры, не только для надежности, но и для репликации (передачи данных на резервные серверы).
• В MySQL (InnoDB) есть Redo Log, который по сути выполняет точно такую же функцию упреждающей записи.

Как включить через командную строку (SQLite CLI).

Если у вас установлена консольная утилита sqlite3, откройте терминал и подключитесь к файлу вашей базы данных (в Django по умолчанию это db.sqlite3):

sqlite3 db.sqlite3

Затем внутри консоли SQLite выполните команду:

sqlite> PRAGMA journal_mode=WAL;

В ответ консоль должна вывести слово wal. Выйти из утилиты можно командой .exit.

Дополнительная настройка для Django

Так как настройка постоянная, вам не обязательно менять settings.py в Django. Вы можете просто выполнить PRAGMA journal_mode=WAL один раз, и Django начнет работать с базой в режиме WAL.

Однако, если вы хотите, чтобы при создании базы на новом сервере Django сам пытался использовать WAL, вы можете передать опцию init_command в настройках подключения к базе данных (в settings.py):

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
        'OPTIONS': {
            # Этот запрос будет выполняться при каждом новом соединении
            'init_command': 'PRAGMA journal_mode=WAL;',
        }
    }
}

Как убедиться, что WAL работает?

Когда режим WAL включен и к базе данных происходит активное обращение, рядом с вашим файлом базы данных появятся два новых временных файла:

• db.sqlite3-wal - файл самого лога (Write-Ahead Log).
• db.sqlite3-shm - файл разделяемой памяти (Shared Memory).

Важно: Никогда не удаляйте эти файлы вручную во время работы приложения! Это может привести к повреждению данных. SQLite сам управляет их жизненным циклом.

Как вернуть стандартный режим?

Если по какой-то причине WAL вам не подошел (например, база лежит на сетевом диске без поддержки блокировок, что для WAL критично), вы можете вернуть стандартный режим (DELETE) командой:

PRAGMA journal_mode=DELETE;

Глоссарий.

• Django: Популярный фреймворк на языке Python для быстрой разработки веб-приложений.
• SQLite: Легковесная реляционная база данных, которая хранит все таблицы и данные в одном обычном файле на диске (часто db.sqlite3).
• WAL (Write-Ahead Logging / Журналирование с упреждающей записью): Современный механизм работы баз данных. При изменении данных они сначала быстро дописываются в специальный лог-файл, что позволяет другим пользователям продолжать чтение без блокировки базы.
• Rollback Journal (Журнал откатов): Классический (и более медленный) режим SQLite. При изменении данных старые значения копируются во временный журнал. Во время этого процесса база блокируется для других операций.
• PRAGMA: Специальная SQL-команда в SQLite, которая используется для изменения внутренних настроек и параметров базы данных (например, для переключения в режим WAL).
• Чекпоинт (Checkpoint): Процесс в режиме WAL, во время которого накопленные в лог-файле изменения массово переносятся в основной файл базы данных.
• .shm файл (Shared Memory): Временный файл разделяемой памяти, который SQLite создает рядом с базой в режиме WAL. Он нужен как "оглавление", чтобы несколько процессов могли быстро находить данные в лог-файле.
• Последовательная запись (Append-only): Добавление данных строго в конец файла (как в режиме WAL). Для жесткого диска это самая быстрая операция, так как не нужно тратить время на поиск нужного места на диске.
• Параллельность (Concurrency): Способность базы данных или приложения обрабатывать множество запросов (чтение и запись) от разных пользователей одновременно, не заставляя их ждать друг друга.
• ACID (Atomicity, Consistency, Isolation, Durability): Набор стандартов для баз данных, гарантирующий, что транзакции (изменения данных) будут выполнены надежно и не потеряются даже при сбое питания или критической ошибке сервера.
• Сетевая файловая система (NFS, SMB): Способ хранения файлов, при котором они физически находятся на другом сервере, а компьютер обращается к ним по локальной сети. Режим WAL крайне не рекомендуется использовать на таких системах из-за проблем с блокировками файлов.

Сетевые сокеты (Berkeley Sockets).
С точки зрения операционной системы, сокет - это дескриптор файла. В Unix-подобных системах "всё есть файл", и сокет не исключение. Это абстракция, которая позволяет программе читать и записывать данные в сеть так же просто, как в текстовый документ на диске.

Техническая формула: Socket = IP Address + Port + Protocol (TCP/UDP)
Дескриптор файла - это маленькое целое число, которое операционная система выдаёт процессу, когда тот открывает файл, сокет, канал, pipe, устройство или любой другой ресурс ввода‑вывода. Это идентификатор, через который программа взаимодействует с ресурсом.

История: Эпоха BSD

История Berkeley Sockets API - это фактически история того, как интернет стал интернетом. До 1983 года мир сетевых технологий напоминал Вавилонскую башню: каждый производитель железа (IBM, DEC, Xerox) имел свои протоколы, которые не умели "разговаривать" друг с другом.

В начале 80-х программирование под сеть было кошмаром. Если вы писали софт для мейнфрейма IBM, вы использовали одни системные вызовы; для машин DEC - другие. Не существовало единой абстракции "соединения".

Разработчики из Computer Systems Research Group (CSRG) в Университете Беркли, работая над релизом 4.2BSD, поставили цель: сделать работу с сетью такой же простой, как работу с файлами в Unix.

"Всё есть файл"

Гениальность Berkeley Sockets заключалась в адаптации концепции Unix "Everything is a file".

• Чтобы прочитать данные из файла, вы его открываете, читаете и закрываете.
• Билл Джой и его команда предложили делать то же самое с сетью.

Они ввели понятие дескриптора сокета. Сокет - это "конечная точка" (IP-адрес + Порт). Программисту стало неважно, как именно пакеты летят по проводам; ему достаточно было создать сокет и писать в него данные.

Популярность Berkeley Sockets была обусловлена двумя факторами:

• Открытость: Код BSD был доступен для изучения и копирования.
• Финансирование DARPA: Агентство продвигало TCP/IP как основной протокол для своей сети (предшественника интернета), и реализация Беркли была лучшей на рынке.

Как это работает  жизненный цикл сокета(Lifecycle)?

Жизненный цикл сокета - это последовательность системных вызовов, через которые проходит любое сетевое соединение. Каждый шаг меняет состояние сокета в ядре и определяет, что с ним можно делать дальше. Ниже - подробное, но компактное объяснение, ориентированное на разработчика, который хочет понимать, что реально происходит под капотом.

Чтобы понять, как работает жизненный цикл сокета, проще всего представить его как процесс установки телефонной связи в офисе. Есть "телефонный аппарат" (сам сокет), "номер" (IP и порт) и "оператор" (ядро ОС).

1. socket() - Покупка телефона
Процесс начинается с системного вызова socket(). На этом этапе вы просто сообщаете операционной системе: "Мне нужно устройство для связи".

• Что происходит: ОС выделяет ресурс и возвращает дескриптор (целое число).
• Параметры: Вы выбираете "тип" связи. Обычно это AF_INET (IPv4) и SOCK_STREAM (TCP, для надежности) или SOCK_DGRAM (UDP, для скорости).

2. bind() - Присвоение номера
У вас есть телефон, но у него нет номера. Вызов bind() привязывает сокет к конкретному адресу сетевой карты и порту.

• Для сервера: Это обязательно. Сервер должен "сидеть" на известном порту (например, 80 для HTTP), чтобы клиенты знали, куда стучаться.
• Для клиента: Обычно не вызывается вручную; ОС сама выделяет свободный случайный порт при подключении.

3. listen() - Перевод в режим ожидания (Только сервер)
Этот вызов превращает обычный сокет в пассивный. Сервер говорит системе: "Я готов принимать звонки".

• Очередь (backlog): В параметрах указывается размер очереди. Если 10 клиентов постучатся одновременно, а сервер занят, listen определит, сколько из них подождут, а кому сразу придет отказ.
• Что происходит, если очередь заполнена? Пришли 10 клиентов, они сидят в очереди в ядре ОС. Пришёл 11, ОС смотрит "мест нет". ОС либо просто игнорирует пакет (клиент отвалится по таймауту), либо отправляет ему ECONNREFUSED (отказ в соединении).

4. connect() vs accept() - Установка связи
Здесь пути клиента и сервера расходятся:

• connect() (Клиент): Клиент инициирует "трехэтапное рукопожатие" (TCP Three-way Handshake). Он отправляет запрос серверу.
• accept() (Сервер): Это блокирующий вызов. Сервер "засыпает" на этой строчке кода, пока не придет клиент. Как только соединение установлено, accept "просыпается" и создает новый отдельный сокет специально для этого клиента.
• Важно: Основной сокет продолжает слушать других, а новый - используется для общения с конкретным подключившимся пользователем.

5. send() / recv() - Разговор
Когда соединение установлено, начинается обмен данными.

• Байты, а не объекты: Сокеты ничего не знают о JSON, картинках или тексте. Они передают только сырые байты.
• Потоковый режим: В TCP данные могут прийти не целиком, а кусками. Разработчику нужно проверять, сколько байт реально получено, и "склеивать" их.

6, close() - Повесить трубку
Когда данные переданы, одна из сторон (или обе) вызывает close(). Это высвобождает дескриптор в ОС и закрывает порт.

WebSockets: Живое общение в браузере

Протокол HTTP (до версии 1.1 включительно) был "молчаливым". Клиент спросил - сервер ответил - соединение закрылось. Чтобы сделать чат, браузеру приходилось каждые 2 секунды отправлять пустые запросы (Polling). Это создавало огромную нагрузку на сервер и дикие задержки.
Протокол WebSocket (RFC 6455)
В 2011 году появился WebSocket. Его главная фишка - Full-Duplex (полный дуплекс). Это значит, что и клиент, и сервер могут одновременно слать данные друг другу по одному открытому каналу.
Почему HTTP не справлялся?

Чтобы понять ценность WebSocket, нужно осознать масштаб проблемы Polling (опроса).

Представьте чат на 1000 человек. При обычном опросе (Short Polling) сервер получает 500 запросов в секунду, даже если никто ничего не пишет. Каждый такой запрос - это:

• Установление TCP-соединения (3-way handshake).
• Огромные HTTP-заголовки (Cookies, User-Agent), которые весят больше, чем само сообщение "Привет".
• Закрытие соединения.

Long Polling (длинные опросы) немного спасали ситуацию: сервер держал запрос открытым, пока не появятся данные. Но это все равно был "костыль", съедающий ресурсы сервера.

Внутри канала: Что такое Фреймы (Frames)?

Когда соединение установлено, данные больше не передаются в виде текста с заголовками. Они упаковываются в бинарные фреймы.

Фрейм - это очень компактный конверт. В нем есть:

• FIN бит: Указывает, является ли этот кусок данных финальным или за ним последуют еще.
• Opcode: Тип данных (0x1 - текст, 0x2 - бинарные данные, 0x8 - закрытие соединения, 0x9 - пинг).
• Payload length: Размер данных. Для маленьких сообщений заголовок фрейма весит всего 2-10 байт. Сравни это с 500+ байтами заголовков HTTP.

Ключевые отличия для IT-специалиста

Сетевой сокет (L4): Это программный интерфейс (API) операционной системы. Когда ты открываешь сокет, ты говоришь ОС: "Выдели мне порт и отправляй все байты с этого IP-адреса моему приложению".

WebSocket (L7): Это протокол прикладного уровня. Он добавляет к "сырому" сокету правила: как поздороваться (Handshake), как зашифровать данные (Masking) и как делить поток байтов на понятные сообщения (Frames).

Когда и что выбирать?