На связи команда облачного провайдера Beget – сегодня мы расскажем, как можно сэкономить на хранении данных, когда их становится всё больше.

Мы с вами живем в цифровую эпоху, где ежедневно создается приблизительно 402,74 млн терабайт информации, а данные – один из ключевых ресурсов каждого бизнеса.

Изображения, видео, документы, пользовательские файлы, резервные копии – их объем постоянно растет: по статистике, неструктурированные наборы данных составляют 90% всей информации, генерируемой предприятиями, а ее размеры зачастую достигают терабайтов или петабайтов.

И вместе с этим, соответственно, увеличиваются требования к инфраструктуре и расходы на ее содержание.

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

В этих реалиях возникает задача – как сократить расходы на хранение данных и не потерять к ним доступ.

Расскажем о решении, которое может в этом помочь.

Когда серверу становится тесно

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

Однако не всей информации нужны ресурсы основного сервера – вот примеры данных, которые так хранить необязательно:

· резервные копии;

· архивы и старые версии файлов;

· логи и истории событий;

· изображения, видео и другой медиаконтент;

· документы, которые редко используются;

· выгрузки и результаты обработки данных;

· дистрибутивы, установочные файлы и образы;

· данные для долгосрочного хранения и аудита.

Ко многим из этих данных обращаются редко, а хранить их нужно постоянно.

Чтобы сэкономить на хранении и при этом сохранить быстрый доступ к информации, когда она понадобится, можно подключить S3 – безлимитное облачное объектное хранилище для работы с большими объемами неструктурированных данных.

С ним можно разделить вычисления и хранение: оставить на серверах только то, что действительно нужно приложению для работы, а большие объемы файлов, архивов и резервных копий вынести в объектное хранилище – такой подход позволяет увеличивать объем данных по мере роста бизнеса, не перестраивая основную инфраструктуру.

Что дает объектное хранилище

· Моментальное масштабирование – облачное хранилище S3 расширяется автоматически, загружайте столько данных, сколько потребуется.

· Надежность и доступность – при аренде S3-хранилища данные хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности.

· Гибкое управление – версионирование, настройка доступа и классы хранения позволяют контролировать, где и как хранятся данные.

· Доступ к данным 24/7 из любой точки мира и из любого браузера.

· Удобная модель оплаты Pay as you go – оплачивайте только тот объем, который используете.

В настоящее время S3 хранит сотни эксабайт данных в сотнях триллионов объектов, обрабатывая в среднем более 200 миллионов запросов в секунду.

Разберем конкретнее, какую пользу объектное хранилище может принести бизнесу.

S3 на практике: кто и как использует

Итак, объектное хранилище может пригодиться для:

· хранения бэкапов, отчетов, медиафайлов и другого контента отдельно от серверов – чтобы сэкономить и снизить риск потери данных при сбоях;

· архивирования – сохраняйте редко используемые документы, логи и старые версии файлов без нагрузки на основные диски;

· обмена данными между сервисами – можно организовать единое хранилище для микросервисов и упростить передачу файлов между ними;

· масштабирования проектов – увеличивайте объем хранимых данных без пропорционального расширения серверных дисков.

S3 используют более 398 тысяч компаний – и вот лишь несколько примеров результатов:

· производитель шин Apollo Tyres – на 90% снизил затраты на резервное копирование за 2 года на трех из семи своих заводов;

· платформа EZJobs – снизила затраты на 50% благодаря интеллектуальному многоуровневому хранению;

· маркетплейс Ozon – благодаря дедупликации в среднем сэкономил на обработке данных около 13% по всем бакетам;

· технологическая компания Bynder – сэкономила 65% затрат на хранение данных о клиентах благодаря системам интеллектуального многоуровневого хранения S3;

· финансовый маркетплейс “Сравни” – уменьшил затраты на инфраструктуру БД в 1,5 раза.

На примере этих и других компаний заметно, что объектное хранилище S3 помогает решать сразу несколько бизнес-задач – сокращать расходы на хранение, разгружать серверную инфраструктуру и масштабировать объем данных без сложных перестроек.

Если у вашего проекта большое количество данных и вы хотите оптимизировать расходы на их хранение, то создать объектное хранилище S3 в Beget буквально в один клик можно уже сейчас.

Заключение

Примерно 90% из генерируемых пользователями данных являются неструктурированными.

В этой ситуации S3-хранилище может помочь бизнесу хранить растущие объемы файлов отдельно от серверной инфраструктуры, не переплачивая за дисковые ресурсы и сохраняя быстрый доступ к нужной информации.

При этом экономия на хранении данных – далеко не единственная задача, которую могут помочь решить продукты Beget, например, вы также можете:

· развернуть производительный VPS с готовностью за 10 секунд и готовыми решениями для ваших задач;

· подключить мощные облачные базы данных для разработки сложных веб-сервисов и приложений;

· настроить сеть доставки контента для снижения нагрузки на сервер и увеличения скорости загрузки сайта;

· удобно управлять инфраструктурой – с Kubernetes;

· обеспечить контроль и прозрачность изменений – с Terraform.

А еще облако Beget – это:

· глобальный охват – выбирайте локацию серверов в России или Казахстане и будьте ближе к вашей аудитории;

· новейшее железо – мощные серверные решения на базе Amd Epyc с NVMe-дисками;

· надежность и стабильность – благодаря uptime 99,98% и дата-центрам Tier III (стандарт с защитой от аварийных ситуаций);

· бесплатные автоматические бэкапы – копии создаются раз в 2–5 дней и хранятся на двух независимых серверах в разных дата-центрах;

· универсальный интерфейс – единая панель для управления всеми облачными решениями;

· комфортный мониторинг с возможностью кастомизировать правила для отслеживания состояния серверов;

· защита от атак – серверы защищены на сетевом и транспортном уровне (L3/L4), а наша собственная разработка Syncookied обеспечивает защиту от SYN/ACK/DATA-флуда;

· функциональный API – управляйте серверами и доменами без необходимости заходить в панель управления.

Если у вас остались вопросы, вы хотите обсудить эту статью или просто пообщаться с коллегами по цеху и сотрудниками Beget, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся.

Также сейчас для новых пользователей мы начисляем 10% кешбэка за первое пополнение баланса – чтобы вы могли начать хранить данные еще выгоднее с самого первого дня.

Реклама. ООО «Бегет», ИНН 7801451618, erid: 2W5zFJqF2Y9

1. Классика всех времен: страница NSM

Традиционная и самая распространённая архитектура в OLTP-СУБД (PostgreSQL, Oracle) — слотированная страница, относящаяся к семейству NSM (N-ary Storage Model). Страница, как правило, имеет фиксированный размер, чаще всего 8 или 16 КБ (может настраиваться параметром БД), и делится на три логические области:

· Заголовок страницы — содержит метаданные: размер страницы, количество слотов, смещение до свободного пространства и флаги.

· Таблица слотов — массив записей фиксированной длины, каждая из которых хранит смещение (offset) до начала соответствующей строки. Слоты упорядочены по позиции строки в таблице.

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

Особенности работы с изменениями на уровне страницы:

При обновлении строки, если её новый размер превышает старый, на старом месте сохраняется указатель (forwarding pointer), а обновлённая запись перемещается в свободную область страницы (или даже на другую страницу, если свободного места недостаточно). Это порождает цепочки переадресации, которые могут замедлять чтение.

При удалении строки соответствующий слот помечается как недействительный (например, устанавливается флаг deleted или смещение становится отрицательным). Физическое освобождение места происходит позже — при сборке мусора (VACUUM в PostgreSQL) или при перестройке страницы.

Главный недостаток:

Для запросов, которые читают миллионы строк, но выбирают лишь 2–3 атрибута из 20, NSM необходимо просканировать всю страницу целиком. В результате в кэш CPU загружаются все атрибуты, включая ненужные. Это не только увеличивает время I/O, но и порождает промахи кэша (cache misses), поскольку полезные данные перемешиваются с не нужными.

2. Колоночная страница DSM:

Научная работа Джорджа П. Коупленда и Сетрага Н. Хошафяна «A Decomposition Storage Model» (ACM SIGMOD) [1] предложила кардинально иной подход к организации данных на странице, получивший название DSM (Decomposition Storage Model).

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

Преимущества на уровне страниц:

· Страница заполняется данными одного типа — это даёт значительный прирост в сжатии (RLE, дельта-кодирование, битовые карты) по сравнению с NSM-архитектурой.

· При сканировании одного-двух столбцов читается ровно столько страниц, сколько нужно для этих атрибутов, без загрузки не используемых в запросе колонок.

Обратная сторона:

Вставка или обновление строки требуют записи в страницы всех атрибутов, что превращается в доступ к множеству файлов и их соединение. Запрос SELECT * для ограниченного числа строк также вынужден выполнять дорогостоящее соединение страниц разных столбцов, что делает DSM неэффективной для OLTP.

Первоначально модель не получила широкого распространения именно из-за высокой стоимости сборки строк. Однако с ростом мощностей процессоров и объёмов оперативной памяти она стала основой для колоночных СУБД (Vertica, Greenplum, ClickHouse), где основная нагрузка — аналитические запросы.

3. PAX: гибридная модель данных

В 2001 году на конференции VLDB была представлена работа Анастасии Аламаки, Дэвида ДеВитта, Марка Хилла и Муниратнама Сивакумара «Weaving Relations for Cache Performance» [2], в которой авторы предложили комбинированный подход — PAX (Partition Attributes Crosswise).

Ключевая идея модели:

Страница остаётся целостной (содержит все атрибуты таблицы, как в NSM), что позволяет избавиться от дорогостоящих соединений файлов данных. Но внутри страницы данные разбиты по атрибутам: все значения первого атрибута собираются в непрерывный мини-блок. Следом идёт мини-блок второго атрибута, затем третьего, и так далее. В начале страницы располагается каталог (directory), указывающий смещение и размер каждого мини-блока.

Как происходит выборка данных:

Для запроса, выбирающего два столбца, СУБД обращается к странице и читает только те два мини-блока — остальные не попадают в кэш процессора, что снижает количество промахов.

Обновление всей строки не требует записи в отдельные файлы (как в DSM) — достаточно перезаписать соответствующие мини-блоки внутри одной страницы.

4. Современные реализации на основе PAX

Apache Parquet

Прямой наследник PAX. Файл разбивается на Row Groups (группы строк, типично 128 МБ – 1 ГБ), каждая из которых действует как крупная «страница» PAX. Внутри Row Group данные организованы по Column Chunks — это и есть мини-блоки разных атрибутов, только теперь они могут быть сжаты независимо друг от друга. Parquet также добавляет индексы и статистику на уровне Column Chunk (min, max, null count), что позволяет при сканировании пропускать целые блоки без разжатия.

Apache ORC (Optimized Row Columnar)

Аналог Parquet, используемый в Hive, Presto и Trino. Внутри ORC-файла выделяются Stripes (полосы), которые выполняют ту же роль, что и Row Groups в Parquet. Внутри Stripe данные хранятся по колонкам с добавлением индексов и словарей. По сути, это тоже PAX, но с более агрессивным сжатием и встроенной фильтрацией.

5. FastLanes — PAX, оптимизированный под SIMD и GPU

PAX-архитектура значительно улучшила предыдущие модели хранения данных, но она не учитывала характеристики процессора. Именно в этом направлении происходит дальнейшее развитие архитектуры хранения данных. Петер Бонч, учёный из исследовательского центра CWI (Нидерланды), предложил новый формат FastLanes, который оптимизирует хранение данных под возможности современных процессоров.

Файл FastLanes состоит из двух главных компонентов: Footer (футер) и Data (данные). Футер содержит метаданные, описание данных и их местонахождение в файле и может храниться отдельно от блока «Данные».

На верхнем уровне блок «Данные» повторяет архитектуру PAX: данные делятся на группы строк и атрибуты. В отличие от существующих типов файлов, в FastLanes группы строк содержат количество записей, кратное 1024. Это позволяет избежать материализации данных в основной памяти и выполнять всю работу на уровне процессора. Следующим важным нововведением является использование сжатия LWC (Light-Weight-Compression). Вместо тяжеловесных алгоритмов по типу Zstd, которые не позволяют распараллелить обработку данных, применяются FSST, DICT, ALP при каскадном (рекурсивном) применении которых достигается уровень сжатия Snappy за более короткий промежуток времени [3]. Кроме этого, для каждой колонки данных могут применяться разные операторы кодирования. Сжатые данные хранятся в сегментах, в которых кроме самих данных хранятся смещения на отдельные вектора, что позволяет читать данные на уровне одного вектора вместо целого блока, как в старых форматах.

Когда данные читаются из оперативной памяти в процессор, закодированный вектор, содержащий 1024 значения, разжимается и полностью помещается в кэш процессора. Напротив, старые форматы файлов не только используют непараллельные алгоритмы сжатия, но и применяют их к целым Row Group, что влечёт за собой использование основной памяти и уменьшение скорости обработки [3].

Использованные источники:

1. Copeland G.P., Khoshafian S.N. A Decomposition Storage Model. Proceedings of ACM SIGMOD, 1985.
2. Ailamaki A., DeWitt D., Hill M., Sivakumar M. Weaving Relations for Cache Performance. Proceedings of VLDB, 2001.
3. Boncz P., Afroozech A., et al. The FastLanes File Format: specification.

Разбираем три расследования — пропавшую запись в базе, три процента сообщений, терявшихся только на чистой машине, и гонки в биллинге, которые видит одна поддержка. У всех трёх разные предметные области и одна общая методика поиска невоспроизводимых багов.

Отсутствие закономерности само по себе является находкой: если сбой не привязан ни к шарду, ни к клиенту, ни к времени суток, это указывает на гонку, а не на данные.

Когда воспроизвести дефект синтетически нельзя, остаётся пассивная телеметрия в продакшене и последовательное отсечение гипотез данными.

Счётчики на каждом слое находят виновника быстрее логов: разрыв между двумя соседними числами прямо называет слой, в котором теряются сообщения.

Вежливый тест, который шлёт запрос и ждёт ответа, скрывает целый класс ошибок пакетирования. Пачечный тест их обнажает.

Отсутствие ошибок не доказывает, что дефект исправлен. Доказательством служит положительный сигнал: сработавшее предупреждение о том, что опасные условия возникли, а сбоя при этом не случилось.

Случай первый: запись, которой не могло не быть

Управляющий слой Tailscale разбит на шарды, у каждого своя база SQLite, и обращается к ней ровно один процесс. Такой однописательный режим — именно то, для чего SQLite и предназначен, что делает дальнейшее особенно неприятным.

Резервное копирование снимало полную копию базы каждые несколько минут и складывало файл в объектное хранилище. Работало это без единого происшествия с начала 2023 года, пока конвейер, читавший резервные копии, не сообщил об ошибке. Проверка встроенной командой контроля целостности подтвердила худшее: база повреждена.

Первый случай сочли единичным. Базу починили, причину не нашли. Потом это повторилось. И ещё раз. Всего до устранения первопричины набралось 19 отдельных инцидентов за полгода, и каждый означал простой: процесс на шарде останавливался, пока базу чинили или восстанавливали. На ранних инцидентах простой превышал час, и всё это время у клиентов на шарде не работали консоль администратора и API.

Почему он не поддавался обычным приёмам

Дефект сопротивлялся всем стандартным подходам сразу:

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

Расписания у инцидентов тоже не было: они случались то через часы, то через недели. Между октябрём и декабрём наступила шестинедельная тишина, после которой повреждения вернулись.

Команда сделала два шага, которые и составляют суть этой истории. Купила контракт поддержки у разработчиков SQLite, получив прямой доступ к людям, написавшим саму базу. И методично составила список гипотез, отсекая их данными, а не рассуждениями. В списке были сломанные блокировки при закрытии файла, неверная работа с памятью, принадлежащей базе, и обращение из нескольких потоков при отключённой потокобезопасности. Каждый инцидент приносил данные, каждая гипотеза отпадала по очереди.

Улика: транзакция, которой не стало

Пока первопричину искали, платформу надо было держать живой. Команда автоматизировала жёсткую остановку при обнаружении повреждения, поставила монитор, непрерывно проверявший целостность резервных копий, и переписала инструкции по восстановлению. Время восстановления упало ниже часа.

А затем построила конвейер журналирования транзакций. Идея простая: писать каждый изменяющий базу запрос в отдельный журнал. Поскольку писатель один, а транзакции сериализуемы, история изменений линейна и детерминирована, и её можно проиграть поверх последней заведомо целой копии, обойдя повреждённые страницы. Приём годится там, где порядок фиксаций известен: при единственном писателе он получается сам собой. Наивный журнал запросов на многописательной базе этого не даёт, потому что конкурентные транзакции переплетаются и без явного порядка фиксаций проигрывание не восстановит то же состояние.

Конвейер сработал и выдал улику. В двух инцидентах журналы не проигрывались чисто: данные, записанные и зафиксированные одной транзакцией, оказывались необъяснимо невидимы для последующих. Запись исчезла бесследно и без единой ошибки.

Этого не может быть. В сериализуемой однописательной базе зафиксированная запись не может пропасть. Значит, виноват слой с достаточной конкурентностью, чтобы такое спрятать, а такой слой ровно один — контрольные точки.

Шестнадцатилетняя гонка

SQLite с журналом предзаписи работает с двумя файлами. База — это набор страниц; при изменении данных новые страницы пишутся не в основной файл, а сначала в журнал. Позже контрольная точка переносит их в базу. Обычно момент переноса SQLite выбирает сам, но Tailscale управляла контрольными точками вручную, чтобы снимать быстрые согласованные копии. Именно этот нестандартный, хотя и полностью документированный выбор и вывел их на дефект.

Метрики во время инцидентов показывали, что SQLite сообщает о переносе большего числа страниц, чем в журнале вообще было. Разработчики базы как раз готовили инструмент для этого слоя: обёртку над виртуальной файловой системой, которая пишет дополнительные трассировочные журналы. Обёртку развернули в продакшене, и ждать пришлось недолго.

Журналы показали редкую гонку данных (race condition) между контрольной точкой и пишущей транзакцией. Если запись происходит в определённый момент работы контрольной точки, та сбивается: считает часть страниц перенесёнными в основной файл, хотя перенос не состоялся. Данные теряются навсегда, а страницы, которые на них ссылаются, например индексные, записываются как ни в чём не бывало. Файл становится структурно повреждённым, что проверка целостности всё это время и фиксировала.

Дефекту дали имя по сбросу журнала предзаписи и оценили его возраст минимум в шестнадцать лет. Он прожил так долго именно из-за редкости, это классический heisenbug: чтобы поймать его в тестовой среде, разработчикам пришлось дописать код, вызывающий гонку намеренно.

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

Настоящего повреждения не было. В ту же версию попала оптимизация, слегка изменившая округление при переводе текста в число с плавающей точкой, а Tailscale хранила метки времени высокой точности текстом и превращала их в числа в вычисляемом столбце. Индекс по вычисляемому выражению перестал соответствовать новому результату вычисления, и проверка целостности честно назвала это повреждением. Канареечные шарды дефект пропустили просто потому, что на них не оказалось меток времени, попадающих под изменённое округление.

Разбирали это с трёх сторон сразу. Разработчики SQLite отозвали версию целиком и выпустили 3.51.3, содержавшую только исправление гонки. Tailscale перешла на хранение меток времени целыми секундами, поскольку перевод текста в целое число однозначен. А в 3.53.0 появилось автоматическое восстановление таких индексов, чтобы проблема не возникала впредь.

Главный урок этого эпизода:
Канареечная выкатка проверяет только те формы данных, которые в канарейке есть. Если на канареечных узлах нет тех же значений, что в проде, канарейка не подтверждает ничего. Это касается и обновлений самой базы, драйверов и инструментов миграции, а не только кода приложения.

Как доказали, что дефект действительно исправлен

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

Логика прямая: если предупреждение сработает, а база останется целой, значит, исправление сработало ровно там, где раньше был бы инцидент. Ждали два месяца. Предупреждение сработало, подтвердив, что условия для гонки в их среде действительно возникают. С того момента прошло ещё четыре месяца без единого происшествия с базами.

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

На ноутбуке автора всё воспроизводилось идеально: сто тысяч строк на входе, сто тысяч на выходе. Это расхождение и было первой уликой — тест проверял не то, что делает продакшен.

Сменить машину раньше, чем код

Первый час, по его собственному признанию, ушёл впустую: менялись и бинарник, и машина, и профиль нагрузки разом, а выводов это не давало. Дальше автор поменял ровно одну переменную: взял чистый сервер с тем же бинарником и тем же скриптом нагрузки. Потери появились снова, 97 128 строк из ста тысяч. Среда меняла вероятность проявления, но не сам факт дефекта, а чистая машина без истории и без накопленных настроек работает как микроскоп для ошибок синхронизации.

Считать, а не логировать

Дальше нужен был не ещё один прогон, а способ понять, на каком слое теряются сообщения. Логи рассказывают истории, счётчики складываются. Автор расставил счётчик на каждом слое: клиент считает отправленные строки, сервер считает разобранные переводы строки, сервер считает отправленные ответы, клиент считает полученные ответы. Один прогон, четыре числа, и разрыв между соседними прямо называет виновный слой.

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

Виновником оказалась одна строка: сервер отправлял по одному ответу на каждое чтение, а не на каждую разобранную строку.

TCP — это поток байтов, а не очередь сообщений. Вызов чтения не имеет понятия о том, что такое одно сообщение в вашем протоколе. Ядро вправе слить десяток сообщений в один сегмент, и одно чтение заберёт все десять, а ответ уйдёт один.

Вежливый локальный тест отправлял сообщение, дожидался подтверждения и отправлял следующее. Одно сообщение на сегмент — дефект спал. Нагрузка на стенде шла пачками, тысячами сообщений в секунду, ядро их группировало, одно чтение проглатывало сотню строк.

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

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

Третий сюжет про биллинг кредитов на бессерверном Postgres, где транзакции по условиям задачи были недоступны. Автор наткнулся на четыре гонки, разберём две самые показательные. Все они, по его собственной формулировке, относятся к тому сорту дефектов, которые не показываются в тестах и показываются в почте поддержки.

Классический двойной расход

Наивная версия, которую пишут первой:

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

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

Одиночный UPDATE в Postgres атомарен. Не хватило баланса — условие не совпало, вернулось ноль строк, и вы точно знаете, что списание не произошло. Транзакция для этого не нужна вовсе. Приём обобщается: перенесите инвариант в условие выборки, и запись просто не случится, когда инвариант нарушен.

Вебхук, доставленный дважды

Платёжные провайдеры повторяют доставку уведомлений при таймаутах, пятисотках и сетевых сбоях, а иногда дублируют событие и в штатном режиме. Если обработчик начисляет кредиты, доставка «хотя бы один раз» означает начисление хотя бы один раз.

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

Деталь, которую стоит забрать отдельно: уникальный индекс под эту схему должен быть частичным. Начисления от администратора приходят с произвольным идентификатором из скрипта, и глобальный уникальный индекс рисковал бы столкнуть их друг с другом или с идентификатором операции другого типа. Приветственные начисления идут вообще без идентификатора, и с ними коллизии не будет в любом случае: Postgres не считает два пустых значения равными. Ограничение индекса двумя типами операций от платёжного провайдера держит проверку уникальности ровно там, где она нужна.

Что из этого складывается

Первые два расследования дают общую методику поиска, и она изложена ниже. Третий случай стоит особняком: это не детектив, а набор приёмов, которые убирают целый класс гонок ещё на этапе проектирования, до того как искать станет нечего.

Что забрать с собой

Общего у трёх расследований больше, чем различий. Во всех трёх случаях проверка была написана в форме, которая не воспроизводит реальность: последовательный запрос вместо пачки, одиночный вызов вместо конкуренции, одна машина вместо двух. И во всех трёх дефект спокойно проходил через тесты, а в случае с SQLite прожил так шестнадцать лет.

Соседний сюжет про то, как тесты перестают отражать реальность, разбирали в материале о том, почему статичные моки убивают тестирование.

Полезнее всего здесь дешёвые привычки. Счётчик на границе каждого слоя ставится за час. Пачечный клиент пишется за вечер. Датчик, доказывающий исправление положительным сигналом, добавляется одной строкой в драйвер. Всё это стоит несопоставимо меньше, чем полгода расследования.

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

Возьмите самый подозрительный сервис и запустите по нему пачечный тест вместо последовательного. Это самый дешёвый способ узнать, какой из ваших дефектов сейчас спит.

Это главная особенность работы с отсутствующими значениями: ошибок нет, есть тихо неправильные числа. Разбираем, откуда они берутся в фильтрах, в арифметике, в агрегатах и в соединениях, и какими операторами это лечится.

Отправная точка одна: NULL — не значение, а отметка «неизвестно». Неизвестность распространяется дальше по всему выражению: через сравнения, арифметику, склейку строк, агрегаты, оконные функции и условия отбора. Результат при этом строго определён правилами языка, он просто может не совпасть с тем, что вы имели в виду.

В SQL три логических исхода, а не два: истина, ложь и неизвестность. Условие отбора оставляет только строки с истиной, поэтому неизвестность отбрасывается наравне с ложью.

Сравнение = NULL не почти верно, а отвечает на другой вопрос. Для проверки на отсутствие есть отдельные операторы, которые сравнением не являются.

Одно значение NULL в списке для NOT IN обнуляет всю выдачу целиком, а не сужает её.

Соединение по равенству отбрасывает строки, где ключ отсутствует с обеих сторон, и то же самое делает проверка уникальности.

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

Три логических исхода вместо двух

Начнём с простого случая. В таблице клиентов у одного из них не заполнен телефон, и это прямо видно глазами. Запрос находит ноль строк:

Условие phone = NULL спрашивает: «равно ли это неизвестное значение тому неизвестному значению?» Ответить на такое нельзя, поэтому для каждой строки возвращается неизвестность, включая ту самую строку с пустым телефоном. А отбор оставляет только строки, где условие истинно. Неизвестность не проходит ровно так же, как не прошла бы ложь.

Правило действует единообразно: NULL = NULL тоже не истина, а неизвестность. Отсюда и главный вывод — оператор равенства нельзя «подправить», чтобы он здесь заработал. Он не почти прав, он отвечает на другой вопрос.

В Postgres это проверяется одной строкой. Что вернёт такое выражение?

Оба внутренних сравнения неизвестны, поэтому внешнее сравнивает неизвестность с неизвестностью и тоже даёт неизвестность. Операторы сравнения возвращают NULL, если хотя бы одна сторона неизвестна. Именно поэтому в языке есть отдельный оператор проверки на отсутствие: узнать, равны ли две неизвестности, нельзя, а узнать, является ли значение неизвестным, можно.

Как ведут себя И, ИЛИ и НЕ

Логические связки тоже работают в трёх значениях, и запомнить стоит два исключения:

То есть ИЛИ всё ещё истинно, если истинна вторая сторона, а И всё ещё ложно, если ложна вторая сторона. Всё остальное с участием неизвестности схлопывается в неизвестность.

Последствия неочевидны. Вот запрос, который отбрасывает строку, которую вы почти наверняка хотели оставить:

В обычной двузначной логике «активно или не активно» — тавтология, утверждение, истинное при любом значении. В SQL это не так.

Операторы, которые никогда не возвращают неизвестность

Лечится это выходом из трёхзначной логики. Сначала решите, что NULL означает в вашей предметной области, а потом скажите это явно:

Проверки IS TRUE, IS NOT TRUE, IS FALSE, IS NOT FALSE и IS UNKNOWN никогда не возвращают неизвестность, поэтому строку не потеряют.

Аналог того же для равенства — IS NOT DISTINCT FROM. Обычное равенство спрашивает, известно ли, что значения совпадают. Этот оператор спрашивает, одно ли это значение, обращаясь с отсутствием как с полноценным состоянием. Две неизвестности неразличимы, поэтому предикат истинен.

Где это пригодится:
Соединение по условию равенства отбрасывает строки, где ключ отсутствует с обеих сторон. Если два отсутствующих ключа должны считаться совпадением, замените равенство на IS NOT DISTINCT FROM. То же касается проверок уникальности и условий отбора, где «отсутствует» должно означать «отсутствует», а не «неизвестно».

Ловушка NOT IN, из-за которой пропадает вся выдача

Это самый дорогой из всех эффектов, потому что он не сужает результат, а стирает его целиком. Операторы IN и NOT IN разворачиваются в цепочки сравнений, а NOT IN — в цепочку через И:

Разберём оба исхода. Если значение совпало с одним из перечисленных, срабатывает то самое правило «И спасает ложь справа», и выражение честно ложно. Если не совпало ни с одним, множитель со сравнением с пустым значением делает всё выражение неизвестным.

Для условия отбора разницы между этими исходами нет: оно оставляет только истину, а ложь и неизвестность отбрасывает одинаково. Поэтому итог один — если в списке или в подзапросе есть хотя бы одно отсутствующее значение, NOT IN не вернёт ни одной строки. Никакой ошибки при этом не будет.

Обычный IN ведёт себя мягче, поскольку разворачивается в цепочку через ИЛИ: совпадение остаётся истиной независимо от того, что ещё есть в списке. В простом условии отбора пустое значение в списке вообще ничего не меняет: несовпавшая строка отсеется что при неизвестности, что при лжи. Разница вылезает там, где результат сравнения используется дальше: под отрицанием, в выражении CASE или в ограничении целостности.

Надёжная замена — NOT EXISTS, который работает через равенство внутри условия отбора и потому никогда не трактует сравнение с отсутствующим значением как совпадение. Тот же смысл выражает антисоединение, которое вдобавок часто даёт лучший план:

Вычистить отсутствующие значения из подзапроса тоже можно, но это помогает, только если вы уверены, что их следует игнорировать. Вариант с NOT EXISTS делает это намерение явным, а не подразумеваемым.

Арифметика: одно значение NULL обнуляет строку

Любая арифметическая операция с участием отсутствующего значения даёт отсутствующее значение. Сложение, умножение, деление, модуль, возведение в степень — результат один.

В отчётах это выглядит как пустые ячейки, а в обновлениях данных как стёртые колонки. Классический пример, который каждый когда-нибудь писал:

Подставлять значение по умолчанию нужно в той точке, где вам известно правило предметной области, а не механически везде. В разборе Кристофера Уинслетта из Crunchy Data приводится удачная иллюстрация: отсутствующее количество почти всегда означает ноль, отсутствующая ставка налога тоже, а вот отсутствующая цена нулём не является и должна оставаться неизвестной, пока её кто-нибудь не заполнит.

Агрегаты и оконные функции считают не то, что кажется

Здесь отсутствующие значения ведут себя иначе, чем везде: агрегаты их пропускают. Функция COUNT(*) считает строки, а COUNT(колонка) — только непустые значения; SUM, AVG, MIN и MAX пропускают пустые входы.

У товара с двумя незаполненными оценками среднее и сумма пусты, а число строк равно двум. Отсюда практическое правило, которое экономит часы разбирательств с аналитикой: среднее — это сумма, делённая на количество непустых значений, а не на количество строк. Смешивать SUM(x) / COUNT(*) и ожидать совпадения со средним нельзя.

Оговорка про типы тоже важна: если сумма и счётчик целочисленные, деление усечёт дробную часть. Шесть, делённое на два, случайно даст ровно три, а оценки 5, 1 и 2 дадут при целочисленном делении двойку вместо 2,67.

Где ломаются оконные функции

Суммирование и усреднение в окне пропускают отсутствующие значения так же, как при группировке, а ROW_NUMBER считает строку в любом случае. Расхождение начинается у функций, которые смотрят в конкретную позицию окна: LAG, LEAD, FIRST_VALUE, LAST_VALUE и NTH_VALUE.

Такая функция возвращает то, что лежит в запрошенной позиции. Если там пусто, результат пуст. Ближайшее реальное значение она не ищет, и на рядах измерений с пропущенным отсчётом это даёт разрывы там, где ожидалась непрерывность.

Проверка чужого запроса, включая сгенерированный

Всё описанное складывается в одну проблему: запрос, который отработал, прошёл только проверку грамматики. База ловит опечатку в имени таблицы. Она не ловит суммирование не той колонки, соединение, задваивающее строки, и фильтр, поставленный не на том этапе. Каждая из этих ошибок — синтаксически корректный SQL.

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

Проверка первая: посчитайте строки до того, как поверите сумме

Задача звучала как «чистая выручка по завершённым заказам». Полученный запрос:

Он отрабатывает и возвращает 1830. Правильный ответ 1330, и это легко проверить руками: валовая сумма одиннадцати завершённых заказов равна 1605, возвраты составляют 275.

Виновато соединение. Два заказа возвращались частями, по две записи на каждый, поэтому одиннадцать строк превращаются в тринадцать, а сумма по заказам считает эти два заказа дважды: 2105 вместо 1605. Лишние 500 — это ровно стоимость задвоенных заказов. Явление называется размножением строк: соединение множит строки всякий раз, когда ключ на другой стороне встречается больше одного раза.

Проверка стоит двух запросов:

Одно это сравнение всё решает. Второе число выросло, значит, соединение размножило строки, и любая сумма или среднее по колонкам левой таблицы под подозрением. Число совпало — соединение безопасно, идём дальше.

Проверка вторая: ищите отсутствующие значения в каждом фильтре

Следующая просьба звучала как «та же выручка, но без служебных аккаунтов», и запрос получился такой:

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

Что забрать с собой

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

Самый надёжный способ не разбираться со всем этим каждый раз — не хранить отсутствующие значения там, где они не нужны. Если колонка обязана иметь значение, скажите это в схеме. Ограничение NOT NULL выглядит формальностью ровно до первого расследования, почему выручка в отчёте оказалась на пятьсот единиц больше настоящей.

Материалы разбора: почему сравнение с NULL никогда не срабатывает, поведение NULL в вычислениях Postgres и проверка сгенерированного SQL до того, как поверить числу.

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

Оба симптома дают один и тот же виновник — постраничная выдача через OFFSET. И оба чинятся одним переходом, причём переписывать приходится только слой выдачи.

Пагинация — это способ отдать большую коллекцию по частям. Вариантов ровно два. Offset-пагинация просит базу пропустить N строк и вернуть следующие двадцать. Курсорная (её же называют keyset) запоминает последнюю отданную запись и просит всё, что идёт после неё.

Стоимость OFFSET растёт линейно: на таблице в 1,2 млн строк выборка со смещением в миллион занимает 2,4 с против 3 мс у курсора.

Под параллельными вставками и удалениями OFFSET выдаёт дубликаты и пропуски, потому что нумерация строк сдвигается между запросами.

Курсор не поддерживает переход на произвольную страницу, поэтому для админок и таблиц с кнопкой «страница 47» offset остаётся правильным выбором.

Лимиты запросов на счётчике в памяти инстанса не работают: при десяти инстансах настроенные 100 запросов в минуту превращаются в 1000.

Скользящее окно на сортированном множестве Redis и атомарном Lua-скрипте занимает пятнадцать строк и снимает гонку без распределённых блокировок.

Результат на спокойной базе одинаковый. Поведение под ростом данных и параллельными записями — принципиально разное.

Offset ломается двумя разными способами

Про первый знают почти все, про второй вспоминают уже после инцидента.

Он линейно замедляется

PostgreSQL, MySQL и SQLite не умеют «перепрыгнуть» через строки. При OFFSET 100000 база честно читает сто тысяч строк и выбрасывает их, чтобы отдать следующие двадцать. Стоимость запроса растёт вместе со смещением.

Автор разбора замерил это на таблице в 1,2 млн строк в PostgreSQL 15 с холодным кешем и обычным btree-индексом по id:

Курсорный вариант на той же таблице держал 3 мс на любой глубине. Разница объясняется сложностью: поиск по индексу это O(log n), а большое смещение — O(offset). На пятидесятитысячной странице пользователь ждёт больше двух секунд вместо миллисекунд.

Он врёт, когда в таблицу пишут

Этот сценарий коварнее. Пользователь загрузил первую страницу с двадцатью записями, отсортированными от новых к старым. Пока он читал, в таблицу добавились три новые записи. Запрос второй страницы с OFFSET 20 вернёт часть того, что уже было на первой: всё сдвинулось на три позиции.

Клиент получает дубликаты. При удалении записей картина обратная — часть строк он не увидит никогда, потому что они проскочили мимо границы страницы. У автора статьи на этом сломалась синхронизация у клиента: задание дважды загрузило одни и те же двадцать заказов, и три письма в поддержку ушло на то, чтобы понять, что виновата пагинация, а не код клиента.

Курсор от этого защищён по построению. Курсор — это последняя фактически полученная запись, поэтому «всё, что после неё» остаётся верным независимо от того, сколько строк вставили или удалили между запросами.

Как выглядит курсор в коде

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

Обратите внимание на per_page + 1. Запрашивая на одну запись больше, чем собираетесь отдать, вы узнаёте о существовании следующей страницы без отдельного запроса COUNT. Лишняя запись отбрасывается, а её наличие становится флагом has_more.

Составной курсор: место, где ломается наивная версия

Курсор по одному id корректен, только пока вы сортируете по id. Как только сортировка идёт по created_at, простое условие created_at > X начинает терять записи: два заказа, созданные в одну миллисекунду, дают ничью, и одна из строк молча исчезает из выдачи.

Лечится это составным курсором — ключ сортировки плюс первичный ключ, сравниваемые как кортеж:

Сравнение кортежей разрешает ничьи детерминированно, поэтому ни одна строка не дублируется и не пропадает. Под это нужен составной индекс (created_at DESC, id DESC), иначе выигрыш в скорости пропадёт вместе с планом запроса.

Про формат курсора:
Не отдавайте наружу голый идентификатор, если планируете менять схему. Заверните значения в маленький JSON с полем версии и закодируйте в base64: тогда через год вы поменяете состав курсора, не сломав клиентов, которые прямо сейчас держат страницу открытой.

Когда офсетную пагинацию нужно оставить

Курсор не бесплатный, и подменять им всё подряд не стоит. Есть четыре ситуации, где offset честно лучше:

• Интерфейсу нужен переход на конкретную страницу. У курсора нет номеров страниц, поэтому админки, таблицы и всё с кнопкой «перейти к странице 47» остаются на offset.
• Данных мало и они не меняются. Справочник на пять тысяч строк не выиграет ничего, зато offset проще объяснить и отладить.
• Пагинация идёт по памяти или по кешу, где смещение и так стоит O(1).
• Сортировка задаётся пользователем по произвольной колонке. Курсор тут превращается в кодирование кортежей в непрозрачные строки, и это уже заметная сложность.

Разумное правило: курсор по умолчанию для всего, что может перерасти десять тысяч строк или читается во время записи. Offset — для небольших, статичных и внутренних данных.

И отдельно стоит помнить, что пагинация обычно не единственная нагрузка на базу. Кто ещё и насколько сильно её грузит, разбирали в переводе про паттерны управления трафиком к PostgreSQL.

Вторая половина задачи: кто и сколько может забрать

Правильная пагинация решает, как отдавать данные. Она не решает, сколько их заберут за минуту. Ограничение частоты запросов выглядит тривиально («считай запросы, блокируй сверх N») и превращается в задачу распределённых систем ровно в тот момент, когда серверов становится два.

Сначала ответьте, от чего защищаетесь

От выбранной цели зависит вся конструкция, и целей обычно выделяют четыре:

• Защита от перегрузки — не дать всплеску положить сервис.
• Честное распределение — не дать одному шумному клиенту вытеснить остальных.
• Защита от злоупотреблений — притупить перебор паролей, скрейпинг и подстановку учётных данных.
• Контроль расходов — ограничить дорогие ручки вроде вызова модели или построения отчёта. Тот же принцип со стороны поставщика разбирали на примере лимитов трат в OpenAI API.

Три алгоритма и один, который выбирают почти всегда

Фиксированное окно считает запросы в календарном интервале: сто в минуту со сбросом на начале минуты. Просто и дыряво: клиент отправляет сотню в 12:00:59 и ещё сотню в 12:01:00, то есть двести за одну секунду. Граница окна и есть дыра.

Скользящее окно считает в непрерывно сдвигающемся интервале, часто взвешивая счётчик предыдущего окна по мере хода времени. Точнее, но требует больше состояния.

Ведро токенов обычно и оказывается верным выбором по умолчанию. В ведре лежит до N токенов, оно пополняется с постоянной скоростью, каждый запрос тратит один токен. Такая схема разрешает контролируемые всплески (молчавший клиент накопил токены и может потратить их разом), но держит среднюю нагрузку в рамках. Родственное «дырявое ведро» выдаёт идеально ровный поток и нужно там, где принимающая сторона всплесков не переносит.

Фиксированное окно пишут первым и потом жалеют. На ведро токенов мигрируют.

Ловушка, из-за которой лимит не работает вообще

Счётчик в памяти процесса живёт до появления второго сервера. После этого «сто запросов в минуту» тихо означает «сто запросов в минуту на инстанс», и при десяти инстансах клиент законно получает тысячу. Ошибку не видно ни в логах, ни в мониторинге: лимит вроде бы работает, просто не тот.

Лечится это переносом счётчика в общее хранилище, обычно в Redis, причём проверка и инкремент обязаны быть атомарными. Последовательность «прочитать, сравнить, увеличить» из кода приложения гоняется между инстансами и недосчитывает запросы ровно под той нагрузкой, ради которой лимит и ставили.

Скользящее окно на Redis: пятнадцать строк Lua

Команда сервиса jo4.io столкнулась с частным случаем этой задачи: ручка подсказки категорий ходит в модель через Groq, каждый вызов стоит денег, а пользователь может дёрнуть её полсотни раз за минуту. Нужны были лимиты на конкретную ручку и на конкретного пользователя, причём в тот же день.

Скользящее окно они собрали на сортированном множестве Redis. Скор записи — временная метка в миллисекундах, а весь алгоритм умещается в один Lua-скрипт, который Redis выполняет атомарно:

Первая команда чистит записи старше окна относительно текущего момента — именно поэтому окно скользящее, а не фиксированное: границ, к которым можно приурочить всплеск, здесь просто нет. PEXPIRE с запасом в секунду доубивает ключ, если новых запросов не приходит, так что чистить хранилище отдельно не нужно.

Две детали, на которых легко ошибиться

Уникальность члена множества. ZADD не добавляет запись, а перезаписывает существующую, если член совпал. Два запроса в одну миллисекунду с одинаковым значением дадут счётчик, который занижен. Авторы склеивают метку времени с восемью символами UUID: метка обеспечивает уникальность почти всегда, а восемь шестнадцатеричных символов дают около четырёх миллиардов вариантов внутри одной миллисекунды.

Куда падать при отказе Redis. Решение здесь принимается осознанно и по-разному для двух случаев. Если вызов не получил внятного ответа вовремя (таймаут клиента, сетевая икота), запрос пропускают: лимит здесь страхует бюджет, а не безопасность, и блокировать живого пользователя из-за сбоя инфраструктуры хуже, чем оплатить лишний вызов модели. А вот жёсткое исключение (Redis недоступен, соединение отвергнуто) пробрасывают наверх: если хранилище легло целиком, лучше шумно упасть, чем молча жечь бюджет вообще без ограничений.

Обошлось это в два часа работы вместе с тестами. Одна запись в сортированном множестве занимает около 50 байт, на пользователя их пять, и даже при десяти тысячах активных пользователей всё хранилище лимитов весит порядка 2,5 МБ. Настроенный лимит составил пять запросов за шестьдесят секунд на пользователя. Первым же уловом стал автоматизированный скрипт, бивший в ручку больше двухсот раз в час.

Честный контракт с клиентом

Ограничение без внятного ответа превращает вежливого клиента в невежливого: не понимая, что происходит, он начинает долбить чаще. Минимальный набор обязательств выглядит так:

• Отдавать 429 Too Many Requests, а не общий 400 или 503. По коду клиент понимает, что делать.
• Присылать заголовок Retry-After, чтобы клиент знал момент следующей попытки, а не подбирал его перебором.
• Показывать остаток бюджета в заголовках вида X-RateLimit-Remaining и X-RateLimit-Reset.

Последний пункт стоит дешевле всего и работает лучше всего: клиент, который видит свой остаток, обычно распределяет запросы сам и до стены не доходит.

Что забрать с собой

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

Отложить их дешевле всего прямо сейчас и дороже всего в момент, когда в поддержку придёт клиент с задвоенными заказами: тогда чинить придётся не только API, но и данные на его стороне.

Разборы, на которых основан материал: переход с offset на курсор с замерами, паттерны и алгоритмы ограничения частоты и скользящее окно на Redis и Lua.

Откройте свой самый нагруженный список и выполните запрос с большим смещением. Если ответ идёт дольше сотни миллисекунд, вы уже нашли, с чего начать.

Кому это важно: тем, кто много лет копил историю перемещений в Google Timeline и после переноса её на устройство ищет, где хранить данные самому. Импорт Google Takeout в Dawarich есть, а с новой отрисовкой многолетний архив перестаёт быть проблемой для интерфейса. Проект написан на Ruby on Rails с PostgreSQL и ставится через Docker; на сайте указано больше 9000 звёзд на GitHub.

• Точки, треки, маршруты и слои «тумана войны» теперь отдаются через map tiles; 957 350 точек за меньше чем секунду, JSON с 590 МБ до 150 КБ.
• Для перетаскивания точек на карте новый режим нужно отключить.
• Определение посещений (visit detection) переписано с нуля; метаданные устройств перенесены в таблицу point_sources.
• OwnTracks в HTTP-режиме показывает членов семьи на карте; перелёты из AirTrail считаются отдельно от треков Dawarich.
• Self-hosting бесплатен со всеми функциями; облако: Lite 59,99 евро в год (12 месяцев истории, 200 запросов API в час), Pro 149,99 евро (бессрочная история, 1000 запросов в час), Family 299,99 евро (до 5 человек).

Почему тайлы решают проблему миллиона точек

Старая схема отдавала клиенту все точки в JSON, и браузер сам рисовал их на карте. На сотнях тысяч точек это сотни мегабайт данных и столько же объектов в памяти вкладки. Новая схема режет данные на тайлы: карта запрашивает только тайлы видимой области и масштаба, а отрисовка по-прежнему идёт в браузере, просто над несравнимо меньшим объёмом данных. Плата за это одна, и автор её называет: точки в режиме тайлов нельзя таскать мышью, для редактирования режим надо выключить.

Автор пишет, что за месяц вышло девять релизов, и называет результат «немного безумным» (перевод редакции). Для админа, который держит Dawarich на маломощном VPS или Raspberry Pi, важно другое: девять релизов за месяц означают частые миграции базы, и перед каждым обновлением нужен бэкап PostgreSQL.

Что ещё изменилось в 1.14.1

• Метаданные устройств перенесены в таблицу point_sources: миграция базы при обновлении обязательна, перед ней нужен бэкап PostgreSQL.
• Импорт OwnTracks исправлен для массивов PostgreSQL; повреждённая или обрезанная загрузка теперь отклоняется без ошибки сервера.
• Расстояние перелётов из AirTrail считается отдельно от расстояния, записанного трекером.
• Интерфейс переведён на шесть языков: английский, немецкий, испанский, французский, польский и каталанский; следующим заявлен упрощённый китайский. Русского перевода нет.

Self-hosting или облако

Self-hosted версия бесплатна и включает всё, что есть в платных тарифах, ограничения только у облачного варианта: Lite за 59,99 евро в год хранит 12 месяцев истории и даёт 200 запросов API в час, Pro за 149,99 евро снимает лимит истории и поднимает потолок до 1000 запросов, Family за 299,99 евро рассчитан максимум на пять участников. Условия оплаты облака по регионам проект не описывает; self-hosting от них не зависит.

Что проверить перед обновлением: сделать дамп базы, обновить образ Docker до 1.14.1, дождаться миграций и убедиться, что карта показывает точки в новом режиме. Кому релиз не нужен: тем, у кого история перемещений измеряется тысячами точек, а не сотнями тысяч; для них разница будет незаметна. О другом свежем self-hosted проекте того же класса мы писали на примере Home Assistant 2026.9; о хранении резервных копий такого рода данных есть разбор про бэкапы в S3.

Источники: Пост разработчика в r/selfhosted, Релиз 1.14.1 на GitHub, Сайт проекта

Если ваш прод стоит на Postgres Pro Enterprise, это тот случай, когда обновляться нужно не по плану, а сейчас: среди закрытых проблем четырнадцать с оценкой CVSS 8,8, и для одиннадцати из них upstream прямо пишет о выполнении произвольного кода, причём часть срабатывает через обычные SQL-функции вроде to_char() или через регулярные выражения. Если вы на ванильном PostgreSQL, те же исправления вышли ещё 13 августа в версиях 18.6, 17.11, 16.15, 15.19 и 14.24, и проверить стоит, что вы их уже накатили.

• «Нулевые» релизы Postgres Pro Enterprise содержат только исправления безопасности и ошибок, без новых функций; новые возможности придут в плановых минорных версиях вида 17.11.1.
• Закрыты 28 CVE и более 110 багов из обновления PostgreSQL от 13 августа 2026 года (18.6, 17.11, 16.15, 15.19, 14.24).
• Самые опасные: 14 CVE с оценкой 8,8, из них 11 на выполнение произвольного кода, включая переполнения буфера в regexp, to_char(), PL/Perl, pg_stat_statements и pg_dump.
• Обновление накопительное, pg_upgrade не нужен: остановить сервер и заменить бинарники; после этого проверить GIN-, btree_gist- и ltree-индексы.
• Компания связывает скорость выпуска с приказом ФСТЭК №117 для госорганов и ГИС: критические уязвимости устранять за 24 часа, высокие за 7 дней.

Что такое «нулевой» релиз

Обычный цикл коммерческого форка выглядит так: выходит минорный релиз upstream PostgreSQL, вендор переносит исправления в свою ветку, тестирует вместе с собственными доработками и выпускает очередную минорную версию, где безопасность идёт вперемешку с новыми функциями. Для заказчика это означает выбор: либо ждать плановый релиз с открытыми дырами, либо ставить его сразу и получать вместе с патчами новую функциональность, которую никто не тестировал в его контуре.

«Нулевой» релиз разрывает эту связку. Он собирается на базе предыдущего минорного релиза Postgres Pro Enterprise, в него переносятся только исправления из актуальной версии PostgreSQL, и никаких новых возможностей там нет. Доработки, отложенные ради скорости, выйдут позже в привычных минорных версиях по обычному циклу. Технический директор Postgres Professional Юлия Рыденкова объясняет это так: «Заказчик может установить необходимые исправления сразу, не дожидаясь следующего планового обновления и не внедряя одновременно с этим новые возможности продуктов».

Подход не новый для индустрии: примерно так устроены security-only ветки у дистрибутивов Linux. Для российского рынка СУБД, где заказчики часто сидят на сертифицированных редакциях с долгим циклом обновления, разделение потоков «безопасность» и «функции» снимает главный аргумент против быстрого патчинга.

Какие уязвимости закрыты

Все 28 CVE перечислены в анонсе PostgreSQL от 13 августа. Четырнадцать из них имеют максимальную в этом наборе оценку CVSS 8,8; Postgres Professional выделяет одиннадцать, где по описанию upstream возможно выполнение произвольного кода:

• CVE-2026-14664: переполнение буфера в обработке регулярных выражений.
• CVE-2026-14669: переполнение буфера в функции to_char().
• CVE-2026-14670: переполнение буфера в связанных (tied) объектах PL/Perl.
• CVE-2026-14671: путаница типов в кэше планов contrib/refint.
• CVE-2026-14676: переполнение буфера в pg_stat_statements.
• CVE-2026-14680: путаница типов через аргументы типа internal.
• CVE-2026-15741: SQL-инъекция через аргумент функции EXTRACT() при обратном разборе (deparse) выражений.
• CVE-2026-16238 и CVE-2026-16239: путаница типов в pg_restore_attribute_stats() и в связке CLOSE + DECLARE курсоров.
• CVE-2026-18408: команда psql \unrestrict позволяла суперпользователю сервера-источника pg_dump выполнить произвольный код в клиенте psql при восстановлении дампа.
• CVE-2026-19385: переполнение буфера в pg_dump.

Ещё две проблемы стоят отдельно. CVE-2026-6471 (CVSS 7,2): пользователь с правами на репликацию мог заставить логическое декодирование подгрузить произвольную библиотеку через dlopen. После исправления список разрешённых плагинов вывода ограничен новым параметром output_plugin_libraries, и если у вас работает логическая репликация с нестандартными плагинами, их нужно туда прописать. CVE-2026-6464 (CVSS 8,1) касается psql: при раннем сбое команды COPY FROM STDIN или \copy FROM STDIN строки данных могли быть разобраны как команды psql. Для эксплуатации нужен контроль и над серверной ошибкой, и над данными COPY; вариант COPY FROM с именем файла не затронут.

Ещё три уязвимости с оценкой 8,8 в этот список компания не включила: недоразмерные выделения памяти в tsvector и tsquery (CVE-2026-14662), в 32-битных pltcl и plperl (CVE-2026-14677) и запись по произвольным адресам в fuzzystrmatch (CVE-2026-15742). Остальные пункты списка, от раскрытия существования пользователя через нестандартное число итераций SCRAM (CVE-2026-14672, CVSS 5,3) до чтения за границей буфера в функции ascii() (CVE-2026-18024, CVSS 4,3), имеют оценки от 3,8 до 8,2. Компания отмечает, что несколько уязвимостей, в частности CVE-2026-16239 и CVE-2026-14680, найдены исследователями при участии ИИ-инструментов Claude и Codex Security.

Что делать после обновления

Обновления накопительные: выгружать и загружать базы или запускать pg_upgrade не нужно, достаточно штатно остановить сервер и заменить бинарные файлы. Но после этого Postgres Professional, как и upstream в своём анонсе, просит выполнить несколько проверок, потому что часть исправлений затрагивает индексы:

1. Проверить таблицы с GIN-индексами и выполнить ANALYZE, если значение reltuples выглядит некорректным (исправлена ошибка параллельной сборки GIN).
2. Переиндексировать btree_gist-индексы на столбцах типов float4, float8, bit и bit varying, если они есть.
3. Переиндексировать B-tree-индексы по столбцам ltree, если значения могут содержать больше 14 653 меток.
4. Проверить конфигурацию логического декодирования и добавить доверенные плагины в output_plugin_libraries.

Пользователям ванильного PostgreSQL стоит помнить ещё об одном: ветка 14 перестанет получать исправления 12 ноября 2026 года, а версии 18.4 и 18.5 не выходили вовсе, ветка 18 перескочила с 18.3 сразу на 18.6 из-за регрессии в 18.5.

Почему компания торопится

Postgres Professional прямо связывает формат «нулевых» релизов с регуляторикой. С 1 марта 2026 года действует приказ ФСТЭК России №117 от 11 апреля 2025 года о защите информации в государственных информационных системах и системах госорганов и госучреждений: уязвимости критического уровня нужно устранить или закрыть компенсирующими мерами за 24 часа, высокого уровня за 7 календарных дней, а если уязвимости нет в БДУ ФСТЭК, сведения о ней нужно направить в службу в течение 5 рабочих дней. На коммерческие компании приказ напрямую не распространяется, но именно госзаказчики составляют заметную часть пользователей сертифицированных редакций, и для них ждать плановый релиз вендора с патчем невозможно: сроки считаются с момента выявления.

Второй фактор, который называет компания: ИИ-инструменты резко ускорили поиск дефектов. В качестве примера Postgres Professional ссылается на программу координированного раскрытия уязвимостей Anthropic, в которой модель Claude нашла и передала мейнтейнерам сотни проблем в проектах с открытым кодом; две CVE из сегодняшнего списка тоже найдены с участием ИИ. Чем быстрее находят, тем важнее способность вендора быстро адаптировать и протестировать upstream-патч для своей редакции.

Чего в сообщении нет: точных номеров «нулевых» версий по веткам и ссылок на страницы загрузки. Не сказано и о сроках аналогичных релизов для редакции Postgres Pro Standard. Следующая точка на календаре для всех пользователей PostgreSQL, плановое квартальное обновление upstream в ноябре; будет ли к нему «нулевой» релиз и как быстро, компания не обещала.

Источники: Postgres Professional: новость на Хабре, PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released, PostgreSQL: Security Information

Изображение на обложке: Изображение: Postgres Professional

DoltLite запустили 25 марта 2026 года как замену SQLite, у которой вместо B-tree под капотом content-addressed Prolly Tree. Всё остальное, по описанию основателя DoltHub Тима Сена, от SQLite: парсер SQL, анализатор, файловый слой и тестовый harness. До беты ушло около 2000 pull request и пять месяцев.

• DoltLite 0.50.0 объявлен бетой: стабильный формат хранения, SQL-совместимость и полный набор операций контроля версий.
• Поддерживаются branch, merge, diff, rebase, cherry-pick, reset, а также push, pull, clone и fetch на свой remote или DoltHub.
• Из 892 277 TCL-тестов SQLite проходят 99,46%; sqllogictest на 5,8 млн запросов проходит полностью; известно 4809 расхождений.
• В памяти чтение медленнее SQLite на 10%, запись на 60%; для файловых баз чтение на уровне SQLite, пакетная запись медленнее на 10%.
• Мелкие autocommit-записи медленнее в 3,1 раза: около 400 мкс против 125 мкс у SQLite.

Что «бета» означает у DoltHub

Компания перечисляет четыре условия. Стабильный формат хранения: до беты он менялся 12 раз, а текущий вариант продержался 57 релизов, больше трёх месяцев, и для будущих несовместимых изменений обещан путь миграции. SQL-совместимость: DoltLite проходит 100% sqllogictest, это 5,8 млн запросов, и 99,46% из 892 277 TCL-тестов самого SQLite. Полный контроль версий: ветки, слияния, diff, rebase, cherry-pick, reset и удалённые операции. И производительность, пригодная для production, с оговорками ниже.

Оставшиеся 4809 расхождений с SQLite DoltHub объясняет архитектурой: отказ от rowid, chunk вместо page и отсутствие WAL и journal-файлов рядом с базой. Если код полагается на эти детали SQLite, миграция не будет прозрачной; проверить стоит именно их.

Сколько стоит версионирование

Замеры приводит сам вендор. Для базы в памяти чтение медленнее SQLite примерно на 10%, запись примерно на 60%. Для файловой базы чтение на уровне SQLite, пакетная запись медленнее примерно на 10%. Хуже всего мелким autocommit-транзакциям: каждая такая запись занимает около 400 мкс против 125 мкс у SQLite, то есть в 3,1 раза дольше. Причина в природе Prolly Tree: каждое изменение порождает новые chunk с хешами, и на одиночной вставке эта работа не амортизируется.

На практике это значит, что DoltLite подходит для сценариев, где данные меняются пакетами и важна история: конфигурации, справочники, наборы данных для ML, локальные базы в приложениях, где нужен откат и сравнение версий. Для очереди с тысячами мелких вставок в секунду SQLite по-прежнему быстрее, и вендор этого не скрывает.

Что можно сделать уже сегодня

Рабочий цикл похож на Git: создать ветку, изменить данные, посмотреть diff, слить. Удалённые операции push, pull, clone и fetch работают с собственным remote или с DoltHub. 7 августа DoltHub добавила поддержку DoltLite в Dolt Workbench, свой графический клиент, где ветвление, diff и merge доступны из интерфейса.

Сборки, по данным репозитория, есть для Linux, macOS, Windows, Python, Node.js, Rust, Android и WebAssembly. Лицензия в анонсе беты не указана, и перед использованием в коммерческом продукте её стоит уточнить в репозитории.

Релиз 0.50.0 не содержит изменений кода относительно 0.11.57: номер версии подняли, чтобы обозначить бету. Если вы уже на 0.11.57, обновляться ради кода не нужно.

Контекст

DoltHub с 2018 года развивает Dolt, версионируемую базу, совместимую с MySQL. DoltLite переносит ту же идею на встраиваемый движок: Prolly Tree даёт дешёвое сравнение версий по хешам и структурное слияние, а SQLite даёт зрелый SQL-слой. По нашей оценке, главный практический вопрос беты не в фичах, а в том, насколько быстро проект закроет разрыв в мелких записях: именно там пройдёт граница между «база для датасетов» и «замена SQLite в приложении».

Сроков выхода стабильной версии DoltHub не называет; редакция проверит, изменится ли производительность записи в следующих релизах.

Источники: Блог DoltHub: DoltLite Beta, Релиз v0.50.0 на GitHub

Если у вас на Workers Free крутится пет-проект, бот или небольшой сервис с базой в D1, это касается напрямую: в один день трафик чуть выше обычного, и после обеда по Москве запросы к базе начинают завершаться ошибкой до трёх часов ночи, а приложение без обработки этой ошибки показывает её пользователям. Cloudflare обещает письмо при достижении лимита, но письмо не починит прод.

• Лимиты Workers Free для D1: 5 млн прочитанных строк и 100 тысяч записанных строк в сутки, 5 ГБ хранилища на аккаунт.
• С 1 сентября при превышении запросы к D1 завершаются ошибкой до сброса счётчика в 00:00 UTC (03:00 мск); сохранённые данные не затрагиваются.
• На Workers Paid за $5 в месяц включено 25 млрд чтений и 50 млн записей в месяц, дальше $0,001 за миллион прочитанных строк и $1 за миллион записанных; 5 ГБ хранилища включено, дальше $0,75 за ГБ в месяц.
• Строки считаются по факту прочитанного движком, а не по числу строк в ответе: SELECT без индекса по таблице в 100 тысяч строк — это 100 тысяч чтений.
• Cloudflare советует посмотреть статистику запросов за прошлые дни и добавить индексы: полное сканирование таблицы съедает лимит чтений быстрее всего.

Что изменилось на самом деле

Сами лимиты не новые, они давно указаны на странице тарифов. Изменился режим их применения: до 1 сентября Cloudflare не блокировала запросы при превышении, теперь блокирует. Ограничение действует и на вызовы из кода Worker через биндинг, и на REST API, которым пользуются внешние интеграции и админки. В тексте ошибки предлагается два выхода: перейти на платный план или подождать до завтра.

Upgrade to a paid plan or wait until tomorrow.

Компания подчёркивает, что хранилище остаётся нетронутым: речь только о временной недоступности запросов, а не о потере или заморозке данных. Счётчик сбрасывается в полночь по UTC, в три часа ночи по Москве. Уведомление по электронной почте приходит при достижении дневного лимита, и Cloudflare отдельно рекомендует посмотреть активность запросов за прошлые дни, чтобы понять, насколько проект близок к границе.

Почему один запрос может стоить 100 тысяч чтений

Главная ловушка D1 — учёт по прочитанным строкам, а не по запросам. Запрос SELECT * FROM events WHERE user_id = ? без индекса по user_id заставляет движок пройти всю таблицу, и каждая пройденная строка засчитывается в лимит, даже если в ответе одна запись. Поэтому небольшой сервис с парой тысяч посетителей в день может упереться в 5 млн чтений на одном неудачном запросе в цикле. Cloudflare в changelog прямо называет виновника: запросы с полным сканированием таблиц, и советует индексы как первое средство.

Сколько строк реально прочитал запрос, D1 возвращает в объекте meta ответа: поля rows_read и rows_written. Именно по ним, а не по числу вызовов, стоит оценивать, насколько вы близки к лимиту. Суммарную картину за день показывают GraphQL Analytics API и дашборд Cloudflare; страница тарифов перечисляет все три способа отслеживать расход.

С записями та же логика: учитываются записанные строки, а не вызовы. Объединение вставок в один батч сокращает число запросов и задержку, но не уменьшает rows_written, так что от лимита в 100 тысяч записей в сутки оно не спасает. Единственный способ уложиться — писать меньше строк: агрегировать события, не хранить в D1 логи на каждый запрос, выносить телеметрию в Analytics Engine или KV.

Сколько стоит платный план

Workers Paid стоит $5 в месяц и снимает дневные лимиты. По странице тарифов в него включены 25 млрд прочитанных строк и 50 млн записанных строк в месяц, сверх этого чтение стоит $0,001 за миллион строк, запись — $1 за миллион строк. Хранилище: 5 ГБ включено, дальше $0,75 за гигабайт в месяц. Бесплатный план даёт те же 5 ГБ, но при их превышении не тарифицирует, а блокирует новые записи и изменение схемы; но 5 млн чтений и 100 тысяч записей в сутки, то есть примерно 150 млн чтений и 3 млн записей в месяц.

Что сделать до вечера

• Откройте статистику D1 в дашборде за последние две недели: если пиковые дни выше 3–4 млн чтений, по нашей оценке вы в зоне риска; порог редакционный, Cloudflare его не задаёт.
• Пройдитесь EXPLAIN QUERY PLAN по самым частым запросам и добавьте индексы там, где видите SCAN.
• Кэшируйте горячие ответы в KV или Cache API: одно чтение из кэша вместо тысячи строк из базы.
• Записи ограничены сильнее чтений: считаются записанные строки, а не вызовы, батчи не помогут; пишите меньше строк, агрегируйте события и не кладите логи в D1 на каждый запрос.
• Обрабатывайте ошибку D1 в коде: показывайте пользователю понятное сообщение и отдавайте кэшированные данные, а не пятисотую страницу.

Контекст

D1 вышла из беты в 2024 году как «SQLite на краю сети» для Workers: база живёт рядом с кодом и тарифицируется по строкам, а глобальная репликация чтения доступна как отдельная бета-функция, а не по процессорному времени. Учёт по строкам — осознанный выбор Cloudflare, и до сих пор он был безболезненным для бесплатных проектов. Для D1 «бесплатно» теперь читается буквально: в пределах квоты сервис работает, за пределами останавливается, а не копит счёт. Распространится ли такой режим на другие бесплатные лимиты Workers, changelog не говорит.

Источники: D1 free tier limit enforcement (Cloudflare Changelog), D1 pricing

Изображение на обложке: Cloudflare

Перевод и пересказ короткой заметки автора Redis для русскоязычной аудитории — четыре месяца разработки, изменение внутренней архитектуры в середине пути, ARGREP с регулярными выражениями через TRE и общий вывод про связку «человек + AI» в инфраструктурном коде.

Что вышло. В Redis приземлился новый нативный тип Array с поддержкой числового индекса как части семантики (PR #15162). Четыре месяца работы; команды ARSET, ARSCAN, ARPOP, ARGREP, ARINSERT.

Спецификация — первое. Месяц ушёл на ручное написание спецификации: обоснование типа, C-структуры, разрежённое представление, семантика курсора для ring buffer и ARINSERT. Сначала с Opus, потом с GPT 5.3 / Codex.

Архитектура поменялась в середине. Изначально были два уровня директорий и slices двух типов (sparse и dense) — этого не хватило для ARSET с очень большими индексами. Перешёл на «super directory of sliced dense directories» с slice по 4096 элементов. Без AI «срезал бы углы» — с AI пошёл на extra mile.

ARGREP с regex. При тестировании Сальваторе начал хранить файлы Markdown в Array — для своей базы знаний. Так появилась идея ARGREP. Взял библиотеку TRE (за гарантии по времени против патологических паттернов), оптимизировал её для матчинга foo|bar|zap и закрыл несколько проблем безопасности.

Главный вывод. AI — не замена человека в системном программировании, но «safety net» для громоздких задач (32-битная поддержка, тесты алгоритмов) и виртуальная команда ревью. Спецификация по-прежнему пишется человеком, и она же ключ ко всем последующим этапам.

Месяц первый: спецификация руками

Сальваторе подчёркивает: даже с AI первый месяц был полностью ручной работой над спецификацией. Документ описывает обоснование нового типа, C-структуры, разрежённое представление, точную семантику курсора для ring buffer и команды ARINSERT.

Дальше пошёл back-and-forth с моделью: сначала с Claude Opus, потом, когда вышел GPT 5.3, переключился на Codex. С тех пор все системные задачи делает только на GPT 5.x. Промежуточные обсуждения с моделью качественно меняли спецификацию: интеллектуальные вызовы про лучший дизайн, что переусложнено, что — недостаточно проработано.

Месяцы второй и третий: автокодинг и пересмотр архитектуры

Со второго месяца Сальваторе начал реализацию через automatic programming (его термин для написания кода с AI-ассистентом): постоянное ревью того, что пишет модель. И тут наткнулся на проблему — выбранный уровень индирекции оказался неправильным.

Изначально была схема: два уровня директорий и slices (sparse и dense). Этого не хватало для сценария вида ARSET myarray 293842948324 foo — то есть когда индекс большой, а массив должен оставаться разрежённым без огромных аллокаций.

Поскольку у меня был AI, я не пошёл на компромисс — решил пройти extra mile.

Под определёнными условиями структура данных меняет внутреннюю форму, превращаясь в super directory из sliced dense directories, которые в свою очередь указывают на сами array slices (по 4096 элементов на slice по умолчанию).

Это и дало одновременно «как настоящий массив» с точки зрения внутреннего представления, и нужные характеристики по памяти. ARSCAN и ARPOP теперь сканируют существующие массивы за время, пропорциональное числу элементов, а не длине диапазона.

Затем — чтение всего кода построчно. Тип покрыт массивным тестированием (опять же с помощью AI), но «работает поверхностно» не значит «оптимально». Сальваторе нашёл много мелких неэффективностей и дизайн-ошибок, которые ему не нравились, и начал процесс ручной и AI-ассистированной перезаписи модулей.

Появление ARGREP — от своей задачи к команде

Когда стресс-тестирование Array на разных кейсах подтвердило, что структура годится, Сальваторе начал моделировать сценарии использования. И тут, как часто бывает, личная задача подсказала фичу: он начал хранить файлы Markdown прямо в массивах — потому что они хорошо ложатся в этот тип.

Параллельно работал с агентами на других задачах и понял, что ему нужна централизованная база знаний из файлов Markdown под нужные навыки. Из своей потребности родился ARGREP. Но захотелось не просто поиска по подстроке — захотелось регулярных выражений.

Выбор библиотеки regex — отдельная история. Сальваторе остановился на TRE от Ville Laurikari: когда regex встраивается в Redis, важно гарантировать отсутствие патологических паттернов по времени и памяти. Но у TRE оказалась неэффективность в одном специфичном и очень полезном кейсе — матчинг alternation вида foo|bar|zap.

С помощью GPT он оптимизировал библиотеку для этого кейса, заодно зафиксил несколько потенциальных проблем безопасности и расширил тесты. После этого ARGREP с честным regex был готов к мержу.

Главное наблюдение: AI как safety net

Сальваторе формулирует главный вывод так: для high-quality системного программирования по-прежнему нужно быть полностью вовлечённым — но AI расширил «зону комфорта». Без него Сальваторе не пошёл бы на тот уровень сложности, который выбрал для нового типа.

AI выступил safety net в двух конкретных аспектах:

• Громоздкие задачи без выгорания. Например, поддержка 32-битной архитектуры, которую он добавил и протестировал отдельно. Это та работа, что обычно отнимает мотивацию и силы — с AI она прошла без обычного истощения.
• Виртуальная команда ревью, которая отлавливает очевидные баги в сложных алгоритмах. Не замена тестам и не замена самому Сальваторе — но дополнительный слой, который ловит «глупости» до того, как они уйдут в код.

При этом Сальваторе подчёркивает: огромная начальная спецификация — ключ ко всему остальному. Без неё невозможно было ни прогнать ревью каждой строки в sparsearray.c и t_array.c, ни решать, что переписывать, ни понимать, какой именно компромисс ты только что принял.

Что взять на заметку разработчику

1. Сначала спека, потом AI. Если задача системная — потратьте первый этап на ручное написание спецификации. AI может качественно её прокачать через диалог, но не сгенерировать с нуля.
2. Не идите на компромисс по архитектуре, если AI это закрывает. Громоздкая правильная реализация теперь под силу одному человеку. Если внутреннее представление кажется «не тем» — пересоберите его, пока спека ещё свежая в голове.
3. Ревью каждой строки. AI хорош в тестах и поверхностном «работает», но качество кода остаётся за вами. Без построчного чтения после того, как «всё работает», оптимизировать дизайн — на ощупь.
4. Чередуйте модели. Хотя бы две (например, GPT 5.x и Claude). Это не страховка от падений API, а способ увидеть проблему с разных углов.
5. Следите за тем, что под рукой. Сальваторе нашёл идею ARGREP не через roadmap, а через собственный сценарий: хранил Markdown в Array, понадобился полнотекстовый поиск.

Выводы

История Redis Array — короткий, но содержательный кейс того, как меняется планка инфраструктурного программирования с приходом AI-ассистентов. Не «AI пишет код», и даже не «AI делает программиста быстрее в 5 раз». А «AI убирает потолок сложности, который раньше задавался выгоранием и страхом ошибиться в дальнем углу системы».

Похожий тренд мы недавно разбирали со стороны GitHub: их CTO признал, что план по 10-кратному наращиванию мощностей пришлось переписывать в 30-кратный — потому что объём AI-сгенерированного кода вырос быстрее, чем планировали. Со стороны автора одиночного проекта это выглядит так же: новый этаж сложности достижим без новой команды.

Источник: Redis array type: short story of a long development — antirez.com.

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

Denwer SE решает все эти проблемы, оставаясь при этом таким же портативным — достаточно скопировать папку на флешку или в облачный каталог.

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

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

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

pgBackRest — основной open-source инструмент резервного копирования и восстановления PostgreSQL последние ~10 лет: parallel backup, асинхронная архивация WAL, шифрование, поддержка S3/Azure/GCS-хранилищ, до десяти одновременно поддерживаемых major-версий Postgres (политика 5 supported + 5 EOL). Текущий стабильный релиз — v2.58.0, выпущен в январе 2026.

• Дата объявления: 27 апреля 2026 года
• Мейнтейнер: David Steele, 13 лет разработки
• Репозиторий помечен archived — release-веток и патчей больше не будет
• Текущий стабильный релиз: v2.58.0 (январь 2026)
• Главные альтернативы: wal-g, Barman
• Автор просит форки выбирать новое имя

Почему закрывают

Прямой повод — продажа компании Crunchy Data, в которой David Steele работал и которая корпоративно спонсировала разработку pgBackRest. После сделки автор искал позицию, которая позволила бы продолжить работу над проектом, и параллельно собирал спонсорство — но обе попытки оказались безуспешны.

pgBackRest 13 лет был моим личным проектом. После продажи Crunchy Data я искал позицию, позволяющую продолжать работу, и пытался собрать спонсорство — но усилий не хватило, чтобы сделать проект жизнеспособным. Как и всем остальным, мне нужно зарабатывать. Лучше сделать жёсткий стоп, чем тянуть проект кое-как.

Что это значит для пользователей

Существующие установки продолжат работать — релиз v2.58.0 не отзывают. Но дальше будет так:

• Security-патчей больше нет. Если в pgBackRest найдут CVE, никто не выпустит фикс — придётся либо мигрировать, либо патчить самим в форке.
• Поддержки следующих major-версий Postgres не будет. v2.58.0 уже поддерживает PG13–18, но когда выйдет PG19 (ожидается осенью 2026), pgBackRest не получит обновлённых WAL-форматов и сломается на новых кластерах.
• Открытые issues (68 на момент архивации) останутся без ответов. Pull-request-ы тоже.
• Документация на pgbackrest.org пока на месте, но судьба сайта после ухода автора неясна.

Альтернативы pgBackRest

wal-g

wal-g — продолжатель WAL-E, создан в Citus Data в 2017 (Daniel Farina + Katie Li). Активная разработка сейчас спонсируется Yandex Cloud, поддерживается распределённой командой и сообществом. Поддерживает PostgreSQL, MySQL/MariaDB, MS SQL Server, MongoDB и Redis (последние два — beta). Бэкап в S3/GCS/Azure/Swift, параллельная обработка, delta-копии. Релизы выходят регулярно.

Barman

Barman — инструмент от EDB (бывший 2ndQuadrant). Делает full и incremental бэкапы, point-in-time recovery, поддерживает streaming-репликацию и WAL-archiving. Сильнее других ориентирован на on-prem-сценарии и enterprise-сетапы. У EDB есть коммерческие подписки на Barman — это снижает риск похожего сценария.

pg_basebackup

pg_basebackup — встроенный инструмент Postgres. Подходит для небольших БД, простых сетапов, разовых снимков. С PG17 умеет page-level incremental backup (через summarize_wal и pg_combinebackup), но без удобной обвязки. Не покроет parallel backup, multi-repo retention и продвинутые retention-полиси.

Что делать прямо сейчас

1. Проверьте текущую версию pgBackRest на серверах: pgbackrest version
2. Подпишитесь на список рассылки pgsql-announce — туда придут уведомления о CVE Postgres, требующих внимания и от backup-tooling.
3. Запланируйте миграцию на wal-g или Barman в течение 6–12 месяцев. До PG19 (релиз ожидается осенью 2026) — окно есть, после — будет жать.
4. Если рассматриваете форк pgBackRest — David Steele явно просит дать форку новое имя. Это не хулиганство, а защита пользователей от путаницы между поддерживаемой и заброшенной кодовой базой.
5. Перед миграцией протестируйте новый инструмент на staging: восстановление до точки, retention-полиси, скорость parallel backup на ваших объёмах. У wal-g и Barman разная философия — на каких-то нагрузках различия в скорости в разы.

Выводы

История pgBackRest — это не «open-source умер», это про то, что donations и star-driven sponsorship не работают как модель устойчивости infrastructure-проектов. 13 лет работы, страница на GitHub Sponsors — и всё равно один человек на длинной дистанции не вытягивает. Backup-инструмент Postgres-уровня требует коммерческого стейкхолдера. У wal-g он есть (Yandex Cloud, исторически Citus Data), у Barman — EDB, у pgBackRest был Crunchy Data, и его не стало. Похожую модель устойчивости open-source проектов мы недавно разбирали на примере расширения honker для SQLite — где спонсорство сразу зашито в распределённую команду.

Для DBA практический вывод простой: ревизия инфры на «один человек = один мейнтейнер = single point of failure» и проверка, кто поддерживает критичные инструменты — продуктовая компания или энтузиаст в свободное время.

Инструменты в подборке закрывает эти задачи по-разному, поэтому для каждого разбираем не только список функций, но и где это работает.

1. Visary BI: облачная BI-платформа для анализа и визуализации данных

Visary BI — платформа бизнес-аналитики от НПЦ «БизнесАвтоматика», в реестре отечественного ПО с декабря 2023 года (реестровый номер №20974). По данным TAdviser, система на втором месте по доле на российском рынке BI за 2022–2024 годы. Поставляется в двух форматах: облако с соответствием 152-ФЗ или серверный дистрибутив — для тех, у кого данные за периметр корпоративной сети не выходят.

Что внутри

В основе три инструмента: конструктор дашбордов, конструктор отчётов и визуальный конструктор запросов.

Конструктор запросов подходит — для аналитиков, которые в целом умеют писать SELECT, но не хотят разбираться в диалекте каждой конкретной базы. Объединить 1С, Excel и CRM в один источник можно визуально, без разработчика.

No-code здесь топ-фича: источники данных добавляются без написания кода, связи между источниками настраиваются через визуальный конструктор. При необходимости поддерживается и стандартное написание SQL-запросов к БД. Периодичность обновления данных в дашбордах и отчётах задаётся системными настройками. Среднее время запуска, по данным вендора, около недели.

Отдельно стоит сказать про разграничение прав доступа — оно работает на трёх уровнях: система, дашборд, конкретный объект. Плюс полное логирование действий пользователей.

Из того, что встречается реже, чем хотелось бы в других BI-инструментах: интеграция с видеокамерами и компонент геоаналитики «Карта».

Источники данных, интеграции и экспорт

Для источника данных подключаются внешние ERP, WMS, 1С и другие системы: Visary BI поддерживает типовые коннекторы к реляционным СУБД (MS SQL, Oracle Database, PostgreSQL и др.), работает с файловыми форматами (Excel, CSV, Google Sheets и др.).

Из ОС поддерживаются Windows и AstraLinux — второе актуально для организаций, которые переходят на отечественный стек. Экспорт готовых отчётов — PDF, XLS, XLSX, DOCX, RTF, MHT, HTML, CSV, изображения.

Visary BI — часть экосистемы Visary Cloud, что это значит: корпоративный чат, видеосвязь, файловое хранилище и онлайн-редактор документов подключаются бесплатно в базовой поставке, а не продаются отдельными сервисами сверху. Если нужна трансформация данных перед загрузкой в BI — есть отдельный платный модуль Visary ETL.

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

Мы попросили вендора привести конкретные примеры, что уже происходило у клиентов.

Первый кейс — розничная сеть. Владелец нескольких точек не понимал, какие товары реально прибыльные с учётом логистики и акций: данные из 1С расходились с Excel, а сводить их вручную занимало несколько дней. Подключили оба источника и CRM. Аналитик за один рабочий день собрал дашборд с маржинальностью по категориям, выполнением плана по точкам и динамикой продаж.

Настроили ежедневную рассылку в Telegram — теперь руководитель видит актуальные данные без обращения к аналитику. От подключения источников до рабочего дашборда — три дня.

Второй кейс — производственное предприятие. Три отдела работали в изоляции: производство в ERP, склад в WMS, бухгалтерия в MSSQL. Сводный P&L собирался вручную две недели. После объединения источников через визуальный SQL-конструктор аналитики без помощи программистов создали OLAP-куб с разбивкой себестоимости по цехам, партиям сырья и временным периодам. Разграничили доступ: цех видит только свои показатели, финансисты — детализацию по статьям затрат, директор по производству — сводную. P&L теперь формируется за один день вместо двух недель. Попутно нашли систематический перерасход сырья в одном из цехов — следующий квартал закрыли с экономией 15%.

Пример дашборда мониторинга финансов

Деньги

Бесплатной версии нет. От 2 000 рублей за пользователя в месяц, тариф «Корпоратив» — 1 600 рублей. Полная сетка с детализацией по функциям — на visary.cloud/tariffs. Оплата через расчётный счёт для юридических лиц.

Для небольших команд или тех, кто хочет сначала потрогать инструмент перед покупкой, — порог входа будет ощутимым. Бесплатного пробного периода в открытом доступе нет, условия уточняются у вендора напрямую.

Поддержка и документация

Поддержка работает по Telegram, почте и телефону. Документация на русском языке, видеоуроки в открытом доступе — можно разбираться самостоятельно. По запросу проводятся очные и онлайн-курсы, что актуально, когда нужно обучить несколько команд одновременно. В роадмапе — интеграция AI-инструментов для прогнозной и предиктивной аналитики, а также развитие концепции Action BI: система не только фиксирует проблему, но и предлагает действия для решения. Например, если заметит отставания по срокам — автоматически предложит собрать совещание или пересмотреть направление проекта.

2. Visiology: корпоративная BI-платформа с собственным аналитическим движком

Visiology работает с 2015 года. 500+ клиентов, 2000+ специалистов в сообществе. Трижды побеждала в «BI-круге Громова» (2019, 2021, 2022), взяла номинацию «Драйвер BI» на «Битве BI» при поддержке Минцифры и выиграла конкурс «Лучшие цифровые решения» Аналитического центра при Правительстве РФ.

Что внутри

В основе платформы аналитический движок ДанКо. Он берёт на себя хранение, вычисления и управление доступом, а поверх него работают два продуктовых модуля.

Visiology Dashboards — среда для построения дашбордов и регламентных отчётов. Интерфейс работает в браузере на любой ОС. Поддерживается синтаксис DAX: аналитик строит сложные расчётные показатели прямо в конструкторе, без правок на уровне витрин DWH и без JS- или Python-кода. Новые представления создаются бизнес-пользователями в режиме конструктора — программирование не нужно. Виджеты переиспользуются между проектами или берутся из маркетплейса. По данным вендора, первый дашборд — через два дня после начала обучения.

Visiology Smart Forms закрывает задачу сбора данных с филиалов и подразделений. Форма открывается в браузере на компьютере или мобильном, вводить данные можно или вручную, или загрузкой Excel. Для каждого поля задаются допустимые значения и формат — выбросы система отправляет на уточнение до попадания в хранилище. После заполнения данные сразу попадают в ДанКо, без ручного импорта. Каждый пользователь видит только те ячейки, которые ему открыты по правам доступа.

Разграничение прав работает на уровне движка ДанКо: RLS-политики применяются автоматически, один и тот же дашборд покажет аналитику полную картину, а рядовому сотруднику — только его данные.

Источники данных, интеграции и экспорт

Экспорт дашбордов: PDF, PPTX, PNG. Регламентные отчёты формируются на основе шаблона Excel и можно использовать для печати. Дашборды публикуются на любой внутренний или внешний портал.

Экосистема

Self-Service ETL закрывает предобработку данных до загрузки в ДанКо — без ETL-инженера. В маркетплейсе Visiology есть готовые виджеты и решения партнёров. Для крупных внедрений есть услуги архитектурного и стратегического сопровождения.

Поддержка и документация

YouTube-канал с обучающими материалами в открытом доступе, база знаний, документация, Telegram-сообщество — вендор называет его самым активным среди российских корпоративных BI-платформ. Есть учебник по Visiology 3, история релизов и публичная дорожная карта. Подготовка специалистов — при поддержке вендора.

3. Yandex DataLens: облачный BI от Яндекса с встроенным ИИ-аналитиком

Yandex DataLens — продукт Яндекса, включён в реестр отечественного ПО, работает на сертифицированной облачной платформе и часто проходит пентесты. Поставляется в двух форматах: облако с быстрым стартом или развёртывание в собственной инфраструктуре.

Что внутри

Конструктор визуализаций работает в браузере. Дашборды собираются в визуальном редакторе, без программирования, готовые шаблоны доступны в Галерее — 91 пример по категориям: продажи, маркетинг, HR, геоаналитика, маркетплейсы.

Для сложных расчётов есть встроенный DataLens Formula Language. Когда формульного подхода недостаточно — подключается Editor: JavaScript-кастомизация визуализаций и обработка данных кодом. Там же доступны API-коннекторы для работы с BI как с кодом.

Отдельная фича, которая в других российских BI-системах пока редкость: встроенный ИИ-агент Нейроаналитик. Он создаёт вычисляемые поля в синтаксисе DataLens, пишет JavaScript для Editor и суммаризирует данные для быстрых инсайтов. Работает прямо в интерфейсе.

Права доступа настраиваются через SSO или Яндекс ID, гибко — для групп и отдельных пользователей.

Источники данных, интеграции и экспорт

Больше 30 источников: от загрузки Excel и CSV до нативных коннекторов к ClickHouse и другим СУБД. Модель данных описывается через схемы «звезда» и «снежинка» с оптимизацией связей или через нативный SQL там, где это нужно.

Экспорт дашбордов: PDF, PPTX, PNG. Готовые дашборды публикуются через iframe в корпоративные порталы, CRM и ERP. Рассылка — по расписанию или по событию, в том числе в Telegram. Интерфейс адаптирован под мобильные устройства.

Экосистема

Внешний вид платформы кастомизируется под корпоративный бренд. On-Premises поставляется как архив с Docker-контейнерами и Helm-чартами для развёртывания на k8s/k3s, с регулярными обновлениями и ранним доступом к новым функциям. Сеть из 30+ партнёров с сертифицированными специалистами берётся за внедрение под ключ.

Деньги

Два варианта. Облако — 990 рублей за рабочее место в месяц, для индивидуального использования бесплатно, пробный период 30 дней. On-Premises — от 1,6 млн рублей в год, доступна как годовая подписка, так и бессрочная лицензия.

Поддержка и документация

Telegram-сообщество насчитывает больше 14 000 участников — по этому показателю DataLens заявляет лидерство среди российских BI-платформ. Есть программа сертификации специалистов, вебинары и книга «От дашборда к системе: как построить операционную аналитику в компании» в открытом доступе. Поддержка облачной версии — от Yandex Cloud, on-premises — через авторизованных партнёров и дистрибьюторов.

4. Luxms BI: платформа бизнес-аналитики с 20-летней историей и лицензией ФСТЭК

Luxms BI — платформа ГК Luxms, работает на рынке больше 20 лет. Внесена в реестр российского ПО, имеет лицензию ФСТЭК на безопасную разработку — по этому показателю вендор заявляет первое место среди российских BI-систем. В рейтинге «Созвездие BI — 2025» платформа вошла в топ-3, заняла второе место по приросту функционала за год и первое по доле прироста в стратегии развития.

Что внутри

Платформа покрывает полный цикл работы с данными: получение и подготовка, встроенное хранилище, визуализация, отчётность, администрирование и кастомизация. Self-Service позволяет бизнес-пользователям строить дашборды самостоятельно.

Отдельный продукт внутри экосистемы — Luxms Data Boring, встроенный ETL/ELT-инструмент. Он закрывает задачу предобработки данных до загрузки в платформу. Есть даже поддержка write-back (обратная запись данных через формы ввода прямо в дашбордах), графовые базы данных для анализа связей, предиктивное обслуживание оборудования через интеграцию с IoT-датчиками.

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

Источники данных, интеграции и экспорт

Платформа подключается к CRM, ERP, реляционным СУБД, Excel и внешним API. Есть совместимость с Arenadata Prosperity и Tantor Certified 15. Среди форматов работы с данными: массовая загрузка из Excel, реестровый сбор через веб-формы, интеграция с LoRaWAN-датчиками.

Поддержка и документация

Документация разделена на три роли: оператор, аналитик, администратор. Обучение проводится очно, есть официальный Telegram-канал и отдельное комьюнити для пользователей платформы. Услуги включают внедрение, техподдержку, технический аккаунт-менеджмент и миграцию с Qlik, Power BI и SAP.

Вместо вывода

На что смотреть в первую очередь: формат поставки, скорость первого результата и стоимость владения с учётом всей команды, а не одного аналитика. Разница между «попробовать» и «внедрить» здесь бывает ощутимой — у части платформ бесплатного периода нет вообще, условия уточняются только через запрос.

Если нужна точка входа и быстрое решение: Visary BI стартует от 2 000 рублей за пользователя в месяц, среднее время от подключения источников до рабочего дашборда по данным вендора — около трёх дней. Для команды, которая хочет сначала увидеть результат, а потом принимать решение о масштабировании, это конкретный ориентир. Остальное зависит от задачи: объём данных, инфраструктурные требования, нужен ли ETL внутри платформы или он уже есть.

Джон Чартер в статье «Things you didn't know about indexes» разбирает не только базовые принципы B-tree, но и три типа индексов, о которых новичкам не рассказывают: функциональные, частичные и покрывающие. Переводим полностью, с примерами на таблице покемонов и объяснением, почему EXPLAIN — ваш лучший друг.

Индексы ускоряют чтение, но замедляют запись. INSERT, UPDATE и DELETE обновляют каждый индекс — восемь индексов на таблице значат восемь дополнительных обновлений.

Композитный индекс (type_1, type_2) работает для запросов на type_1 и на обе колонки вместе, но не для запросов только на type_2. Порядок колонок важен.

Функция над индексированной колонкой убивает индекс. WHERE lower(name) = 'pikachu' не использует индекс на name — нужен функциональный индекс на lower(name).

Частичный индекс с WHERE покрывает только нужные строки. Для soft-delete или редких флагов экономит место и ускоряет запись.

Покрывающий индекс с INCLUDE отвечает на запрос без похода в таблицу — в EXPLAIN это Index Only Scan.

Не угадывайте — используйте EXPLAIN ANALYZE. Он показывает реальный план запроса и реальное время выполнения.

Начнём с того, что вы, вероятно, уже знаете

Индекс в базе данных похож на алфавитный указатель в конце учебника. Хотите найти страницы про фосфор? Идёте в конец, находите тему и номера страниц рядом с ней:

Представим таблицу покемонов:

Без индекса поиск Пикачу означает, что база прочитает каждую строку, проверяя колонку name. На четырёх строках это мгновенно. На десяти миллионах — уже проблема. Такое чтение называется full table scan, и оно не медленное само по себе: современные базы легко прошивают миллионы строк в секунду. Проблема в линейной сложности — удваиваете число строк, удваиваете время. Индексный поиск этой разницы почти не замечает.

Но если добавить индекс на name, получится примерно то же, что указатель в учебнике:

Данные отсортированы, поэтому база может сделать бинарный поиск по имени и найти нужную строку, а не сканировать всю таблицу. Под капотом Postgres хранит это как B-tree (сбалансированное дерево), но идея такая же, как в учебнике: отсортированные данные, по которым можно быстро искать.

Итак, индексируем всё подряд, верно? Не так быстро.

Цена индексации

Как бы ни хотелось проиндексировать всё, у индексов есть компромиссы. Главное правило:

Чтение ускоряется, запись замедляется.

С новым блестящим индексом каждый INSERT, UPDATE и DELETE должен обновить и индекс тоже. Когда мы добавляем нового покемона, база находит правильное место в отсортированном индексе имён и вставляет его туда. А индексов может быть несколько — умножайте эту работу на каждый из них.

Плюс индексы — это реальные структуры данных, и их нужно хранить. Они живут на диске и подгружаются в память: в Postgres это shared_buffers. У таблицы с восемью индексами девять объектов, которые конкурируют за буфер, а не один.

И не забываем про планировщик (query planner) — компонент, который перед каждым запросом оценивает варианты доступа к данным и выбирает самый дешёвый. Чем больше индексов, тем больше вариантов он взвешивает, так что время планирования растёт и на быстрых выборках может даже превысить время выполнения.

Отдельный риск на проде. Обычный CREATE INDEX блокирует таблицу на запись до конца построения. На таблице в десятки миллионов строк это минуты недоступности. В production используйте CREATE INDEX CONCURRENTLY — он строит индекс без эксклюзивной блокировки, ценой чуть большего времени и того, что операция может быть прервана и оставить индекс в состоянии INVALID (который надо пересобрать).

Почему ваш индекс не работает

Вы взвесили компромиссы, решили, что индекс уместен. Отлично. Но он не работает как ожидалось: улучшения нет или, хуже того, скорость падает. Разберём типичные грабли.

Композитные индексы и порядок колонок

Возвращаясь к таблице покемонов: вы могли решить, что хороший индекс — это индекс на type_1 и type_2. «Покажи всех покемонов типа Water и Flying» — вполне разумный запрос.

Этот индекс определённо поможет запросам вроде:

Но вот этому — уже нет:

Удивлены? Когда вы создаёте композитный индекс (type_1, type_2), вы просите базу построить структуру примерно такого вида:

Сначала сортировка по type_1, затем по type_2 внутри каждой группы. Для запросов по type_1 индекс отличный, для запросов по type_1 AND type_2 — ещё лучше, но для запросов только по type_2 он не будет использован так, как вы надеетесь. Посмотрите на Flying: он разбросан под Bug, Electric, Fire и Water — базе некуда прыгнуть.

Задайте себе вопрос: какие запросы будут частыми? Если по type_2 вы будете искать так же часто, как по type_1, создайте второй индекс на type_2.

Функции убивают индекс

Поиск без учёта регистра — частая фича. Пользователям всё равно, пишут ли они «Pikachu», «pikachu» или «PiKaChU» — они просто хотят результат. Поэтому можно написать так:

Я бы не обратил на такой запрос особого внимания. Выглядит нормально. У нас есть индекс на name, запрос должен летать. Но, конечно, он не летает.

Почему? Индекс на name, а не на lower(name). Для базы это две совершенно разные вещи. Ваш индекс — это отсортированный список значений вида Bulbasaur, Charmander, Squirtle, Pikachu, а не bulbasaur, charmander, squirtle, pikachu. Так что когда вы просите строки, где lower(name) = 'pikachu', у базы нет отсортированной структуры для этого — и она откатывается к сканированию всей таблицы, приводя каждое имя к нижнему регистру по ходу дела.

Это касается любой функции, оборачивающей колонку. Если база не видит индексированную колонку слева от сравнения, индекс выбывает из игры.

И вот настоящие грабли: неявные преобразования тоже считаются. Классический пример — колонка user_id типа bigint сравнивается со строкой (WHERE user_id = '42') или timestamp сравнивается со строковой датой. Postgres тихо добавит приведение типа — и индекс работать перестанет с тем же эффектом, что и явная обёртка функцией.

Как обойти это? К счастью, можно построить индекс на выражении. Индекс на lower(name) абсолютно валиден, и запрос выше будет использовать его без проблем. К этому мы ещё вернёмся.

Как избежать этих ловушек

Короткий ответ: не гадайте. Измеряйте. Как? Спросите базу.

В Postgres есть инструмент EXPLAIN, который показывает, как именно база собирается выполнить запрос. Поставьте его перед любым SELECT — и получите отчёт:

Index Scan — это то, что вы хотите видеть. Значит, база использует индекс. Сравните с проблемным запросом:

Seq Scan значит, что читается каждая строка. Никаких индексов.

Если хотите реальные тайминги вместо оценок планировщика, используйте EXPLAIN ANALYZE. Он действительно запускает запрос и сообщает, что произошло. Попробуйте на запросе, который, как вам кажется, вы понимаете — результаты часто удивляют. А если Postgres тормозит не из-за индексов — у нас есть 12 шагов диагностики, от pg_stat_activity до auto_explain.

Чего вам не рассказывали

Мы разобрали базовый индекс на одной колонке и его композитного брата. Вместе они покрывают большинство случаев. Но есть ещё несколько видов индексов, которые иногда оказываются именно тем, что нужно.

Сначала оговоримся про типы индексов в целом. Всё, о чём мы пока говорили, — это B-tree, тип по умолчанию в Postgres. Но для нестандартных задач есть другие: GIN для jsonb и полнотекстового поиска, GiST для геоданных и диапазонов, BRIN для огромных таблиц с физически упорядоченными данными (логи, временные ряды), Hash для точного равенства. Ниже речь идёт именно о B-tree — но идеи функциональных, частичных и покрывающих индексов применимы и к другим типам.

Функциональные индексы

Мы затрагивали это в разделе про функции. Проблемный запрос был такой:

Индекс на name не помогает, потому что база ищет строки с lower(name) = ..., а отсортированной структуры для lower(name) у неё нет. Исправление — дать ей такую структуру:

Это функциональный индекс (его ещё называют индексом на выражении). Вместо того, чтобы индексировать сырую колонку, вы индексируете результат выражения, применённого к ней. Конечно, это не ограничивается lower(). Можно индексировать любое детерминированное выражение:

Годится любая функция с меткой IMMUTABLE — в Postgres это означает, что она возвращает одинаковый результат для одинаковых аргументов при любых условиях (в отличие от STABLE, которая детерминирована только в рамках одной транзакции, и VOLATILE).

Но осторожно. Если тянуться к функциональному индексу при первом же случае, это часто плохой запах. Если мы так часто ищем по имени в нижнем регистре, почему мы вообще не храним имя в нижнем регистре? Альтернативы: отдельная колонка name_lower, которую заполняете на вставке; тип citext (case-insensitive text) из одноимённого расширения; или COLLATE с регистронезависимой коллацией. Функциональный индекс — когда изменить хранение уже нельзя.

Частичные индексы

Большинство индексов покрывает каждую строку таблицы. Но иногда вы запрашиваете только её небольшой срез — и индексировать всё подряд расточительно. Напомню: индексы не бесплатны.

В нашей таблице покемонов есть колонка is_legendary. На момент написания существует около 1000 видов покемонов, из которых легендарными считаются всего 80 — меньше 10%.

Представьте приложение с опцией «показать всех легендарных». Изначально так и хочется создать составной индекс:

Это работает, но это перебор. Индекс теперь содержит запись для каждого покемона, а подавляющее большинство — не легендарные. Мы будем платить за хранение и запись 1000 строк, чтобы обслуживать запросы, которым интересны только 80. Более того, поскольку is_legendary — булево, получается структура, где сначала идёт разделение на False и True, и первая группа — это 920 записей мёртвого груза, оплачивающих свою долю каждой записи в таблицу ради запросов, которые их игнорируют.

Частичный индекс покрывает только строки, которые подходят под условие:

Теперь в индексе 80 записей вместо 1000. Он меньше, быстрее в запросах; а запросы вида WHERE is_legendary = true используют его без вопросов. Запросы, которые не подходят под условие (WHERE is_legendary = false), откатываются к full table scan — что вам и нужно. Эти запросы и так матчат почти каждую строку, так что индекс им не особо помог бы.

Любая колонка, где вы почти всегда запрашиваете одно значение, — кандидат на частичный индекс. Представьте индекс на колонке email в таблице users, где у вас реализован soft-delete:

Soft-deleted строки почти никогда не запрашиваются, но без фильтра всё равно раздували бы ваши индексы.

Покрывающие индексы

Когда база использует индекс, чтобы найти строку, это только половина работы. Индекс указывает, где строка лежит, но потом база должна сходить в саму таблицу и забрать остальные колонки, которые запросил запрос. Две поездки.

А что, если я скажу, что так делать необязательно?

Если в индексе уже есть все колонки, которые нужны запросу, база может ответить на запрос из одного только индекса. Это покрывающий индекс. В EXPLAIN вы увидите его как Index Only Scan — три самых сладких слова из возможного вывода EXPLAIN.

Одна важная оговорка. Даже при Index Only Scan Postgres всё же заглядывает в visibility map — битовую карту, которая для каждой страницы таблицы отмечает, видимы ли все её строки всем активным транзакциям. Если страница «грязная» (были недавние UPDATE/DELETE), Postgres всё равно пойдёт в heap за проверкой MVCC. Так что на интенсивно пишущих таблицах регулярный VACUUM (автовакуум обычно справляется) критичен для того, чтобы Index Only Scan оставался «онли».

Вот запрос:

Наш частичный индекс из предыдущего раздела идеально покрывает этот запрос. Индекс на name, отфильтрованный по легендарным, — и запрос просит name легендарных. Всё, что нужно запросу, уже в индексе. Поход в таблицу не нужен.

Покрывающие индексы можно строить и специально. Postgres позволяет добавить к индексу дополнительные колонки через INCLUDE:

Теперь на такой запрос можно ответить прямо из индекса:

Почему не положить base_attack прямо в индексируемые колонки? Потому что база считает индексируемые колонки тем, по чему нужно сортировать и искать. Если добавить base_attack в ключевые колонки индекса, вы скажете базе сортировать индекс сначала по name, потом по base_attack — дополнительная работа, которая не нужна, если вы ищете только по name. INCLUDE говорит: «тащи эту колонку с собой, но не морочься сортировкой».

Правка автора: когда на самом деле нужен INCLUDE

В комментариях на Reddit автор получил поправку от u/therealgaxbo и обновил статью. Скорость записи — не главная причина использовать INCLUDE для покрывающих индексов: в обоих случаях (колонка в ключе или в INCLUDE) индекс обновляется при каждой записи, разница по нагрузке скромная.

Реальные причины использовать INCLUDE:

Можно включать колонки, у которых типы данных не имеют подходящего operator class для типа индекса (operator class — набор функций сравнения, по которым Postgres строит индекс для конкретного типа; для некоторых типов он просто не определён). Например, колонку box (геометрический прямоугольник) нельзя добавить в B-tree индекс как ключевую — нет оператора «меньше/больше». А через INCLUDE можно.

Можно добавить колонки в уникальный индекс без изменения его семантики уникальности:

Это обеспечивает уникальность только по email, но при этом покрывает запросы, которым нужен user_id.

Выводы

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

Хотите глубже? Сайт Use The Index, Luke научит вас всему, что только можно знать про индексы в разных СУБД. А если вы только начинаете с Postgres — загляните в наши основы PostgreSQL: от установки до первых запросов.

И не забудьте запустить EXPLAIN ANALYZE хотя бы на одном запросе сегодня — результаты могут вас удивить.

Источник: jon.chrt.dev — Things you didn't know about indexes

• SQLCommenter — формат тегов в SQL-комментариях, по которым Traffic Control различает запросы
• Изоляция микросервисов через Postgres-роли и application_name
• Автоматическая маркировка запросов по HTTP-роутам через middleware
• Контроль новых деплоев и фича-флагов через теги feature
• Tier-based лимиты для мультитенантных SaaS-приложений
• Обработка ошибки SQLSTATE 53000 при блокировке запроса

Перевод статьи Patterns for Postgres Traffic Control Джоша Брауна из блога PlanetScale.

Настройка: SQLCommenter и передача тегов через контекст

Большинство паттернов опираются на пользовательские теги, прикреплённые к запросам. Traffic Control читает их в формате SQLCommenter — это SQL-комментарий с URL-кодированными парами ключ=значение, добавляемый в конец запроса:

Эти теги затем доступны для правил Traffic Control. Вот минимальный хелпер на Go, который добавляет теги в этом формате:

Если вы используете pgx с включённым PrepareThreshold, комментарий SQLCommenter станет частью ключа кэша prepared statement. Это может привести к разрастанию кэша планов. Решение — отключить PrepareThreshold для подключений с тегированием или использовать SimpleProtocol.

Примеры кода рассчитаны на Go 1.22+. В частности, r.Pattern (поле http.Request) и range по целому числу (for attempt := range maxRetries) появились именно в этой версии.

Также понадобится способ пробрасывать теги через стек вызовов без изменения каждой сигнатуры функции. Ключ контекста отлично подходит для этого:

С этими двумя хелперами паттерны ниже просто устанавливают ключи и значения в контексте. Тегирование происходит автоматически при выполнении запроса.

Изоляция сервисов через Postgres-роли

В микросервисной архитектуре один «взбесившийся» сервис не должен деградировать все остальные сервисы, использующие ту же базу данных. Простейший способ изолировать сервис — создать правило Traffic Control на основе уникальной строки подключения или application_name.

Бюджет на username='pscale_api_123abc' изолирует весь трафик от этой роли. Это также помогает при инцидентах — можно мгновенно ограничить долю ресурсов сервиса без передеплоя.

Имя пользователя — это внутреннее Postgres-имя роли, а не имя роли в дашборде. Также можно целиться в кастомные роли, созданные через CREATE ROLE, если ваши микросервисы строго разделяют права на таблицы.

Также можно использовать application_name, добавив его к строке подключения:

Маркировка запросов по HTTP-роутам

Когда вы запускаете монолит или крупный API-сервис, проблема обычно не в целом сервисе — а в конкретных роутах. Эндпоинт /api/export, генерирующий CSV-отчёты, не должен убивать /api/checkout.

HTTP-middleware может инжектировать роут в контекст во время выполнения, до запуска любого обработчика:

Оберните вызовы к базе данных, чтобы они автоматически подхватывали теги:

Теперь каждый запрос несёт информацию о роуте, из которого пришёл. Можно создать бюджет Traffic Control для route='/api-export' и задать ему консервативный лимит CPU.

Это также упрощает управление инцидентами. Если вы видите всплеск и не знаете, какой роут виноват — график нарушений в Traffic Control покажет, какой именно тег route достигает лимитов.

Фича-флаги и новые деплои

Выкатка новой фичи в production всегда несёт риск. Может, новый паттерн запросов нормально работает под тестовой нагрузкой, но становится дорогим на масштабе. Traffic Control позволяет ограничить радиус поражения до того, как ситуация превратится в инцидент.

Простейшая версия устанавливает тег из переменной окружения при старте:

Установите DEPLOYMENT_TAG=new_checkout_v2 при раскатке новых подов и оставьте переменную пустой на старых. Traffic Control может иметь бюджет на feature='new_checkout_v2' в режиме Warn с первого дня — так вы увидите, как новый код себя ведёт, прежде чем он вызовет проблемы.

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

Tier-based лимиты для мультитенантных приложений

В SaaS-приложении пользователи бесплатного тарифа не должны деградировать работу enterprise-клиентов. Traffic Control позволяет обеспечить это на уровне базы данных, а не только на уровне приложения.

Инжектируйте тариф пользователя в SQL-теги сразу после аутентификации:

В middleware аутентификации:

Теперь создайте два бюджета Traffic Control:

• tier='free' — консервативные лимиты на долю сервера и максимальное число параллельных запросов
• tier='pro' — умеренные лимиты

Enterprise-трафик оставьте без бюджета или задайте высокий потолок. Когда пользователь бесплатного тарифа запускает тяжёлый дашборд или триггерит медленный запрос — бюджет сбросит этот трафик до того, как он затронет enterprise-нагрузки.

Паттерны можно комбинировать. Бюджет tier='free' AND route='api-export' будет строже, чем бюджет только на tier='free'. Enterprise-экспорты получат больше ресурсов, чем бесплатные.

Фоновые задачи и скрипты

Фоновые задачи — частая причина инцидентов с базой данных. Миграция, ночная синхронизация или одноразовый бэкфилл данных могут случайно насытить БД, если выполняются быстрее ожидаемого. Traffic Control — чистый способ задать потолок ресурсов без настройки таймаутов на уровне каждого запроса.

Для долгоживущих фоновых воркеров используйте выделенный пул подключений с отдельным application_name:

Функция newJobDB принимает DSN базы и устанавливает application_name в background-jobs перед подключением. Максимум подключений ограничен четырьмя, чтобы фоновая задача не занимала больше воркеров, чем положено.

Установка application_name на уровне строки подключения в коде гарантирует, что имя всегда задано для этого сервиса — независимо от конкретного запроса или переменных окружения. Это можно комбинировать с SQL-комментариями для ещё более гранулярного контроля.

Для одноразовых скриптов и миграций — аналогичный подход. Здесь идентичность скрипта кодируется прямо в строке подключения:

Создайте бюджет Traffic Control для application_name='background-jobs' в режиме Warn. Понаблюдайте, сколько ресурсов базы обычно потребляет фоновая работа. Затем переключите на Enforce, чтобы ограничить её на уровне, при котором она не сможет вытеснить интерактивный трафик.

Обработка заблокированных запросов

Когда Traffic Control в режиме Enforce и запрос превышает бюджет, Postgres возвращает SQLSTATE 53000 с сообщением, начинающимся с [PGINSIGHTS] Traffic Control:. Приложение должно обрабатывать это без падения.

С pgx/v5:

Правильная реакция зависит от роли запроса в приложении. Для некритичных нагрузок — аналитики, отчётов — возвращайте 503 или закэшированный результат:

Для критичных путей можно реализовать короткий retry с экспоненциальным backoff:

Наблюдение за Warn-режимом

Прежде чем переключить бюджет в Enforce, запустите его в режиме Warn. В этом режиме запросы выполняются успешно, но драйвер получает Postgres-notice. С pgx/v5 можно логировать их, чтобы понять, что именно будет заблокировано:

Соберите логи за несколько часов репрезентативного трафика. Паттерн срабатываний подскажет, нужно ли корректировать лимиты.

Собираем всё вместе

Паттерны компонуются. В реальном приложении можно наслоить несколько из них:

Traffic Control видит всё это как комбинацию тегов. Бюджет на tier='free' покрывает весь free-трафик независимо от роута. Бюджет на route='api-export' AND tier='free' — конкретную комбинацию. Несколько совпадающих бюджетов применяются одновременно, и запрос должен удовлетворять каждому из них.

Начните в режиме Warn, понаблюдайте, какие бюджеты срабатывают при нормальной нагрузке, ужесточайте лимиты, пока не будут триггериться только патологические случаи — затем переключите на Enforce.

Выводы

Разница между падением базы и деградированным опытом часто сводится к тому, решили ли вы заранее, какой трафик сбрасывать. Traffic Control делает это решение явным и конфигурируемым — вместо того чтобы оставлять его на милость гонки за ресурсы.

Полный текст оригинальной статьи — в блоге PlanetScale.

Этот путеводитель — не просто список ссылок. Каждая секция содержит самостоятельный разбор темы: от истории SQL и принципов работы реляционных баз до транзакций, нормализации и защиты от инъекций. Там, где тема заслуживает глубокого погружения, мы даём ссылку на отдельную статью. Цель — дать полную карту знаний, по которой можно выстроить обучение от нуля до уверенного уровня.

— SQL — фундаментальный навык для любого, кто работает с данными: от джуна до архитектора

— Основные команды (SELECT, JOIN, GROUP BY) покрывают 80% повседневных задач

— Порядок выполнения запроса (FROM → WHERE → GROUP BY → SELECT) — ключ к пониманию SQL

— Транзакции, ACID и уровни изоляции гарантируют надёжность данных

— Оконные функции, CTE и хранимые процедуры — продвинутый уровень для карьерного роста

— PostgreSQL — СУБД №1 в 2024 по Stack Overflow Survey, обогнавшая MySQL

— SQL не устареет: стандарт развивается, появляются JSON-запросы и графовый SQL

Что такое SQL и зачем его учить

SQL (Structured Query Language) — декларативный язык для работы с реляционными базами данных. «Декларативный» означает, что вы описываете что хотите получить, а не как это сделать. Вы пишете «дай мне все заказы за март», а СУБД сама решает, в каком порядке обходить таблицы и какие индексы использовать.

Краткая история: в 1970 году Эдгар Кодд из IBM опубликовал реляционную модель данных. В 1974 Дональд Чемберлин и Рэймонд Бойс создали язык SEQUEL (Structured English Query Language) для работы с этой моделью. Позже его переименовали в SQL из-за торговой марки. В 1986 году ANSI принял SQL как стандарт, а последняя версия — SQL:2023 — добавила поддержку JSON и графовых запросов.

Его используют бэкендеры, аналитики, дата-инженеры и даже тестировщики. И в обозримом будущем SQL никуда не денется — язык продолжает развиваться вместе со стандартом.

Как работает SQL: от запроса до результата

Когда вы отправляете SQL-запрос, внутри СУБД происходит цепочка шагов:

1. Парсинг — СУБД разбирает текст запроса, проверяет синтаксис и строит дерево разбора
2. Анализ — проверяет, существуют ли таблицы и столбцы, есть ли у пользователя права доступа
3. Оптимизация — самый важный этап. Оптимизатор строит несколько вариантов плана выполнения и выбирает самый дешёвый по стоимости (I/O, CPU, память)
4. Выполнение — движок исполняет выбранный план: сканирует таблицы, применяет фильтры, объединяет результаты
5. Возврат результата — СУБД формирует набор строк и отправляет клиенту

Логический порядок выполнения запроса

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

1. FROM / JOIN — определяется источник данных, выполняются соединения
2. WHERE — фильтрация строк (до группировки)
3. GROUP BY — группировка
4. HAVING — фильтрация групп (после группировки)
5. WINDOW — вычисление оконных функций
6. SELECT — выбор столбцов, вычисление выражений и алиасов
7. DISTINCT — удаление дублей
8. ORDER BY — сортировка (по стандарту SQL единственное место, где гарантированно работает алиас из SELECT (в PostgreSQL и MySQL алиасы также работают в GROUP BY))
9. LIMIT / OFFSET — ограничение количества строк

Из-за этого порядка нельзя использовать алиас из SELECT в WHERE — на момент фильтрации SELECT ещё не выполнен. А HAVING работает после GROUP BY, поэтому в нём доступны агрегатные функции.

Именно благодаря оптимизатору SQL остаётся эффективным: вы пишете простой запрос, а СУБД сама выбирает, использовать ли индекс, в каком порядке объединять таблицы, нужна ли сортировка. Увидеть план выполнения можно командой EXPLAIN ANALYZE — это один из главных инструментов оптимизации.

Основные команды SQL

Любое знакомство с SQL начинается с четвёрки CRUD: SELECT (чтение), INSERT (создание), UPDATE (изменение), DELETE (удаление). К ним добавляются DDL-команды для управления структурой: CREATE TABLE, ALTER TABLE, DROP TABLE, TRUNCATE TABLE (быстрое удаление всех строк без логирования каждой).

Реальная мощь SQL раскрывается в объединениях через JOIN (INNER, LEFT, RIGHT, FULL), группировке с GROUP BY и фильтрации агрегатов через HAVING. Пример: найти средний чек по городам, где было больше 100 заказов: А также CROSS JOIN (декартово произведение всех строк) и SELF JOIN (соединение таблицы с собой — например, для поиска сотрудников и их руководителей).

На практике эти команды покрывают примерно 80% задач. Полный разбор с примерами — в нашем гайде по основным командам SQL. Статью прочитали полтора миллиона раз.

Типы данных и ограничения SQL

Правильный выбор типов данных — основа производительной и надёжной базы. Базовые типы SQL:

• Числовые: INTEGER, BIGINT, DECIMAL(10,2), FLOAT
• Строковые: VARCHAR(255), TEXT, CHAR(10)
• Дата и время: DATE, TIMESTAMP, INTERVAL
• Логический: BOOLEAN
• JSON: JSON / JSONB (PostgreSQL) — для полуструктурированных данных

Ограничения (constraints) — это правила, которые СУБД проверяет автоматически при каждой вставке и обновлении:

PRIMARY KEY гарантирует уникальность строки. FOREIGN KEY связывает таблицы и не даёт создать «висячие» ссылки. NOT NULL запрещает пустые значения. CHECK валидирует данные по условию. Вместе эти ограничения защищают целостность данных на уровне структуры — СУБД не позволит вставить строку, нарушающую правила.

Операторы и выражения

За базовыми командами идут операторы, которые делают запросы по-настоящему гибкими. WHERE фильтрует строки, LIKE ищет по шаблону с подстановочными знаками (% — любая подстрока, _ — один символ), IN проверяет вхождение в список, BETWEEN задаёт диапазон.

Отдельного внимания заслуживает CASE WHEN — условная логика прямо внутри запроса:

Подробный разбор LIKE с примерами — в отдельной статье.

NULL: подводные камни

NULL — не значение, а отсутствие значения. NULL = NULL возвращает не TRUE, а NULL. Единственный способ проверки — IS NULL / IS NOT NULL.

Функции даты и времени

Работа с датами — повседневная задача аналитика:

• NOW() / CURRENT_DATE — текущий момент / дата
• DATE_TRUNC('month', ts) — округление до начала периода
• EXTRACT(YEAR FROM ts) — извлечение части даты
• ts + INTERVAL '7 days' — арифметика с датами

Строковые и математические функции

Помимо дат и агрегатов, SQL предоставляет богатый набор функций для работы со строками и числами. Строковые функции: CONCAT — склейка строк, SUBSTRING — извлечение подстроки, LENGTH — длина строки, UPPER / LOWER — смена регистра, REPLACE — замена подстроки, TRIM — удаление пробелов по краям. Математические: ROUND — округление, ABS — модуль числа, CEIL / FLOOR — округление вверх и вниз. Эти функции работают одинаково в PostgreSQL, MySQL и других СУБД (с минимальными различиями в именах).

Операторы множеств: UNION, INTERSECT, EXCEPT

Эти операторы объединяют результаты нескольких запросов:

• UNION — объединение с удалением дубликатов. UNION ALL — без удаления (быстрее)
• INTERSECT — пересечение (строки из обоих запросов)
• EXCEPT — разность (строки из первого, которых нет во втором)

Агрегатные функции SQL

Агрегатные функции вычисляют одно значение по набору строк: COUNT, SUM, AVG, MIN, MAX. Работают в связке с GROUP BY.

Нюансы, которые часто путают:

• COUNT(*) считает все строки (включая NULL). COUNT(column) — только строки, где column не NULL
• COUNT(DISTINCT column) — количество уникальных значений
• AVG игнорирует NULL — если NULL означает «0», результат будет завышен

Подзапросы, CTE и представления

Когда запрос становится сложным, его нужно декомпозировать. Для этого есть три инструмента.

Подзапросы

Запрос внутри запроса. Бывают скалярные (возвращают одно значение), табличные (набор строк) и коррелированные (ссылаются на внешний запрос):

CTE (Common Table Expressions)

Конструкция WITH позволяет дать имя подзапросу и переиспользовать его. CTE делают сложные запросы читаемыми, а рекурсивные CTE позволяют обходить деревья и графы:

Рекурсивные CTE

Рекурсивные CTE обходят деревья и графы — например, оргструктуру компании или вложенные категории:

Представления (Views)

CREATE VIEW создаёт «виртуальную таблицу» — именованный запрос, к которому можно обращаться как к обычной таблице. Это удобно для инкапсуляции сложной логики и разграничения доступа. Материализованные представления (MATERIALIZED VIEW в PostgreSQL) хранят результат физически и обновляются по команде — полезно для тяжёлых аналитических запросов.

Хранимые процедуры и функции

Хранимые процедуры и функции — SQL-код, сохранённый на сервере СУБД. Функция возвращает значение и вызывается в SELECT, процедура выполняет действия и вызывается через CALL.

Когда использовать:

• Инкапсуляция бизнес-логики на уровне базы (расчёт скидок, начисление бонусов)
• Повторяющиеся многошаговые операции (ежемесячные отчёты, архивация)
• Безопасность: SECURITY DEFINER позволяет давать доступ к функции, не давая доступ к таблицам

Когда не использовать:

• Логику приложения лучше держать в коде — её проще тестировать и деплоить
• Тяжёлые вычисления: масштабировать сервер СУБД дороже, чем сервер приложения
• Бизнес-логика, которая часто меняется — миграции хранимых процедур болезненнее, чем код

Триггеры — особый тип: они срабатывают автоматически при INSERT/UPDATE/DELETE. Полезны для аудита (логировать все изменения) и автоматических вычислений, но злоупотреблять не стоит — скрытая логика усложняет отладку.

Оконные функции SQL

Оконные функции — это то, что отделяет новичка от уверенного SQL-разработчика. Они выполняют вычисления по «окну» строк, не сворачивая результат как GROUP BY. Вы получаете и агрегат, и исходные строки одновременно.

Ключевые функции: ROW_NUMBER() для нумерации, RANK() / DENSE_RANK() для ранжирования, LAG() / LEAD() для сравнения с соседними строками, агрегатные функции с OVER() для скользящих средних и нарастающих итогов.

Типичные задачи: топ-N в каждой группе, рост метрики месяц к месяцу, скользящее среднее за 7 дней. Без оконных функций эти задачи требуют громоздких подзапросов.

RANK() пропускает позиции после одинаковых значений (1, 2, 2, 4), а DENSE_RANK() — нет (1, 2, 2, 3). Для скользящих агрегатов используется конструкция ROWS BETWEEN — например, ROWS BETWEEN 6 PRECEDING AND CURRENT ROW для скользящего среднего за 7 дней.

Детальный разбор с визуальными примерами — в нашей статье об оконных функциях SQL.

Транзакции и ACID в SQL

Транзакция — группа операций, которые выполняются как единое целое: либо всё, либо ни одна. Классический пример — перевод денег:

Если между двумя UPDATE произойдёт сбой, ROLLBACK откатит обе операции — деньги не потеряются и не удвоятся. Для частичного отката используется SAVEPOINT: можно откатить транзакцию не целиком, а до определённой точки (ROLLBACK TO SAVEPOINT имя).

Свойства ACID гарантируют надёжность транзакций:

• Atomicity (атомарность) — транзакция неделима: либо выполнена полностью, либо отменена целиком
• Consistency (согласованность) — после транзакции база остаётся в корректном состоянии, все ограничения соблюдены
• Isolation (изоляция) — параллельные транзакции не мешают друг другу. Уровни: от READ UNCOMMITTED (быстро, но грязные чтения) до SERIALIZABLE (безопасно, но медленно)
• Durability (долговечность) — после COMMIT данные сохранены даже при аварии сервера

ACID — фундамент надёжности реляционных баз данных. Именно эти свойства гарантируют, что данные не потеряются и не «рассинхронятся» даже при сбоях и параллельных запросах.

Уровни изоляции

Свойство Isolation на практике настраивается через уровни изоляции. Каждый уровень — компромисс между корректностью и производительностью:

• READ UNCOMMITTED — самый слабый: видны незакоммиченные изменения других транзакций (dirty reads). Практически не используется
• READ COMMITTED — видны только закоммиченные данные. По умолчанию в PostgreSQL. Достаточно для большинства приложений
• REPEATABLE READ — повторное чтение строки всегда даёт тот же результат. По умолчанию в MySQL. Защищает от non-repeatable reads
• SERIALIZABLE — максимальная изоляция, транзакции ведут себя как последовательные. Нужен для финансовых операций и бронирований

Нормализация и проектирование схем

Нормализация — процесс организации таблиц так, чтобы минимизировать дублирование данных и аномалии при вставке, обновлении и удалении.

Три ключевые нормальные формы:

1. 1NF — каждая ячейка содержит одно атомарное значение. Никаких «Москва, Питер» в одном поле — разносим по строкам или связанным таблицам
2. 2NF — все неключевые столбцы зависят от всего первичного ключа, а не от его части. Актуально для составных ключей
3. 3NF — неключевые столбцы не зависят друг от друга. Если город определяет страну, нужна отдельная таблица городов

Пример: таблица заказов до и после нормализации до 3NF:

В этом примере мы устранили дублирование данных клиента (2NF). Для полной 3NF нужно было бы вынести и города в отдельную таблицу, если город определяет дополнительные атрибуты (страну, регион).

На практике большинство баз проектируют в 3NF. Но иногда данные намеренно денормализуют — например, в аналитических хранилищах (OLAP), где скорость чтения важнее экономии места. Схемы «звезда» и «снежинка» в data warehouse — это контролируемая денормализация.

Производительность и оптимизация

Когда таблица вырастает до миллионов строк, наивные запросы начинают тормозить. Первый инструмент диагностики — EXPLAIN ANALYZE: он показывает, какой план выбрал оптимизатор, сколько строк просканировал и где узкое место.

Типичные антипаттерны:

• SELECT * вместо конкретных столбцов — читает больше данных, чем нужно
• Отсутствие индекса на столбцах в WHERE и JOIN — приводит к полному сканированию таблицы (Seq Scan)
• Функции на индексированных столбцах: WHERE UPPER(email) = ... — индекс не используется
• N+1 запросы из ORM — 1 запрос за список + N запросов за детали каждой записи

Индексы — главный способ ускорения. B-tree индекс (по умолчанию) подходит для большинства задач: точные совпадения, диапазоны, сортировка. PostgreSQL также поддерживает GiST (геоданные), GIN (полнотекстовый поиск, JSONB) и BRIN (временные ряды).

Глубокий разбор типов индексов и их применения — в нашей статье об индексах PostgreSQL.

Безопасность: SQL-инъекции

SQL-инъекция — одна из самых опасных уязвимостей веб-приложений, стабильно входящая в OWASP Top 10. Суть: если пользовательский ввод подставляется в запрос без обработки, злоумышленник может изменить логику запроса.

Классический пример — форма логина:

Защита проста и надёжна — параметризованные запросы (prepared statements):

Пароли в реальных приложениях никогда не хранят и не сравнивают в открытом виде — их хешируют (bcrypt, argon2), а проверку выполняет код приложения, не SQL-запрос.

При использовании ORM (SQLAlchemy, Django ORM, Prisma) параметризация происходит автоматически. Если пишете raw SQL — никогда не вставляйте пользовательский ввод через конкатенацию строк или f-строки.

Управление доступом: GRANT и REVOKE

Вторая линия защиты — принцип минимальных привилегий. Приложению не нужен суперпользователь базы данных:

REVOKE отзывает права. В PostgreSQL также доступна Row-Level Security (RLS) — ограничение видимости строк в зависимости от роли: каждый менеджер видит только своих клиентов.

Современный SQL: JSON, диалекты и стандарт SQL:2023

SQL — не замороженный язык из 80-х. Стандарт активно развивается, и последняя версия SQL:2023 (опубликована в июне 2023) принесла два крупных нововведения:

• SQL/JSON — стандартизированные функции для работы с JSON прямо в SQL-запросах. PostgreSQL поддерживает JSONB с 2014 года, а теперь аналогичные возможности появляются и в других СУБД
• SQL/PGQ (Property Graph Queries) — графовые запросы внутри SQL. Можно искать пути и паттерны в связанных данных без отдельной графовой базы

На практике каждая СУБД имеет свой диалект:

• PostgreSQL — PL/pgSQL, JSONB, массивы, расширения (PostGIS, pg_trgm). Ближе всего к стандарту
• MySQL — оконные функции появились поздно — только в версии 8.0 (2018), LIMIT вместо FETCH FIRST
• T-SQL (Microsoft SQL Server) — TOP вместо LIMIT, IDENTITY вместо SERIAL, мощные CTE
• PL/SQL (Oracle) — ROWNUM, CONNECT BY для иерархий, пакеты (packages)
• Cloud SQL — BigQuery, Redshift, Snowflake имеют свои расширения, но базовый SQL везде одинаков

Хорошая новость: базовый синтаксис (SELECT, JOIN, GROUP BY, оконные функции) одинаков во всех диалектах. Освоив стандартный SQL на PostgreSQL, вы легко перейдёте на любую другую СУБД.

PostgreSQL и MySQL

PostgreSQL

PostgreSQL — самая популярная реляционная СУБД для новых проектов. Полная поддержка SQL-стандарта, JSONB для полуструктурированных данных, расширения (PostGIS для геоданных, pg_trgm для нечёткого поиска), продвинутая система типов и отличная производительность.

15 самых полезных команд PostgreSQL — от размера базы до профилирования запросов — в нашей подборке. А для оптимизации больших таблиц — разбор индексов PostgreSQL.

MySQL

MySQL — одна из старейших популярных open-source СУБД, движок WordPress и множества legacy-систем. Проще в настройке, но имеет подводные камни: неявное приведение типов, особенности GROUP BY, различия между InnoDB и MyISAM.

Самые частые ошибки — от кодировок до потери данных — в нашей статье о типичных ошибках MySQL.

Выбор СУБД: SQL vs NoSQL

SQLite — для встраиваемых сценариев: мобильные приложения, Electron, edge computing, прототипы (вся база в одном файле). MySQL — проверенный выбор для веб-приложений, на нём работают GitHub и Booking.com. PostgreSQL — универсальный вариант для новых проектов, от стартапов до enterprise. Детальное сравнение с бенчмарками — в нашем обзоре трёх СУБД.

Когда данные неструктурированные или нужна горизонтальная масштабируемость, рассмотрите NoSQL: MongoDB (документы), Redis (ключ-значение), Cassandra (колонки), Neo4j (графы). Подробнее — в статье о моделях баз данных.

SQL на собеседованиях

SQL-вопросы — обязательная часть собеседований для бэкенд-разработчиков, аналитиков и дата-инженеров. Типичный формат: дают схему из 2–3 таблиц и просят написать запрос. Темы: JOIN-ы, GROUP BY, оконные функции, подзапросы, нормализация.

Ключ к успеху — практика на реальных задачах. Интервьюеры оценивают умение декомпозировать задачу, выбрать правильный тип JOIN и грамотно обработать NULL.

27 самых распространённых вопросов с ответами — в нашей подборке. Для практики — 5 заданий с реальных собеседований с разбором решений.

Куда двигаться дальше

SQL — это фундамент, но не потолок. Направления для роста:

1. Администрирование БД — репликация, бэкапы, мониторинг, настройка производительности
2. Дата-инженерия — ETL-пайплайны, dbt, Airflow, data warehouse (BigQuery, Snowflake)
3. Аналитика данных — SQL + Python (pandas), визуализация, A/B-тесты
4. Бэкенд-разработка — ORM (SQLAlchemy, Prisma, GORM), миграции, проектирование схем
5. Data Science — feature engineering, работа с большими датасетами

Главный совет: практикуйтесь на реальных данных. Поднимите PostgreSQL локально, загрузите публичный датасет и решайте задачи. Ресурсы для старта:

• SQLBolt — интерактивные уроки SQL в браузере, от нуля
• PostgreSQL Exercises — задачи на реальной схеме (клуб, бронирования)
• LeetCode / HackerRank — SQL-задачи для подготовки к собеседованиям
• Kaggle Datasets — открытые датасеты для импорта в PostgreSQL и экспериментов

Автор блога Database Doctor провёл серию бенчмарков на DuckDB и PostgreSQL (подробнее о нём — в нашем гайде по PostgreSQL), сравнив классическую размерную модель (dimensional model) с подходом «One Big Table». Результаты оказались неожиданными для многих — JOIN не просто «не дорогой», он зачастую быстрее плоской таблицы.

— JOIN в колоночных СУБД (DuckDB) обходится дешевле, чем сканирование широкой OBT-таблицы, уже начиная с 4–6 колонок

— Стоимость сканирования OBT растёт нелинейно (примерно O(n log n)) с увеличением числа колонок

— В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев

— Ральф Кимбалл описал эти закономерности ещё в 1996 году в своей классической книге о размерном моделировании

— Даже при «бесконечном I/O» денормализация не экономит CPU — она его тратит

Постановка эксперимента

Рассмотрим два конкурирующих подхода к моделированию данных:

• Размерная модель (dimensional model) — атрибуты продуктов хранятся в отдельной таблице product, и мы делаем JOIN с таблицей sales каждый раз при чтении
• One Big Table (OBT) — все атрибуты продуктов заранее «вклеены» в таблицу sales_obt, и мы читаем данные через SELECT без JOIN

Очевидно, что вторую таблицу дороже строить в ETL-пайплайне. Но какая из них потребляет меньше CPU при чтении?

Размерная модель

Схема данных:

Здесь c01 ... c20 — строковые колонки с атрибутами продуктов. Кардинальности:

• product — 100 000 строк; каждая из колонок c01–c20 содержит ~100 уникальных значений (MD5-хеши)
• sales — 1 миллиард строк со случайным v и равномерно распределённым id_product

Эта модель, где сущность (product) хранится отдельно от фактов (sales), называется размерной моделью (dimensional model). Подробнее о ней — в конце статьи.

Генерация тестовых данных

Сначала создаём seed-таблицу — универсальный способ генерации последовательности чисел, который работает практически на всех SQL-платформах:

Примечание: да, можно было бы использовать INSERT ... VALUES с несколькими кортежами, но не каждая аналитическая БД поддерживает этот синтаксис. Зато UNION ALL работает, кажется, вообще везде.

С помощью seed-таблицы генерируем миллиард строк для sales:

Таблицу product заполняем MD5-хешами для получения строковых значений с контролируемой кардинальностью:

Примечание: да, можно было бы взять ровно 100 различных значений вместо ~101 для c01–c20, но с приведённым выше кодом проще.

Модель «One Big Table»

На другой стороне ринга — заранее объединённая широкая таблица:

Гипотеза: JOIN медленнее, чем плоская таблица

Итак, вопрос: что быстрее?

Размерная модель с JOIN:

Или OBT без JOIN:

Если «JOIN — это дорого», то размерная модель должна быть медленнее. Мы также должны увидеть более высокое потребление CPU.

Чтобы быть максимально нечестным по отношению к размерной модели, автор запускает тесты на системе, где вся база помещается в оперативную память. Так мы моделируем «бесконечный I/O» и не платим за дисковые операции.

Результаты DuckDB

Тестовая машина: ноутбук с 14 ядрами, 32 ГБ RAM, SSD на 3 ГБ/с. Размер базы — 45 ГБ, из которых sales_obt занимает ~40 ГБ. DuckDB отлично утилизирует ядра: CPU загружен на 100% во время выполнения запросов.

Для тестов автор использовал серию запросов с нарастающим числом колонок:

Примечание: DuckDB использует написание EXPLAIN ANALYZE (а не ANALYSE). В оригинале автор шутит, что DuckDB «правильно» использует британское написание — но на самом деле в DuckDB работает американский вариант.

Базовый замер (measurement 0) — просто чтение v: мы платим за JOIN, но не запрашиваем колонки из product. Читатели, которых интересует эта крайняя ситуация и способы оптимизации, могут изучить тему join elimination в планировщиках запросов. Каждый запрос выполняется трижды, берётся лучшее время.

Время выполнения (wall clock)

Выводы из графика:

• При запросе 1–2 колонок OBT незначительно быстрее
• С ростом числа колонок стоимость OBT взлетает — до 15 секунд при 20 колонках
• JOIN остаётся практически константным по времени (~1 секунда) независимо от числа колонок
• Рост OBT напоминает O(n log n) — нелинейная зависимость

Потребление CPU

DuckDB позволяет замерить CPU-время по каждому оператору в запросе:

Та же закономерность: OBT при 20 колонках потребляет ~200 секунд CPU, тогда как размерная модель — всего ~15 секунд (scan + join). Разница — на порядок.

Почему JOIN быстрее при масштабировании?

Казалось бы, мы читаем каждую строку. Почему не быстрее просто отдать её из плоской таблицы?

Ответ кроется в том, как работают колоночные хранилища (DuckDB, Parquet и другие):

1. Декомпрессия колонок. Сжатые строки хранятся в словаре (dictionary encoding). Чтобы получить данные, движок «соединяет» указатели в сегментах сжатия со словарём. Это по сути тоже своего рода JOIN — но уже внутри Storage Engine. В размерной модели строки уже «материализованы» в таблице product, и эта «декомпрессия» фактически заранее выполнена
2. Сборка строк из колонок. В колоночном формате данные каждой колонки хранятся отдельно. Чтобы собрать строку, нужно пройти по метаданным, найти местоположение каждой колонки и скопировать данные в финальный результат. Каждая колонка — это отдельная аллокация (и деаллокация) памяти. Именно этот механизм, вероятно, и даёт нелинейный рост стоимости сканирования широкой OBT-таблицы

А что насчёт строковых хранилищ?

Не все базы данных используют колоночное сжатие. Строковые хранилища (row stores) хранят данные в формате строк (аналогично AVRO в мире Data Lake).

У строковых хранилищ есть интересное свойство: им не нужно «собирать» строку из отдельных колонок — строка уже хранится целиком. Правда, они занимают больше места на диске и хуже работают при чтении отдельных колонок.

Вопрос: может быть, для OBT лучше использовать строковое хранилище? Давайте проверим.

Гипотеза автора

В пользу OBT в строковом хранилище:

• Данные можно отдать напрямую, без «сборки» строк из колонок
• Не нужна «неявная декомпрессия» сжатых строк
• JOIN на строковых форматах медленнее, чем на колоночных — нельзя векторизовать хеширование

В пользу JOIN:

• Если нужна часть колонок, проекция (отбрасывание ненужных) стоит CPU — это неявный memcpy
• Больший объём данных при сканировании — больше работы с буферами
• У JOIN лучше кеш-локальность для строк — меньше TLB-промахов

Интуиция автора подсказывает, что строковые хранилища могут сдвинуть «точку пересечения» дальше от одной колонки и дать больше преимуществ OBT — хотя бы потому, что не нужна «сборка» строки. Давайте проверим.

Тест на PostgreSQL 17

Для теста автор выбрал PostgreSQL 17 — классическое строковое хранилище. Датасет уменьшен до 1% (10 млн строк в sales, 10 000 строк в product), но и так sales_obt занимает 7 ГБ.

Чтобы убрать стоимость сериализации результата для клиента, вместо SELECT * используется:

Примечание: PostgreSQL сериализует результат в клиентский формат даже при EXPLAIN ANALYZE. Это дополнительная работа, которой лишены системы, использующие Arrow-буферы, — там промежуточная сериализация не нужна.

Чтобы убедиться, что PostgreSQL не «хитрит» с NULL-проверкой в COUNT, автор проверил план выполнения. Видно, что агрегат действительно работает со строкой, ширина которой пропорциональна числу входных колонок:

Выводы:

• Как и предполагалось, стоимость «проекции» (отбрасывания ненужных колонок) доминирует при малом числе колонок — OBT проигрывает
• Вопреки ожиданиям, даже в базовом случае (0 колонок из JOIN) размерная модель оказывается быстрее
• Красивая линейная зависимость: строковое хранилище масштабируется предсказуемо в обоих случаях
• JOIN выигрывает или проигрывает OBT с минимальной разницей — но тренд в пользу JOIN

Глубокое погружение: что именно тормозит PostgreSQL?

С помощью EXPLAIN (ANALYZE, BUFFERS) автор убедился, что запрос работает полностью в памяти:

shared hit=909120 означает, что все буферы были прочитаны из памяти (shared buffers), без обращения к диску. PostgreSQL форкает процесс на каждое соединение, поэтому профилировать конкретный запрос можно через SELECT pg_backend_pid().

Автор использовал Windows Performance Recorder для профилирования PostgreSQL на 16-колоночном запросе:

Два самых горячих вызова:

1. tts_buffer_heap_getsomeattrs (файл execTuples.c) — по сути, неоптимальный memcpy. Эта функция копирует данные из буферного пула в представление кортежа. Именно та «проекция», которую автор предсказывал — но реализованная неэффективно
2. ExecInterpExpr (файл execExprInterp.c) — интерпретатор выражений. Современные БД используют векторизованное или компилированное выполнение; PostgreSQL по умолчанию интерпретирует через гигантский switch-блок (JIT-компиляция через LLVM доступна с PG 11, но не используется на дефолтных настройках для дешёвых запросов). Основной вызывающий — ExecAgg: подсчёт COUNT обходится почти так же дорого, как само чтение данных

Важная оговорка: PostgreSQL — не идеальный представитель строковых хранилищ. Базы данных с компилируемыми запросами могут быть значительно быстрее при «сыром сканировании». Тем не менее, строковые хранилища, похоже, почти всегда выигрывают от использования JOIN — если только вы не планируете выбирать практически все колонки из OBT в каждом запросе. Даже денормализация одной колонки ради экономии CPU может оказаться ошибочной.

Как автор собирал PostgreSQL с отладочными символами

Для профилирования PostgreSQL нужны debug-символы. Ни пакет Chocolatey, ни установщик EnterpriseDB их не включают — пришлось собирать из исходников на Windows.

Необходимые пакеты:

Файл msvc.ini в корне репозитория PostgreSQL:

Сборка:

Размерная модель: уроки прошлого

Всё, что мы наблюдаем, не ново. Ещё в 1996 году Ральф Кимбалл опубликовал книгу «The Data Warehouse Toolkit», которая до сих пор переиздаётся и считается классикой.

Кимбалл аргументировал:

• Большие аналитические таблицы (факты) должны содержать только метрики (то, что агрегируется) и целочисленные ключи измерений (то, по чему делается JOIN)
• Все атрибуты сущностей хранятся в отдельных таблицах измерений (dimension tables), к которым присоединяются через foreign key
• Колонки с высокой кардинальностью и единственным значением лучше хранить прямо в таблице фактов — «вырожденные измерения» (degenerate dimensions). Это идеально соответствует нашему наблюдению: чтение одной колонки через JOIN действительно немного медленнее

Кимбалл также рекомендовал объединять связанные таблицы внутри самого измерения (делая таблицу измерения шире) — но только для измерений, не для фактов. И делал он это не ради производительности, а для упрощения работы оптимизатора запросов.

Итоги

Главный вывод:

«JOIN — НЕ дорогая операция по сравнению с альтернативами»

Что мы выяснили:

• Даже при чтении всех строк JOIN зачастую дешевле, чем сканирование One Big Table
• В колоночных хранилищах (DuckDB) преимущество JOIN проявляется начиная с 4–6 колонок и растёт нелинейно
• В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев
• «Жертвовать диском ради экономии CPU на JOIN» — это миф, который противоречит измерениям
• Размерное моделирование (Кимбалл, 1996) — не устаревшая методология, а эффективный инженерный подход

Важно помнить: мы тестировали JOIN большой таблицы (1 млрд строк) с маленькой (100 000 строк). Что произойдёт при JOIN двух больших таблиц — вопрос для отдельного исследования.

В следующей статье автор обещает разобрать, что происходит с производительностью при добавлении фильтров. Спойлер: разрыв между OBT и JOIN становится ещё больше в пользу JOIN — благодаря bloom-фильтрам и pushdown-оптимизациям.

Перевод и адаптация статьи «Joins are NOT Expensive!» из блога Database Doctor. Если вы хотите глубже разобраться в SQL — рекомендуем нашу шпаргалку по SQL.

SQL (Structured Query Language) — это декларативный язык запросов для управления реляционными базами данных. С его помощью можно создавать таблицы, добавлять, изменять и удалять данные, а также делать выборки по заданным условиям. SQL стандартизирован организацией ISO и поддерживается всеми основными СУБД: PostgreSQL, MySQL, SQLite, Microsoft SQL Server и Oracle.

- SQL расшифровывается как Structured Query Language — язык структурированных запросов.

- Язык создан в 1973 году в IBM, стандарт ISO принят в 1987 году.

- SQL используют 51,5% профессиональных разработчиков по всему миру (Stack Overflow, 2023).

- Основные операции: SELECT, INSERT, UPDATE, DELETE — охватывают 90% повседневных задач.

- SQL работает с реляционными базами данных, где данные хранятся в связанных таблицах.

- Один SQL-запрос может обработать миллионы строк за доли секунды.

Зачем нужен SQL — где используется и кому пригодится

SQL нужен везде, где есть структурированные данные. Вот лишь несколько примеров из реальной практики:

• Веб-разработка — интернет-магазины, блоги, социальные сети хранят пользователей, товары и записи в реляционных БД.
• Аналитика данных — аналитики используют SQL для агрегации, фильтрации и построения отчётов.
• Backend-разработка — серверные приложения взаимодействуют с PostgreSQL или MySQL через SQL-запросы.
• Data Science — учёные по данным выгружают датасеты из хранилищ (Redshift, BigQuery) с помощью SQL.
• DevOps и администрирование — DBA оптимизируют запросы, настраивают индексы, следят за производительностью.

SQL востребован как у начинающих разработчиков, так и у опытных инженеров. По данным Glassdoor, знание SQL входит в топ-3 навыков для вакансий Data Analyst и Backend Developer в 2024 году. Даже фронтендеры, которые редко работают напрямую с БД, рано или поздно сталкиваются с SQL при отладке или настройке.

Основные команды SQL

Все команды SQL делятся на группы. Самые важные — это DDL (Data Definition Language) для создания структур и DML (Data Manipulation Language) для работы с данными. Рассмотрим ключевые команды подробнее.

SELECT — выборка данных

SELECT — самая используемая команда SQL. Она позволяет извлекать данные из одной или нескольких таблиц. Базовый синтаксис:

Звёздочка * означает «все столбцы», но на практике лучше перечислять нужные явно — это ускоряет запрос и делает код читаемым. Чтобы отфильтровать дубликаты, используют SELECT DISTINCT.

Можно также ограничить количество строк в результате:

INSERT, UPDATE, DELETE — изменение данных

Три команды, отвечающие за создание, изменение и удаление записей:

Важно: Всегда используйте WHERE в командах UPDATE и DELETE. Без условия изменения применятся ко всем строкам таблицы, и восстановить данные без бэкапа не получится.

CREATE TABLE — создание таблиц

Прежде чем работать с данными, нужно создать таблицу. Команда CREATE TABLE задаёт структуру: имена столбцов, их типы и ограничения:

SERIAL (или AUTO_INCREMENT в MySQL) автоматически генерирует уникальный числовой идентификатор. PRIMARY KEY — уникальный ключ строки. REFERENCES создаёт внешний ключ — связь между таблицами.

JOIN — объединение таблиц

Реляционные базы данных хранят информацию в нескольких связанных таблицах. Чтобы получить данные из нескольких таблиц одним запросом, используется JOIN. Существует несколько видов объединений:

• INNER JOIN — только совпадающие строки из обеих таблиц.
• LEFT JOIN — все строки из левой таблицы, совпадения из правой (или NULL).
• RIGHT JOIN — все строки из правой таблицы, совпадения из левой (или NULL).
• FULL OUTER JOIN — все строки из обеих таблиц, NULL там, где нет совпадений.

WHERE, ORDER BY, GROUP BY — фильтрация и сортировка

Три важнейших инструмента для управления результатом выборки. Подробный разбор ORDER BY с примерами читайте в нашем гайде по сортировке в SQL.

Ключевое отличие: WHERE фильтрует строки до группировки, HAVING — после. Агрегатные функции (COUNT, SUM, AVG, MIN, MAX) работают с группами строк.

Типы данных в SQL

При создании таблицы каждому столбцу нужно указать тип данных. Правильный выбор типа экономит место на диске и ускоряет запросы. Основные типы:

• Числовые: INT / INTEGER — целые числа; BIGINT — большие целые; DECIMAL(p,s) — дробные с фиксированной точностью; FLOAT — числа с плавающей запятой.
• Строковые: VARCHAR(n) — строка до n символов; TEXT — строка без ограничений; CHAR(n) — строка фиксированной длины.
• Дата и время: DATE — дата (YYYY-MM-DD); TIME — время; TIMESTAMP — дата и время; INTERVAL — интервал.
• Логический: BOOLEAN — значения TRUE / FALSE / NULL.
• Специальные: UUID — уникальный идентификатор; JSON / JSONB — JSON-данные (PostgreSQL); ARRAY — массив значений.

Практическое правило: используйте наименьший подходящий тип. Для возраста достаточно SMALLINT, для идентификатора пользователя — INT, для финансовых сумм — DECIMAL, а не FLOAT (чтобы избежать ошибок округления).

SQL vs NoSQL — когда что использовать

SQL-базы данных хранят данные в таблицах с фиксированной схемой. NoSQL-базы (MongoDB, Redis, Cassandra) используют другие модели: документы, ключ-значение, графы, колонки. Вот когда выбирать каждый подход:

• SQL подходит, когда: данные структурированы и схема стабильна; важна целостность и транзакции (банки, интернет-магазины); нужны сложные запросы с JOIN и агрегацией; команда умеет работать с реляционными БД.
• NoSQL подходит, когда: структура данных гибкая или меняется часто; нужна горизонтальная масштабируемость под огромные объёмы; данные неструктурированы (логи, события, JSON); требуется сверхнизкая латентность (кэш в Redis).

SQL и NoSQL — не конкуренты, а инструменты для разных задач. В одном проекте вполне можно использовать PostgreSQL для бизнес-данных и Redis для кэша.

Популярные СУБД: PostgreSQL, MySQL, SQLite, MS SQL

SQL-синтаксис стандартизирован, но каждая СУБД добавляет свои расширения. Вот краткое сравнение четырёх самых популярных:

• PostgreSQL — мощная open-source СУБД с богатым набором типов данных, поддержкой JSON, полнотекстового поиска и оконных функций. Лучший выбор для серьёзных проектов. Подробнее читайте в нашем руководстве по PostgreSQL для начинающих.
• MySQL / MariaDB — самая распространённая СУБД для веб-приложений, особенно в связке с PHP (WordPress, Drupal). Простая в настройке, быстрая для чтения.
• SQLite — встроенная база данных в одном файле, без сервера. Идеально подходит для мобильных приложений, тестирования и небольших проектов. Используется в Android, iOS, браузерах.
• Microsoft SQL Server — корпоративная СУБД от Microsoft, тесно интегрированная с экосистемой .NET и Azure. Популярна в крупных компаниях.

Если вы только начинаете, рекомендуем PostgreSQL или SQLite. PostgreSQL — для полноценной разработки, SQLite — для обучения без установки сервера.

Как начать учить SQL — ресурсы, песочницы, советы

SQL — один из самых практичных языков для изучения. Базовые команды можно освоить за неделю, а первые реальные запросы писать уже через несколько часов практики.

Подробную дорожную карту с последовательностью тем и рекомендуемыми ресурсами смотрите в нашей дорожной карте SQL для начинающих.

• SQLiteOnline.com — онлайн-песочница без регистрации. Запустите первый запрос прямо в браузере за 30 секунд.
• SQLBolt.com — интерактивный курс с упражнениями от SELECT до сложных JOIN. Полностью бесплатный, на английском.
• Stepik.org — бесплатный курс «Введение в базы данных» на русском языке с практическими заданиями.
• LeetCode / HackerRank — задачи на SQL для подготовки к техническим собеседованиям.
• Официальная документация PostgreSQL — самый полный и точный источник по возможностям СУБД.

Советы для эффективного обучения: практикуйтесь на реальных данных (импортируйте CSV-файл в SQLite), сразу изучайте индексы — они кардинально влияют на производительность. Читайте наш материал об SQL-индексах за 10 минут и 10 советов по оптимизации запросов.

Выводы

SQL — фундаментальный навык для любого, кто работает с данными. За полвека существования язык не только не устарел, но и стал ещё более востребованным: облачные хранилища BigQuery и Redshift, аналитические инструменты, современные ORM — всё это работает поверх SQL или совместимо с ним.

Что делать дальше:

1. Установите PostgreSQL или откройте SQLiteOnline.com и напишите первый SELECT.
2. Пройдите интерактивный курс на SQLBolt.com — займёт 3–5 часов.
3. Попрактикуйтесь на реальных данных: загрузите любой CSV-датасет с Kaggle.
4. Изучите индексы — это самый быстрый способ ускорить запросы.
5. Посмотрите нашу дорожную карту SQL и двигайтесь по ней системно.

SQL знают и продолжают учить потому, что он действительно работает. Сотни миллионов строк в банках, маркетплейсах и SaaS-сервисах каждый день обрабатываются именно с помощью SQL-запросов. Это инвестиция в навык, который окупится независимо от выбранного стека.

В Go для этого есть Bleve — файловая библиотека полнотекстового индексирования. Она умеет индексировать любые Go-структуры с разумными настройками по умолчанию, поддерживает встроенный язык запросов в стиле Google, работает с миллионами записей и не требует отдельного сервера.

В этой статье — практический гайд: от простого индекса до кастомных анализаторов, мультиязычного поиска, пагинации курсором и тонкой настройки производительности.

Ключевые выводы

- Bleve — встраиваемый полнотекстовый движок для Go: не нужен отдельный сервер, достаточно одной зависимости
- Кастомные маппинги позволяют настроить анализатор, стемминг и стоп-слова для каждого поля отдельно
- IndexAlias объединяет несколько индексов (например, по языкам) в один виртуальный — с единым интерфейсом поиска
- Курсорная пагинация через SearchAfter / SearchBefore работает стабильно даже при обновлении индекса между запросами
- Scorch-настройки (воркеры, размер сегментов, порог мёржа) критичны для производительности под нагрузкой

Создаём простой индекс

Начнём с минимального примера. Два базовых действия — индексирование (сохранение документа для последующего поиска) и запрос (извлечение документов, отсортированных по релевантности).

Несколько важных деталей:

• bleve.New vs bleve.Open — New создаёт новый индекс по указанному пути, Open открывает существующий. Паттерн из примера (сначала New, при ошибке — Open) — идиоматический способ обработки первого и повторных запусков.
• NewIndexMapping() — возвращает маппинг по умолчанию: текстовые поля токенизируются, приводятся к нижнему регистру и фильтруются через список стоп-слов английского языка.
• Автоматическое обнаружение полей — Bleve использует рефлексию для анализа структуры. Все экспортируемые поля автоматически токенизируются и становятся доступными для поиска.
• Уникальные ID документов — строковый идентификатор, передаваемый в Index, используется для обновлений и удалений. Повторный вызов Index с тем же ID заменяет документ.
• SearchRequest.Fields — по умолчанию Bleve возвращает только ID и релевантность. Укажите имена нужных полей или []string{"*"}, чтобы получить все.
• hit.Score — каждый результат содержит числовой показатель релевантности на основе BM25. Чем выше — тем точнее совпадение.

Кастомные маппинги полей

Маппинг по умолчанию подходит для быстрого старта, но в реальных проектах нужен контроль над тем, как Bleve анализирует и хранит каждое поле. Маппинг определяет тип поля, анализатор для токенизации, необходимость хранения оригинального значения и включение в индекс.

Маппинги позволяют:

• Управлять токенизацией — разбивать текст на термы по пробелам, языковым правилам, edge n-граммам и другим стратегиям
• Фильтровать входные данные — приводить к нижнему регистру, удалять HTML, применять стоп-слова и стемминг (чтобы «running» и «runs» находились по запросу «run»)
• Исключать поля из индекса — пропускать чувствительные или нерелевантные данные для экономии дискового пространства
• Создавать кастомные анализаторы — комбинировать любой токенизатор с произвольной цепочкой фильтров

Пример ниже применяет стемминг английского языка к полям Text и Title, а поле с сырым HTML исключает из индексирования:

Результат buildIndexMapping() передаётся в bleve.New или bleve.NewUsing при создании индекса. Маппинги закрепляются за индексом на этапе создания и не могут быть изменены позже. Чтобы применить новый маппинг, нужно создать свежий индекс и переиндексировать все документы.

Мультиязычный поиск

Bleve умеет прозрачно работать с несколькими индексами одновременно через IndexAlias. Алиас — это виртуальный индекс, который отправляет запрос во все реальные индексы и объединяет результаты в единый ранжированный список.

Это особенно полезно, когда у каждого языка свой индекс с собственным анализатором (английский стемминг, французские стоп-слова, кастомная токенизация), а искать нужно по всем сразу:

Алиасы также упрощают горячую замену (hot-swap). Когда нужно перестроить индекс (например, применить новый маппинг), можно собрать новый индекс в фоне, а затем атомарно подменить его вызовом alias.Swap(newIndexes, oldIndexes). Текущие запросы завершатся на старом индексе, новые сразу пойдут на свежий — без даунтайма.

Пагинация с курсором

У SearchRequest в Bleve есть поле From для офсетной пагинации: 0 для первой страницы, 20 для второй и так далее. Это работает, но имеет серьёзную проблему: Bleve вынужден оценивать и сортировать все совпавшие документы вплоть до From + Size на каждый запрос. Глубокие страницы становятся всё дороже по памяти и CPU.

Хуже того, если между двумя запросами в индекс были добавлены новые документы, смещение сдвигается — и пользователь видит дубликаты или пропуски.

Правильный подход — курсорная пагинация через SearchAfter и SearchBefore. Эти методы продолжают выдачу с известной позиции, а не пересканируют результаты с начала:

На что обратить внимание:

• Стабильная сортировка обязательна. SearchAfter использует ключ сортировки последнего результата в качестве курсора. Если ключ нестабилен, курсор станет невалидным.
• Sort — всегда []string. Даже при сортировке по числовому полю Bleve сериализует ключ в строку. Читайте курсор из hit.Sort и передавайте напрямую в SetSearchAfter.
• SearchBefore работает аналогично, но в обратном направлении — полезно для кнопки «предыдущая страница».

Оптимизация производительности

Настройки производительности Bleve не слишком хорошо документированы, но существенно влияют на работу под нагрузкой. Конфигурация передаётся как map[string]any в NewUsing или OpenUsing вместо обычных New / Open.

Эти параметры относятся к Scorch — дефолтному бэкенду хранения Bleve. Полный список доступных опций и значений по умолчанию можно найти в исходном коде персистера.

Пакетная индексация

Если нужно проиндексировать большой объём данных, используйте Batch вместо одиночных вызовов Index. Пакетная запись группирует операции в одну транзакцию, что значительно снижает нагрузку на диск:

Оптимальный размер пакета зависит от объёма документов и доступной памяти. Как правило, пакеты по 100-1000 документов дают хороший баланс между скоростью и потреблением ресурсов.

Выводы

Bleve — одна из недооценённых жемчужин экосистемы Go. Библиотека позволяет добавить полнотекстовый поиск в приложение без сложной инфраструктуры. Настройки по умолчанию дают рабочий результат за минуты, а кастомные маппинги, композитные запросы и тонкая настройка Scorch — инструменты для решения специфических задач оптимально.

Официальная документация местами неполна, но issues на GitHub и реальные open-source-проекты отлично её дополняют. Рабочий пример всех описанных концепций можно найти в пакете indexer проекта Hister.

Адаптированный перевод статьи Data Indexing in Golang из блога Hister.

Судя по всему, это те самые приложения, которые были собраны на скорую руку с помощью ИИ. В базе уже 167 приложений. Проект опубликован на платформе Firehound и активно обсуждается в сообществе iOS-разработчиков на Reddit.

Что именно нашли

Firehound сканирует iOS-приложения и ищет публично доступные базы данных и файлы — без взлома, логинов и обхода защиты. Речь идет о классической ошибке конфигурации: бэкенд приложения открыт для всех желающих.

В реестре уже есть приложения с:

• десятками миллионов записей в открытых базах;
• доступными коллекциями profiles, posts, comments, likes;
• утекшими email-адресами, никнеймами, метаданными активности.

Один из лидеров антирейтинга — приложение Adult Coloring Book – Pigment. У него более 7,7 млн документов оказались доступны без какой-либо аутентификации.

Причем тут вайб-кодинг

По словам автора проекта, большинство уязвимостей выглядят одинаково: разработчики используют ИИ для генерации кода и инфраструктуры, но не понимают, что именно деплоят в прод.

Типичный сценарий:

• ИИ предлагает использовать Firebase, Supabase или MongoDB.
• Конфигурация безопасности либо отсутствует, либо остается дефолтной.
• Ключи и переменные окружения попадают в клиентский код.
• База становится публичной — иногда буквально в один клик.

Как подчеркивают участники обсуждения на Reddit, проблема не в ИИ как таковом, а в том, что вайб-кодинг часто заканчивается полным отсутствием базовой гигиены кибербезопасности.

Это не взлом — и в этом главная проблема

Важно: Firehound не эксплуатирует уязвимости. Он лишь показывает то, что уже открыто. Данные в публичной версии интерфейса частично замаскированы, но сам факт доступности никто не отрицает.

Именно это делает ситуацию неприятной: формально никто ничего не «ломал», но пользовательские данные все равно утекли.

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

1. Платформа Tantor

Платформа Tantor позволяет осуществлять управление, администрирование и мониторинг множества корпоративных баз данных на PostgreSQL и любых его форках (Tantor Postgres, PostgresPro, Pangolin и других). Объединяет в одном интерфейсе инструменты для конфигурирования, обслуживания, профилирования запросов и работы с кластерами Patroni. Все функции доступны из браузера без установки дополнительного ПО на рабочее место администратора. Продвинутая система алертов (оповещений) в платформе Tantor автоматически отслеживает метрики и уведомляет администраторов о потенциальных проблемах, позволяя максимально быстро на них реагировать.

Для кого это работает

• DBA используют платформу как центр управления всеми PostgreSQL-инстансами: мониторят нагрузку, блокировки и репликацию, настраивают параметры через группы конфигураций, планируют регламентные работы.
• SRE и дежурные инженеры следят за дашбордами по доступности кластеров, работают с алертами на превышение порогов по времени ответа или лагу репликации. При инцидентах используют алерты и алгоритмический ассистент для расшифровки ошибок и базовой диагностики.​
• Разработчики заходят эпизодически — посмотреть профиль нагрузки своих сервисов, разобрать планы выполнения проблемных запросов или получить SQL-выборку по описанию на естественном языке через алгоритмический ассистент.​
• Команды безопасности настраивают маскирование конфиденциальных данных для тестовых контуров и проверяют аудит действий пользователей.

Алерты (оповещения)

• Непрерывный мониторинг: агенты платформы постоянно собирают метрики (например, загрузку процессора, состояние процессов БД) и анализируют эти данные на предмет аномалий. Можно редактировать условия срабатывания. Например, система может автоматически создать алерт, если загрузка процессора сервера БД долгое время превышает 80%, а при сбое в отказоустойчивом Patroni-кластере алерт мгновенно уведомит администратора о необходимости вмешательства. Также если запланированная задача (например, резервное копирование) не выполнилась или завершилась с ошибкой, в интерфейсе появится соответствующее уведомление.
• Классификация по критичности: алерты имеют цветовую индикацию: красный — высокая критичность, желтый — предупреждение. Все алерты отображаются в едином интерфейсе (меню «колокольчик»), где их можно фильтровать, сортировать и просматривать детали.
• Внешние уведомления: интеграции позволяют направлять алерты в Telegram, электронную почту, Mattermost. Алерты разного уровня критичности можно направлять в разные каналы.
• Анализ и история: для каждого алерта доступны детали (метрики, хост), связанные события и полный журнал изменений (Events Log).

Управление Patroni-кластерами

Платформа визуализирует топологию кластера: кто лидер, кто реплика, какой lag, статус health. Плановый switchover выполняется из интерфейса без ручных команд. Если одна из реплик отстаёт или упала, система фиксирует это на дашборде и отправляет алерт.

Профилирование и оптимизация запросов

Query Profiler на базе pg_stat_statements собирает статистику по запросам на выбранном промежутке времени. Группирует их, показывает время выполнения, количество вызовов, детализацию по каждому.

Для «тяжелых» запросов формирует визуализацию планов и рекомендации по оптимизации — добавить индекс, переписать join, изменить параметры планировщика.

Конфигурирование СУБД под разные профили нагрузки

Платформа Tantor позволяет из одной точки управлять конфигурациями кластеров и инстансов. Кроме этого, у пользователя есть возможность создать типовые профили нагрузки, например 1С или BI-платформу, автоматизированную банковскую систему или иные ресурсоемкие бизнес-приложения. Это позволяет более тонко управлять имеющимися ресурсами хранения данных и их вычисления за счет возможности сконфигурировать сразу большую группу инстансов одной конфигурацией с помощью групповых параметров.

Анонимизация данных

Модуль на основе pg_anon ищет конфиденциальную информацию в таблицах и создаёт анонимизированные дампы. Настраиваются правила маскирования для конкретных полей, после чего формируется выгрузка или копия базы для передачи разработчикам. Данные остаются репрезентативными по объёму и структуре, но без реальных значений.

Планировщик и автоматизация

Создание задач для выполнения SQL-скриптов или команд ОС по расписанию или с указанием периодичности. Подходит для регламентных работ — vacuum, analyze, проверка bloat, архивирование логов. История выполнения и результаты сохраняются в интерфейсе.​

Лог-аналитика

Платформа собирает и хранит логи СУБД с возможностью поиска по тексту, пользователям, объектам БД и кодам ошибок. При разборе инцидентов это позволяет связать проблемы на уровне приложения с реальными событиями в базе без grep по десяткам файлов.

Алгоритмический ассистент

Взаимодействует с метаданными БД, логами, оптимизатором запросов и метриками. Выполняет семантический поиск, классифицирует данные, генерирует SQL по текстовому описанию, предлагает оптимизации и помогает интерпретировать планы выполнения.

Технические детали

• Веб-интерфейс, доступный из браузера на любой ОС.
• Развёртывание on-premise через docker-compose на Linux (включая Astra Linux).
• Поддержка всех версий PostgreSQL и коммерческих форков.
• REST API для экспорта метрик и выборок данных.
• Интеграция с SIEM через syslog, с мессенджерами (Telegram, Mattermost) и почтой.
• Ролевая модель доступа, рабочие пространства, журнал событий.​

Лицензирование

Коммерческая лицензия по количеству серверных ядер обслуживаемых (наблюдаемых ) СУБД. Бесплатная полнофункциональная версия работает до 180 дней. Включена в Единый реестр российского ПО (запись 12905).

Поддержка

Документация полностью на русском языке, есть обучающие материалы на YouTube, Rutube и VK. Компания проводит вендорские курсы и сертификацию через авторизованные учебные центры. Для корпоративных клиентов доступна техподдержка 24/7 с SLA от 2 часов в зависимости от критичности запроса.

2. Platform V Kintsugi

Инструмент для мониторинга и сопровождения СУБД, основанных на PostgreSQL, который позволяет обслуживать тысячи баз данных и выполнять задачи администрирования в едином интерфейсе. Продукт зарегистрирован в Едином реестре российских программ и позиционируется как альтернатива Oracle Enterprise Manager Cloud Control.

Для кого это работает

Platform V Kintsugi также подходит для компаний, которые ищут замену инструментам мониторинга иностранных вендоров. Решение масштабируется от среднего бизнеса с небольшими объёмами баз данных до крупных компаний с высоконагруженными системами — продукт выдерживает промышленные нагрузки Сбера.

Централизованное наблюдение

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

В оперативном центре можно отслеживать события БД практически в режиме реального времени, чтобы контролировать инциденты до их эскалации.

Работа с экземплярами БД

Обзорная панель СУБД проводит постоянный мониторинг экземпляров и отправляет важную информацию о статусе баз данных в одном месте. Функциональность решения ускоряет обслуживание инфраструктуры и автоматизирует повторяющиеся задачи по сопровождению СУБД.

SQL-интерфейс с аудитом

Безопасный терминал для выполнения запросов оснащен функцией аудита действий пользователя, что повышает уровень безопасности при работе с данными. Решение соответствует стандартам защищённости в каждой функциональной части и гарантируют безопасность при работе с критической инфраструктурой.

Анализ производительности

История активности сессий помогает оптимизировать производительность любой PostgreSQL-подобной СУБД без необходимости использования дополнительного программного обеспечения. В интерфейс продукта интегрированы отчёты pg_profile. Решение помогает анализировать и проводить диагностики без влияния на производительность СУБД.

Визуализация и оптимизация запросов

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

Лицензирование

Продукт зарегистрирован в Едином реестре российских программ для ЭВМ и баз данных. Реестровая запись: №18302 от 12.07.2023.

Особенности архитектуры

Инструмент оснащен изменяемой информационной моделью и широким интеграционным слоем. Совместим с 80+ решениями Platform V. Встроена поддержка отечественной СУБД Platform V Pangolin DB для высоконагруженных систем, при этом поддерживается работа с любыми PostgreSQL-like СУБД. Документацию можно изучить здесь.

3. Postgres Pro Enterprise Manager

PPEM — графическая платформа для управления базами данных Postgres Pro через веб-интерфейс. Инструмент обеспечивает мониторинг, диагностику и управление множеством экземпляров Postgres Pro в рамках собственной инфраструктуры.​

Снижение порога входа

Понятная структура интерфейса, визуализация данных и подробная информация о статусе операций снижают порог вхождения в администрирование СУБД. Для выполнения рутинных операций не требуется знать команды SQL. Автоматизация задач, визуализация метрик и планов запросов, интеграция с pgpro_pwr и pg_probackup ускоряют работу и упрощают анализ производительности.​

Централизованный дашборд

На главном дашборде отображается основная информация о базах данных, подключённых к PPEM: общий размер, последние сообщения из журналов, статус выполнения задач. Обеспечивается постоянный контроль в режиме реального времени 24/7.​

Управление экземплярами

Раздел «Экземпляры» показывает список всех подключённых баз данных с основной информацией: версия PostgreSQL, каталог данных, порт, сервер, роль (standalone), количество баз данных, транзакций в секунду, соединений. Доступны базовые действия: остановка, запуск, резервное копирование, настройки. PPEM работает с любой редакцией Postgres Pro.​

Инструмент поддерживает автоматическое обнаружение экземпляров в сети (autodiscovery-режим), что сокращает время подключения новых баз и упрощает масштабирование.​

Мониторинг и диагностика

Для каждого экземпляра доступны графики ключевых метрик производительности, информация по сеансам БД и событиям ожидания, выполняющимся SQL-запросам. Можно просматривать и редактировать параметры экземпляра. Есть возможность добавлять собственные показатели производительности и адаптировать мониторинг под особенности инфраструктуры.​

Работа с базами данных

Список баз данных предоставляет детальную информацию: объём, количество таблиц и индексов, bloat (коэффициент распухания), wraparound (предупреждение о зацикливании счётчика транзакций). Это помогает выявлять узкие места и реагировать до появления проблем.​

Интеграция с pgpro_pwr

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

Управление табличными пространствами

Возможность создания, редактирования и удаления Tablespace. При создании табличного пространства настраиваются параметры: название, каталог, владелец, seq_page_cost, random_page_cost, effective_io_concurrency, maintenance_io_concurrency, compression.​

Резервное копирование и восстановление

Интеграция с pg_probackup позволяет настраивать резервное копирование по расписанию и восстанавливать данные за несколько кликов. В интерфейсе отображается список резервных копий с информацией: ID, размер, начало и окончание выполнения, режим (FULL), хранилище, экземпляр, статус, пользователь, статус валидации, начало и окончание валидации. Можно посмотреть детальный журнал выполнения или вызвать форму восстановления из выбранной резервной копии.​

Планирование и автоматизация

Настройка расписаний для обслуживания базы: вакуум, анализ, реиндексация и другие операции. Все процессы прозрачны — в консоли заданий видны статус, длительность и результат выполнения. Это ускоряет обслуживание инфраструктуры и автоматизирует рутинные повторяющиеся задачи.​

Журнал событий

Графический интерфейс к журналу событий экземпляра БД с возможностями выбора временнóго интервала, фильтрации и текстового поиска. Журнал показывает детали каждого события: дата, время, экземпляр, пользователь, база данных, тип, сообщение.​

Управление доступом

Система ролей и встроенная аутентификация позволяют точно настроить права доступа. Гибкое распределение ролей помогает ограничить доступ к важным данным и избежать случайных ошибок. Все действия — от задач до изменений в конфигурации — фиксируются в истории. Можно интегрировать PPEM с LDAP для централизованной аутентификации.​

Лицензирование

Postgres Pro Enterprise Manager входит в состав всех редакций Postgres Pro и не имеет ограничений на количество ядер процессора или сервера и количества пользователей. Регистрация (№104 в Едином реестре российского ПО).

Особенности развёртывания

PPEM не требует внедрения сторонних решений — всё в одном инструменте, без дополнительных затрат и рисков. Можно развернуть в изолированной среде без доступа в интернет. Интуитивно понятная структура, ролевая модель доступа, встроенная история действий и консоль заданий обеспечивают удобную и безопасную работу с БД.

В результате

Если у вас уже есть коммерческая СУБД одного из российских вендоров, то вы вместе с ней в комплекте скорее всего получили и графическую платформу управления БД. Но если текущая платформа вас не устраивает, то можете выбрать из обзора.

В этой подборке — пять системы управления базами данных, которые закрывают разные сценарии: от транзакционных нагрузок до аналитики петабайтных хранилищ. Каждый продукт решает свой класс задач — одни оптимизированы под OLTP с частыми операциями чтения-записи, другие под OLAP с обработкой миллиардов строк, третьи дают задержки в миллисекунды для real-time систем.

1. РЕД База Данных: реляционная СУБД с режимом встраивания

Тип: реляционная СУБД общего назначения, OLTP

РЕД База Данных — реляционная OLTP-система общего назначения, которая включена в реестр российского ПО и имеет сертификат ФСТЭК России по 4 классу защиты. Команда разрабатывает продукт параллельно с Firebird уже 20 лет: общие ошибки исправляются в обеих ветках, доработки переносятся между проектами.​

Где используют

Один из публичных кейсов — АИС ФССП России. СУБД работает с терабайтными базами данных, скорость обработки запросов сопоставима с другими реляционными OLTP-системами на рынке.

Два режима работы

РЕД База Данных может работать как классическая серверная СУБД или в режиме встраивания — без выделенного сервера, как SQLite. В встраиваемом режиме функциональность сохраняется полностью, кроме сетевого доступа. Это позволяет использовать одну СУБД и для серверных задач, и для локальных приложений.

Поддерживаются Windows, Linux (включая РЕД ОС, Альт Линукс, AstraLinux, ROSA) и Android. Архитектуры: x86_64 (Intel, AMD), Эльбрус (e2k), Байкал (aarch64), ARM.

Отказоустойчивость и репликация

Есть три режима репликации: синхронная, асинхронная и адаптивная. Адаптивная репликация переключается в асинхронный режим при проблемах со связью и возвращается обратно после восстановления. Отказоустойчивый кластер включён в текущую версию, шардинг планируется в версии 6.​

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

Сборка мусора и метаданные

Сборка мусора работает автоматически в разных режимах и не требует блокировки таблицы. Механизм сборки промежуточных версий снимает проблему версионного сервера и длительных транзакций. Метаданные можно обновлять на лету, без блокировки таблицы для запросов.​

Многопоточная архитектура позволяет запускать множество транзакций в рамках одного подключения и поддерживать несколько подключений одновременно.​

Интеграция и инструменты

В экосистеме РЕД Базы Данных есть два основных инструмента:

РБД Эксперт для разработки и администрирования баз данных

РБД Монитор для мониторинга.​

СУБД имеет сертификаты совместимости с 80+ продуктами: медицинские информационные системы, банковское ПО, СКАДА-системы, системы резервного копирования. Полная совместимость с другими продуктами РЕД СОФТ (РЕД Виртуализация, РЕД ОС, РЕД Платформа и другие) позволяет собирать инфраструктуру на базе одного вендора.

Поддерживаются популярные языки и фреймворки: Java (Spring, Hibernate, Liquibase, FlyWay), NodeJS, Python (Django, SQLAlchemy), Ruby (Active Record), GO (GORM), C, C++, .NET, Rust, QT, ODBC, OLE DB, PHP, Erlang.

Доступность и поддержка

Продукт представлен в облаках VK Cloud и Яндекс Облако. Для VK Cloud есть бесплатная версия для тестирования. Покупка через интеграторов, лицензирование поядерное — минимум 2 ядра на установку. Для разработчиков прикладного ПО предусмотрена отдельная лицензия без ограничений.​

Техническая поддержка работает на двух уровнях: стандартном и расширенном. Для пользователей доступны техническая документация и база знаний, статьи на Хабре, каналы на RuTube и Дзен, чат в Telegram с разработчиками. Ежегодно проводится конференция, посвящённая Firebird, где можно пообщаться с командой напрямую.​

Что будет в версии 6

Шестая версия запланирована на 2026 год с фокусом на производительность и новые функции. В релиз войдут: геометрические типы данных, гетерогенные запросы, ROW-тип данных, партиционирование, катастрофоустойчивый кластер, восстановление на точку во времени, создание и удаление индексов без блокировки, улучшенные JSON-функции, новые методы доступа (HASH/MERGE OUTER JOIN, HASH GROUP BY), общий кеш метаданных и поддержка TRUNCATE.

2. Tantor Postgres: СУБД для высоких нагрузок и защищённых систем, в том числе 1С

Тип: универсальная СУБД на базе PostgreSQL

Tantor Postgres — это СУБД для высоконагруженных систем на основе PostgreSQL с глубокими доработками. Продукт выпускается в четырёх редакциях: Special Edition для нагруженных OLTP-систем и корпоративных хранилищ до 100 ТБ, Special Edition 1C с оптимизацией под приложения 1С, Certified с сертификацией ФСТЭК для защищённых ГИС и КИИ, и Basic Edition с базовыми улучшениями и поддержкой вендора.

Где применяют

СУБД Tantor Postgres в различных редакциях, включая сертифицированную ФСТЭК, используется в большинстве ключевых отраслей бизнеса, коммерческих и государственных организациях, в том числе на объектах КИИ. Так, правительство одного из крупнейших городов России использует продукты Tantor в большинстве комитетов, а АО "Губернские аптеки" — крупнейшая аптечная госсеть Красноярского края — мигрировала на Tantor Postgres при объёме данных свыше 2 ТБ и более 17 млн совершаемых транзакций в день. Проект охватил более 2000 рабочих мест. Инструменты мониторинга Tantor помогли выявить неоптимальные запросы и передать данные 1С-разработчикам для доработки, и в результате время массовых расчётов и перепроведения документов в 1С сократилось на 50%, что сэкономило массу времени десяткам бухгалтеров.

Производительность под 1С

Tantor располагает собственным центром экспертизы 1С, который решает технические вопросы клиентов и ставит конкретные задачи по развитию СУБД под специфику 1С. Для крупных внедрений 1С предлагается машина баз данных Tantor XData. С СУБД Tantor Postgres для 1С пройдены тесты на высоконагруженных системах: 30 000 одновременных пользователей 1С с APDEX 0.859 на МБД Tantor XData 2Y, 20 000 одновременных пользователей с APDEX 0.846 на МБД Tantor XData 2B, и 15 000 одновременных пользователей с APDEX 0.950 на МБД Tantor XData 2Y в альтернативном тестировании.

Отличия от PostgreSQL

Полный список отличий от "ванильной" версии доступен в документации.

Среди реализованных в 2025 году технологий и оптимизаций – технология Transparent Data Encryption (TDE) для прозрачного шифрования данных на диске + шифрование WAL, поддержка протокола аутентификации 0Auth 2.0, новый механизм работы с временными таблицами, улучшенная поддержка широких таблиц и таблиц с неравномерным распределением значений, множество оптимизаций производительности для систем «1С», оптимизация обработки дизъюнкций подзапросов, расширенная поддержка параллельного выполнения операций с временными таблицами, раздельное управление детализацией статистики для постоянных и временных таблиц. Таким образом, СУБД Tantor Postgres глубоко оптимизирована для более высокой производительности, в том числе для высоконагруженных систем 1С.

• Расширение Tantor PipelineDB обеспечивает агрегацию и вычисления на данных в реальном времени.
• Расширение columnar предоставляет колоночное хранение и обработку данных с возможностью транзакционного выполнения операций UPDATE и DELETE.
• Расширение transp_anon реализует динамическую анонимизацию данных.

В каждую редакцию СУБД Tantor Postgres входит графическая Платформа Tantor для администрирования и мониторинга баз данных на основе PostgreSQL.

Стратегическим направлением развития СУБД Tantor Postgres является реализация технологии разделения вычислений и хранения для независимого масштабирования под высокие и смешанные нагрузки (НТАР), адаптация к облачному использованию и использованию с ИИ.

Новые расширения в релизах 17.7 и 16.11

• pg_stat_kcache фиксирует физические операции чтения и записи, позволяя выявлять узкие места производительности, недоступные для обнаружения другими инструментами мониторинга.
• pgvector предоставляет тип данных vector и оптимизированные алгоритмы поиска по сходству для работы с многомерными представлениями данных.
• pg_ivm реализует инкрементальные материализованные представления, обновляя их по мере изменения данных в исходных таблицах.
• pg_throttle позволяет ограничивать скорость выполнения отдельных запросов и создавать пользовательские профили для управления ресурсами путём контроля нагрузки на систему.
• pg_trace обеспечивает глубокий анализ и профилирование SQL-запросов.
• pg_archive автоматически архивирует исторические данные из партиционированных таблиц.

Отказоустойчивость и надёжность

Для гарантии надёжности используются pg_cluster и wal-g. Эти инструменты отвечают за механизмы отказоустойчивости, резервное копирование и восстановление после сбоев.

Безопасность и сертификация

Модуль ЗСУБД операционной системы Astra Linux Special EditionLSE 1.8 имеет сертификацию ФСТЭК по 1 категории, редакция Tantor Certified сертифицирована ФСТЭК по 4 категории. Поддерживается прозрачное шифрование данных (Transparent Data Encryption, TDE).

СУБД совместима с ОС Astra Linux Special Edition во всех режимах функционирования. Отдельное приложение pg_sec_check проводит комплексный аудит безопасности СУБД. Протокол аутентификации OAuth 2.0 позволяет приложениям получать защищённый доступ к данным без передачи паролей пользователей.

Реализован контроль целостности баз данных и конфигурации СУБД, удаление объектов баз данных без возможности восстановления: очистка файлов во внешней памяти перед удалением, очистка версий строк, очистка страниц перед удалением, очистка оперативной памяти перед освобождением, очистка журнала упреждающей записи перед удалением или перезаписью.

Экосистема и совместимость

Платформа Tantor, входящая в поставку каждой редакции, обеспечивает самый широкий функционал для администрирования и управления БД среди решений для PostgreSQL.

Поддерживаемые ОС: Astra Linux, Alt Linux, МСВСфера, Ред Софт, CentOS, Red Hat, Rocky Linux, Ubuntu, Debian, Oracle Linux.

Tantor предоставляет единое окно технической поддержки для продуктов Tantor и «Группы Астра», что обеспечивает качество и скорость решения вопросов. Вендорская поддержка доступна для всех редакций СУБД, полное описание ограничений СУБД опубликовано в документации.

Лицензирование

Классическая модель — поядерное лицензирование физических или виртуальных ядер сервера. Для СУБД под 1С есть адаптированная схема для SMB-рынка, где стоимость лицензии рассчитывается исходя из количества работников заказчика.

Планы на 2026 год

Запланирована сертификация ФСТЭК для Tantor Postgres 17.x, выпуск СУБД Tantor Postgres 18, выпуск редакции с разделением Compute и Storage. В разработке интеграция RocksDB, реорганизация таблиц без блокировок, реализация Tantor Postgres DBaaS в Astra Cloud, развитие PipelineDB в сторону более тесной интеграции с Columnar, поддержка сжатия на уровне JDBC-драйвера.

3. Postgres Pro: форк PostgreSQL с российской разработкой и встроенным кластером

Тип: реляционная СУБД общего назначения на базе PostgreSQL

Postgres Pro — российская разработка на основе PostgreSQL. Компания объединяет 70% российских контрибьюторов PostgreSQL, входит в ТОП-5 мировых разработчиков этой СУБД. Продукт включён в реестр российского ПО, сертифицирован ФСТЭК России. На рынке 10 лет, в команде более 400 специалистов.

Где используют

• Один из масштабных кейсов — миграция ГИС ГМП Федерального казначейства на Postgres Pro Shardman. Система обрабатывает платежи национального масштаба и работает в распределённой архитектуре.
• «Авито» перенесли базы данных 1С с Microsoft SQL Server на Postgres Pro Enterprise. Объём данных — более 10 ТБ. Платформа обрабатывает 220 млн объявлений ежемесячно, обслуживает 62 млн пользователей и до 10 сделок в секунду.
• Газпромбанк мигрировал ключевую АБС с Oracle на Postgres Pro Enterprise. Проект потребовал перестройки архитектуры и детального тестирования под пиковыми нагрузками.
• «Росатом» развернул автоматизированную систему управления финансами и перенёс СЭД на Postgres Pro Enterprise Certified. Решение обслуживает более 250 предприятий атомной отрасли.

Редакции и специализация

Линейка включает пять основных редакций:

• Postgres Pro Enterprise — флагманская версия для высоконагруженных систем с более чем 100 дополнительными функциями относительно PostgreSQL. Поддерживает до 10 000 одновременно работающих пользователей.
• Postgres Pro Enterprise для 1С — оптимизирована под платформу 1С. Ускоряет ключевые операции, закрыть месяц можно до 10 раз быстрее по сравнению с базовыми решениями.
• Postgres Pro Enterprise Certified — сертифицированная ФСТЭК версия Enterprise со встроенными средствами защиты.
• Postgres Pro Standard — улучшенная версия PostgreSQL с повышенной производительностью и полнотекстовым поиском.
• Postgres Pro Certified — сертифицированная ФСТЭК версия Standard.

BiHA: встроенный отказоустойчивый кластер

BiHA (Built-in High Availability) — встроенный отказоустойчивый кластер, работает «из коробки» без внешних компонентов. При сбое основного узла система автоматически переключается на реплику. Механизм не требует отдельной настройки Pacemaker, Corosync или других решений для управления кластером — всё интегрировано в ядро СУБД.

Масштабирование: Shardman и Citus

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

Postgres Pro Shardman — распределённая СУБД с автоматическим управлением шардами. Данные распределяются по узлам, система сама отслеживает топологию и балансирует нагрузку. Использовался в проекте миграции ГИС ГМП.

Citus — расширение для распределённых запросов и параллельной обработки. Подходит для аналитических задач и работы с большими объёмами данных.

Proxima и управление жизненным циклом данных

Proxima — встроенный пулер соединений и прокси-сервер. Оптимизирует управление подключениями, снижает накладные расходы на создание новых сессий.

ILM (Information Lifecycle Management) — управление жизненным циклом данных. Позволяет автоматически перемещать старые или редко используемые данные на более дешёвые носители без остановки системы.

Миграция с Oracle и других СУБД

Postgres Pro включает инструменты для упрощённой миграции с Oracle: поддержка PL/SQL-совместимого языка, эмуляция пакетов Oracle, совместимость типов данных.

Экосистема инструментов

Postgres Pro Enterprise Manager (PPEM) — графическая платформа для управления кластерами, мониторинга производительности и резервного копирования. Интерфейс позволяет управлять несколькими инстансами одновременно.

Postgres Pro Backup Enterprise — инструмент для инкрементального резервного копирования. Поддерживает восстановление на точку во времени (PITR) и сжатие данных.

Техническая поддержка и документация

Техническая поддержка работает 24/7, два уровня: базовая и расширенная. Расширенная включает решение задач, требующих изменений в ядре СУБД. Доступен портал техподдержки с личным кабинетом и базой знаний.

Документация включает книги, курсы, демобазу для обучения, глоссарий и HOW-TO видео. Для студентов и вузов есть отдельные программы.

Доступность

Продукты доступны через интеграторов и дистрибьюторов. Лицензирование поядерное. Для разработчиков прикладного ПО предусмотрены отдельные условия. Можно протестировать через личный кабинет на сайте.

Компания проводит регулярные мероприятия: PGPro TechDay, PGMeetup по шардированию и другим техническим темам.

4. Tarantool DB: in-memory СУБД для real-time систем

Тип: NoSQL in-memory СУБД, key-value/документная

Tarantool DB — российская in-memory СУБД с открытым кодом, разработка VK. Включена в реестр отечественного ПО (№ 23005 от 28.06.2024), сертифицирована ФСТЭК России. Основной фокус — системы реального времени с требованиями к задержке в единицы миллисекунд.

Где используют

• Tarantool применяют как кэш-слой для автоматизированных банковских систем и дисковых СУБД. Вместо полной замены core-систем создаётся быстрый промежуточный слой, который снижает нагрузку на основное хранилище.
• В банковской архитектуре СУБД работает как оперативное хранилище между клиентскими приложениями и базовой АБС. Это позволяет обрабатывать запросы без обращения к медленным дисковым системам.
• В телекоме и ритейле используют для организации «золотой записи» клиента, цифрового профиля, единой авторизации и real-time биллинга. В e-commerce — для обработки потоков событий и маркетинга в реальном времени.

Drop-in замена Redis

В поставке есть механизм замены Redis с минимальными изменениями кода. Поддерживаются 60+ команд Redis, типы данных Redis, Redis ACL для управления доступом и настройки, совместимые с Redis.

Есть логирование событий и шифрование TLS. Переход с Redis на Tarantool не требует переписывать клиентское приложение — достаточно изменить конфигурацию подключения.

Схемы данных и работа с памятью

Tarantool поддерживает несколько схем: key-value, таблицы и документы. Данные хранятся в оперативной памяти с возможностью сжатия для экономии ресурсов.

Для сохранности предусмотрена упреждающая журнализация (WAL) и создание снимков состояния БД. При сбое система восстанавливается быстро благодаря механизму быстрого восстановления.

CRUD-операции работают с объектами в кластерном хранилище. Поддерживаются вторичные индексы и управление временем жизни данных (TTL). Справочники можно хранить прямо в кластере.

Репликация и шардирование

Доступна синхронная и асинхронная репликация. Шардирование (сегментирование данных) встроено в платформу — не нужны внешние инструменты для горизонтального масштабирования.

Failover для отказоустойчивости работает автоматически: при падении узла система переключается на реплику. Управление кластером реализовано через собственную технологию Tarantool.

API и интеграция

Для работы с данными из бизнес-приложений есть коннекторы на Java и Go. API поддерживает чтение и запись данных в кластерное хранилище.

Метрики мониторинга экспортируются в Prometheus и Grafana. Развёртывание возможно в Kubernetes. Поддерживаются российские ОС: Astra Linux и РЕД ОС.

Экосистема продуктов

Помимо Tarantool DB, в экосистеме есть:

• Tarantool Enterprise Edition — коммерческая версия с расширенной поддержкой
• Tarantool CDC — Change Data Capture для синхронизации с другими системами
• Tarantool Graph DB — графовая база данных
• Tarantool Queue Enterprise — система очередей
• Tarantool Column Store — колоночное хранилище для аналитики
• Tarantool Clusters Federation — управление федерацией кластеров
• Tarantool Kubernetes Operator — оператор для Kubernetes
• Tarantool Cloud Edition — облачная версия

Горизонтальное масштабирование

Переход с вертикального масштабирования (более мощное железо) на горизонтальное (больше узлов) снижает расходы на оборудование. Создание копий данных с быстрым доступом распределяет нагрузку между серверами.

Встроенные инструменты шардирования автоматически распределяют данные по узлам. Не нужно вручную настраивать балансировку или разбивать таблицы.

Документация и поддержка

Техническая документация доступна на русском языке. Есть руководства по началу работы для Enterprise Edition и Community Edition, документация по модулям и Data Grid.

Сообщество общается в Telegram, VK, GitHub и Stack Overflow. Есть блог с техническими статьями.

5. ClickHouse: колоночная СУБД для аналитики

Тип: колоночная OLAP-СУБД для онлайн-аналитической обработки

ClickHouse — колоночная СУБД для аналитических задач, доступна как open-source проект и облачный сервис. Разработка началась в Яндексе, сейчас развивается как независимый проект. Основной фокус — обработка больших объёмов данных в режиме реального времени с возвратом результата за время менее секунды.

OLAP vs OLTP

ClickHouse решает задачи онлайн-аналитической обработки (OLAP): SQL-запросы со сложными вычислениями, агрегациями и арифметикой по миллиардам и триллионам строк. Аналитические запросы обрабатывают большие объёмы данных, в отличие от транзакционных (OLTP), которые читают и записывают несколько строк за запрос.

Колоночное хранение

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

При выполнении запроса с диска читаются только те столбцы, которые требуются. Если в таблице 100 столбцов, а запрос обращается к пяти, остальные 95 не загружаются в память. В построчной СУБД даже при обращении к одному столбцу приходится загружать данные всей строки, так как блоки на диске содержат значения всех столбцов вместе.

Производительность

На примере реальных данных веб-аналитики: запрос по 100 миллионам строк с фильтрацией и группировкой выполняется за 92 миллисекунды. Пропускная способность — около 1 миллиарда строк в секунду или около 7 ГБ данных в секунду.

Приблизительные вычисления

ClickHouse может жертвовать точностью ради производительности. Некоторые агрегатные функции вычисляют приблизительное количество различных значений, медиану и квантили. Запросы можно выполнять по выборке данных для быстрого получения приблизительного результата.

Агрегацию можно выполнять с ограниченным числом ключей вместо всех. При смещённом распределении ключей это даёт достаточно точный результат при меньших затратах ресурсов по сравнению с точным расчётом.

SQL и стандарт ANSI

ClickHouse поддерживает декларативный язык запросов на основе SQL, который во многих случаях соответствует стандарту ANSI SQL. Поддерживаются GROUP BY, ORDER BY, подзапросы в FROM, JOIN, оператор IN, оконные функции и скалярные подзапросы.

Синтаксис знаком разработчикам, работавшим с реляционными СУБД, но внутренняя логика выполнения запросов отличается из-за колоночного хранения.

Репликация и целостность данных

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

Восстановление после большинства сбоев выполняется автоматически или полуавтоматически в сложных случаях. Ролевое управление доступом (RBAC) реализовано через SQL-запросы, аналогично стандарту ANSI SQL и популярным реляционным СУБД.

Адаптивные алгоритмы соединения

ClickHouse адаптивно выбирает алгоритм соединения таблиц: начинает с быстрых хеш-соединений и переходит к merge-соединениям, если в запросе участвует более одной крупной таблицы. Система сама определяет оптимальную стратегию на основе характеристик данных.

Сценарии использования

ClickHouse применяют для веб-аналитики, логирования событий, мониторинга инфраструктуры, анализа временных рядов, обработки данных с датчиков IoT. Везде, где нужно агрегировать большие объёмы данных с низкой задержкой.

Типичный паттерн — сбор событий в реальном времени (клики, просмотры, логи) и построение дашбордов с обновлением каждые несколько секунд. ClickHouse обрабатывает миллиарды записей и возвращает результаты агрегации быстрее, чем традиционные хранилища данных.

Open-source и облако

Проект доступен на GitHub под лицензией Apache 2.0. Есть коммерческое облачное предложение ClickHouse Cloud с управляемой инфраструктурой. Можно развернуть на собственных серверах или использовать облачный вариант без управления кластером.

Выбор СУБД зависит от типа задач и архитектуры проекта. Для транзакционных систем с частыми операциями чтения-записи подходят РЕД База Данных и Postgres Pro — обе работают по модели OLTP, поддерживают ACID и совместимы с существующими инструментами разработки. Универсальная СУБД Tantor Postgres имеет специализированную версию для работы с 1С, производительность которой подтверждена тестами с одновременной работой десятков тысяч пользователей. Tarantool закрывает сценарии, где критична задержка в миллисекунды: кэширование, сессии, real-time биллинг. ClickHouse и Arenadata DB решают аналитические задачи, но по-разному: первый оптимизирован под скорость отдельных запросов с колоночным хранением, второй — под корпоративные хранилища данных с MPP-архитектурой и полной совместимостью с PostgreSQL.

1. H3LLO.CLOUD

H3LLO.CLOUD — молодая, но амбициозная облачная платформа гиперскейлерского уровня, построенная с нуля без легаси и на передовом железе. Облако уже находится в боевой эксплуатации, с гарантированным SLA 99.97% и возможностью масштабирования клиентских нагрузок в 10 раз и более в моменте. Команда обещает бенчмарк на уровне 1 миллиарда запросов в секунду — подобную нагрузку держит только AWS. Пока кейсы клиентов в процессе подготовки, платформа уже показывает уверенную стабильность: с момента запуска не было зафиксировано ни одного падения нагрузки в проде. Под капотом — каналы до 800 Гбит/с, внутренние сети на 400 Гбит/с, балансировщик нагрузки, автоскейлинг (в разработке), быстрый отклик техподдержки (от нескольких минут до пары часов).

H3LLO.CLOUD предлагает IaaS и PaaS: виртуальные машины, объектное хранилище (S3), DNS, балансировщики, базы данных, Kubernetes, очереди и SOC — всё на собственной платформе без OpenStack. В архитектуре предусмотрено размещение в трёх дата-центрах: два в IXCellerate (Москва) и один собственный, до конца года появятся еще пять региональных площадок. Используются серверы последнего поколения HP Proliant Gen11 на процессорах Intel Gen6 и памяти DDR5 — это дороже, но в 3 раза быстрее, обеспечивая до 40% экономии для клиента.

Условия тарификации прозрачны: базовый набор ресурсов (2 vCPU, 4 ГБ RAM, 40 ГБ диска, белый IP, база данных, 100 ГБ S3 и Load Balancer) предоставляется на год бесплатно при пополнении баланса всего на 5000₽. Управление — через собственную панель с мониторингом, поддержка API и скриптов для автоматизации.

2. L1veStack

L1veStack — бессерверная PaaS-платформа, созданная для быстрого развёртывания, управления и масштабирования приложений на базе Docker-контейнеров. Это решение фокусируется на упрощении работы DevOps-инженеров и разработчиков: запуск микросервисов происходит за секунды, а мониторинг и настройка портов — через интуитивную панель. SLA платформы составляет 99.97%, показатели отказоустойчивости и масштабируемости соответствуют продакшен-нагрузкам. Кейсы клиентов находятся в процессе, однако инфраструктура уже стабильно работает в разных сценариях: от слабонагруженных Dev-сред до боевых систем с нестабильным трафиком.

L1veStack подходит для тех, кто ищет баланс между простотой VPS и возможностями облачной архитектуры. Платформа реагирует на пиковые нагрузки, адаптируясь под разные среды: dev, stage, прод и внутренние сервисы. Средний аптайм — 99.97%, масштабирование происходит гибко и без участия пользователя.

Цены прозрачны:

• 1%vCPU (High Performance) — 0,45 ₽/час
• MB RAM (DDR5) — 0,00085 ₽/час
• GB SSD (3xReplicated) — 0,015 ₽/час
• IPv4 Public IP — 0,015 ₽/час

Сейчас проект в бете: все ресурсы предоставляются бесплатно, а ранние пользователи получат бонусы. Управление — через удобную визуальную панель со статусами контейнеров и настройкой в пару кликов.

3. Incloud

Incloud — облачная платформа для бизнеса любого масштаба, работающая на отказоустойчивом кластере VMware с использованием Enterprise-СХД NetApp и HPE 3PAR. Вся инфраструктура резервирована: дублируются сетевые устройства, питание обеспечивается двумя вводами от разных подстанций и собственными дизельными генераторами. Это гарантирует стабильность и защищённость сервисов, что подтверждается аптаймом 100% за последние 12 месяцев при SLA 99.95%.

На платформе развёрнуты десятки проектов малого и среднего бизнеса, в том числе NT-IT — IT-аутсорсер, обслуживающий клиентов с разнообразной инфраструктурой. До перехода в облако Incloud компании приходилось сталкиваться с разрозненными системами и частыми инцидентами у разных провайдеров. После миграции в Incloud удалось централизовать управление пулами ресурсов, сократить сроки запуска новых проектов с нескольких дней до часов и снизить число простоев до минимума. Инженеры NT-IT отмечают быстрый отклик поддержки и возможность гибкого масштабирования без расширения штата.

Incloud предоставляет IaaS и SaaS-решения, включая корпоративную почту Exchange, базы данных и 1С. Масштабирование происходит мгновенно за счёт резерва мощностей: в любой момент можно увеличить ресурсы под пиковую нагрузку. Среднее время реакции техподдержки на инциденты — 15 минут.

Тарифы прозрачны: базовый CPU — от 250 ₽, RAM — от 200 ₽ за 1 ГБ, диски — от 4 ₽ за 1 ГБ (SATA) до 12 ₽ (SSD/NVMe), резервные копии — 2 ₽ за 1 ГБ. Для производительных конфигураций CPU доступен от 500 ₽ за ядро и RAM — от 250 ₽. Калькулятор для расчёта доступен на сайте.

4. Cloud.ru

Cloud.ru Evolution — это масштабируемая облачная платформа, построенная на собственных технологиях и открытых компонентах. Пользователям доступны десятки IaaS- и PaaS-сервисов: от виртуальных машин и управляемых баз данных до платформы для ML-задач и AI-инструментов. Облачная инфраструктура размещена в дата-центрах Tier III на территории РФ, соответствует требованиям 152-ФЗ и аттестована по УЗ-1. SLA — 99.95%.

Платформа работает по модели «pay-as-you-go» и предлагает гибкую архитектуру: Managed Kubernetes, бессерверные контейнеры, балансировщики нагрузки, геораспределённые хранилища и поддержку Terraform. Есть и физические выделенные серверы, и мощные вычислительные ресурсы с GPU. Новые пользователи получают грант в 4000 бонусов и доступ к free tier. В числе PaaS-инструментов — Kafka, Redis, PostgreSQL, ArenadataDB, Spark, Trino и платформа AI Factory с LLM, инференсом, агентами и обучением ML-моделей в распределённой среде. Панель управления объединяет весь стек облачных сервисов и даёт полный контроль над расходами, доступами и ресурсами.

Cloud.ru подходит как для построения базовой инфраструктуры проекта, так и для сложных AI- и data-driven-сценариев. Среди преимуществ — поддержка контейнеров, работа с Terraform и CLI, встроенные инструменты безопасности и быстрое масштабирование.

Узнать цену для своего сервиса можно через калькулятор.

5. Selectel

Частное облако Selectel — решение для проектов со строгими требованиями к информационной безопасности и кастомизации. Оно может быть развернуто как на инфраструктуре Selectel, так и on-premise, с полным сопровождением инженеров 24/7, лицензированием по модели «за хост» и временем реакции на критические инциденты от 15 минут. Облако полностью совместимо с OpenStack и входит в реестр российского ПО.

Selectel проектирует архитектуру под конкретные задачи клиента: гибкая настройка железа (Intel Xeon, AMD EPYC, NVIDIA GPU), интеграция с СХД, конвергентное и гиперконвергентное хранение на базе Ceph. Возможны сценарии с геораспределённостью и гибридной инфраструктурой. Поддерживаются масштабируемые отказоустойчивые базы данных (PostgreSQL, Kafka, Redis и др.) и Managed Kubernetes до 1 500 нод с GPU-кластерами.

Компания также реализует меры защиты данных под любые регуляторные требования: 152-ФЗ, ФСТЭК №17/21, ГОСТ Р 57580, PCI DSS 4.0. Selectel помогает пройти аттестацию до К-1/УЗ-1 и развивать инфраструктуру с ежемесячными обновлениями и SLA до 99.98%. Это облако для тех, кому нужно не просто IaaS, а стабильная и безопасная цифровая среда, полностью адаптированная под бизнес.

Цены рассчитываются индивидуально.

6. VK Cloud

VK Cloud — универсальная облачная платформа, включающая широкий спектр IaaS- и PaaS-сервисов для разработки, хранения данных, масштабирования и построения отказоустойчивой cloud-native инфраструктуры. Платформа подходит как для стартапов, так и для крупных корпоративных заказчиков, предлагая гибкие условия подключения, бесплатную миграцию и сертифицированную безопасность.

VK Cloud предоставляет виртуальные серверы, сети, объектное хранилище, управляемые базы данных, Kubernetes-кластеры, а также решение VK Data Lakehouse для работы с большими данными. Вся инфраструктура размещена в дата-центрах уровня Tier III в России и соответствует требованиям 152-ФЗ, ГОСТ Р 57580, ISO, PCI DSS. Облачные серверы аттестованы по 152-ФЗ.

Платформа построена на OpenSource и российском ПО, обеспечивает единое резервируемое окружение, автоматическое масштабирование, плановые бэкапы и послеаварийное восстановление. SLA — 99,95% с финансовыми гарантиями. Поддержка 24/7 и «IT-служба одного окна» делают VK Cloud удобным выбором для любых сценариев.

Дополнительно: приветственный бонус 5000 ₽ для новых аккаунтов (до 12 000 ₽ — для юрлиц), гранты до 2 млн ₽ для стартапов и 10 000 ₽/мес. для благотворительных фондов.

7. Timeweb.Cloud

Timeweb.Cloud предлагает аренду выделенных серверов (bare metal) в дата-центрах уровня Tier III в России и Европе с гарантированным SLA до 99,98%. Это решение для тех, кто ищет высокую производительность, изолированную инфраструктуру и максимальную гибкость в управлении.

Вы получаете физический сервер полностью в своё распоряжение: root-доступ, KVM-консоль в панели управления, возможность установить любое ПО и ОС, а также подключать дополнительные процессоры, диски и шлюзы. Вся настройка доступна на уровнях сервера, железа и сети — вплоть до объединения в приватную сеть между регионами и провайдерами.

Timeweb.Cloud предоставляет мощные конфигурации на базе процессоров Intel Xeon Gold, AMD Ryzen 9 и EPYC, с NVMe-дисками и премиальными сборками от Supermicro и Gigabyte. Быстрый запуск готовых конфигураций — от 1 часа, индивидуальные — за 1 день.

Техподдержка — сильная сторона сервиса: персональный менеджер, ответы по телефону и в чате — за минуту, в тикетах — до 15 минут. Надёжность подтверждена соответствием 152-ФЗ, PCI DSS и ISO. Timeweb.Cloud — подходящее решение для разработчиков и бизнеса, которым нужно больше, чем просто «облако», и которые ценят контроль, мощность и поддержку.

На что ориентироваться при выборе облака

Универсального «идеального» облака не существует: платформа должна соответствовать именно вашим задачам. Для стартапов и быстрых MVP подойдут решения с простым управлением и гибкой тарификацией вроде L1veStack или H3LLO.CLOUD. Если ключевую роль играет отказоустойчивость и предсказуемый SLA — обратите внимание на Incloud, Cloud.ru или Selectel. Для работы с большими данными, ML и высоконагруженными сервисами удобнее использовать экосистемы уровня VK Cloud. А если требуется полный контроль над железом и гарантированная изоляция, оптимальным выбором станут выделенные серверы Timeweb.Cloud.

При выборе облака важно учитывать три фактора: технические возможности (производительность, поддержка контейнеров, интеграция с CI/CD), надёжность (аптайм, резервирование, дата-центры Tier III) и экономику (модель тарификации, стоимость ресурсов, наличие грантов и бонусов). Сравнив эти параметры в разрезе реальных сценариев, вы сможете выбрать платформу, которая не подведёт именно в вашем продакшене.

Согласно имеющимся данным, злоумышленники проникли во внутренние системы компании и находились там несколько месяцев.

Хакеры утверждают, что получили доступ к исходному коду, технической документации, рабочим перепискам и внутренним сервисам.

Более того, они заявили, что удалили часть инфраструктуры, включая базы данных, которые, по их словам, были связаны с воинским учетом.

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

«Микорд» подтвердил факт взлома, но от комментариев уклонился

По данным СМИ, директор «Микорда» Рамиль Габдрахманов подтвердил факт кибератаки, но отметил лишь, что «подобное случается со многими компаниями». От каких-либо уточнений он отказался.

Эта формулировка оставляет ситуацию неопределенной: нет публичных доказательств масштаба ущерба, но сам факт проникновения подтвержден.

Что известно о самом реестре

Единый цифровой реестр воинского учета создается с 2023 года. В проекте участвуют Минцифры, Ростелеком и подрядчики, среди которых пресса неоднократно упоминала «Микорд».

Ключевые даты:

• апрель 2023 — старт инициативы;
• февраль 2024 — Ростелеком назначен единственным исполнителем госконтракта, срок завершения — 31 декабря 2024 года;
• планировалось запустить систему осенью 2024 года, но полноценный запуск состоялся лишь в 2025-м;
• с октября 2025 года военкоматы десятков регионов начали размещать электронные повестки, а четыре региона полностью отказались от бумажных носителей.

Если данные, действительно удаленные хакерами, были связаны с реестром, это может привести к нарушению процессов уведомления, работе военкоматов и корректности сведений о призывниках.

А если в проекте несколько кластеров на разных контурах и разные типы СУБД, время на администрирование бесполезно увеличивается. Проверили RT.ClusterManager — инструмент для управления несколькими СУБД через один веб-интерфейс

Зачем нужен менеджер кластеров

Типичная задача DBA выглядит так: развернуть кластер, настроить мониторинг метрик, организовать бэкапы, раздать права доступа разным специалистам команды. Для кластерных и MPP-решений добавляются риски — при обновлении ПО, изменении настроек или масштабировании можно сломать кластер, даже если вы действуете чисто по документации.​

Проблема масштабируется с количеством кластеров. Если у вас один Greenplum-кластер на проде, можно обойтись Ansible-скриптами и ручными операциями через psql. Но когда кластеров несколько — dev, stage, prod, плюс разные СУБД для логов и Hadoop для озера данных, — переключение между инструментами и повторение одних и тех же операций убивает время.

Чек-лист, когда нужен один интерфейс:

• У вас несколько кластеров на разных контурах (разработка, тестирование, продакшен)
• В проекте используются разные типы СУБД — MPP для аналитики, колоночные для быстрых агрегаций, NoSQL для метаданных
• С кластерами работают специалисты с разным уровнем доступа: разработчики могут читать метрики, DBA — масштабировать, поддержка — только просматривать логи
• Требуется автоматизировать рутинные операции: развертывание новых нод, создание бэкапов по расписанию, установку расширений

Что решает RT.ClusterManager

Управление базами данных в продакшене — это не только написание SQL-запросов. Типичная задача выглядит так: развернуть кластер, настроить мониторинг, организовать бэкапы, раздать права доступа разным специалистам. Если у вас несколько кластеров на разных контурах и разные типы СУБД, время на администрирование растёт кратно.​

RT.ClusterManager автоматизирует развёртывание и управление несколькими типами СУБД через веб-интерфейс. Инструмент работает с RT.Warehouse (на базе Greenplum), RT.WideStore (Clickhouse), RT.DataLake (Hadoop) и RT.KeyValue (Cassandra). Помимо СУБД, управляет другими решениями платформы TData: RT.MDM, RT.DataGovernance, RT.Streaming, RT.DataVision. Для хранения метаданных использует PostgreSQL.

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

Как работает развёртывание

Развёртывание происходит через протестированные Ansible-скрипты, собранные в плагины для работы с конкретным продуктом. При установке плагина и инсталляции продукта система сама проверяет готовность серверов перед установкой и сообщит об ошибках конфигурации, учтёт все зависимости компонентов и выдаст подробный лог установки.​

Помимо on-premise, RT.ClusterManager подготовлен для работы в облачных средах — включает плагины на базе Terraform для управления облачной инфраструктурой и взаимодействия с платформами контейнеризации.​

Функции администрирования

Инструмент покрывает стандартные операции DBA:​

• Масштабирование. Горизонтальное и вертикальное масштабирование делается через интерфейс. Для MPP-кластеров это нужно — неправильная последовательность действий может привести к недоступности данных.​
• Резервное копирование. Создание резервных копий настраивается в интерфейсе. Можно автоматизировать бэкапы по расписанию.​
• Расширения. Можно устанавливать расширения вроде PostGIS или DiskQuota через интерфейс. Не нужно подключаться к нодам вручную.​
• Мониторинг. Встроен в веб-интерфейс — доступны метрики серверов и системных таблиц ядра Greenplum. Если стандартного набора метрик недостаточно, их можно расширить через модуль RT.Monitoring на базе Grafana.​
• Настройка политик. Можно настраивать парольные политики и контролировать данные. Задания по обслуживанию СУБД создаются в крон-формате из интерфейса.​

Ролевая модель и доступы

Можно настроить права для разных специалистов, по умолчанию доступны роли: Пользователь, Поддержка, Администратор, Супер-Администратор, Менеджер. Например, сотруднику поддержки можно дать доступ только на просмотр без возможности изменений. При необходимости создаются кастомные роли с уникальными правами.​

Ещё одна фишка — возможность разделить роли между продуктами. Администраторы СУБД не получат доступ к продуктам визуализации или управления данными, если это не требуется.​

Авторизация работает через локальные учётные записи или Active Directory по протоколу LDAP. Кластеры дополнительно поддерживают керберизацию.​

RT.Warehouse: MPP-СУБД для аналитических нагрузок

RT.Warehouse — это доработанная версия Greenplum 6.26.1 от вендора TData. СУБД ориентирована на аналитические задачи с большими объёмами данных и работает по архитектуре MPP (Massively Parallel Processing) — запросы распределяются между несколькими узлами для параллельной обработки.​

Основной сценарий использования — когда нужно обрабатывать петабайты данных и выполнять сложные аналитические запросы. Работа с данными происходит через стандартный SQL, что снижает порог входа для команд, знакомых с реляционными СУБД. Для интеграции с другими источниками данных доступны коннекторы и протоколы, включая кастомизированный PXF с шифрованием паролей JDBC-подключений.​

RT.Warehouse поддерживает RBAC (Role-Based Access Control) — можно ограничить доступ к конкретным колонкам и определённым SQL-командам. Это важно, когда с одной базой работают разные отделы, и каждому нужен свой уровень доступа к данным.​

Технические детали и масштабируемость

Инструмент работает с кластерами любого размера — от одной ноды до десятков нод суммарным объёмом на сотни терабайт. Производительность интерфейса при этом не меняется. Доступны две темы оформления: светлая и тёмная.​

Развёртывание возможно в облаке, on-premise или в гибридной модели. Поддерживаются отечественные операционные системы: RedOS, Astra, ALT Linux. Продукт зарегистрирован в реестре российского ПО и имеет сертификат ФСТЭК-УД4.​

Лицензирование и поддержка

RT.ClusterManager лицензируется по инстансам и предоставляется условно бесплатно при оформлении основного продукта, например RT.Warehouse.​

RT.Warehouse лицензируется по ядрам CPU на сегмент-серверах. Лицензия предоставляется бессрочно или в формате годовой подписки. При покупке лицензии с технической поддержкой утверждается SLA реакции на инциденты и временем исправления.​

Доступны тестовые лицензии на срок до 90 дней с развёртыванием on-premise в инфраструктуре заказчика или в облаке вендора.​

Документация, интерфейс и техническая поддержка доступны на русском языке. TData совместно с партнёрами — учебными центрами, обладающими необходимыми лицензиями и компетенциями в продуктах — проводит обучение и сертификацию по продуктам платформы по запросу. Компания поддерживает канал в Telegram и публикует материалы на Rutube.​

Когда имеет смысл использовать

Единый интерфейс управления кластерами оправдан в нескольких сценариях:

1. Несколько кластеров и разные СУБД. Если у вас Greenplum для аналитики, Clickhouse для логов, Hadoop для озера данных — переключение между инструментами отнимает время. Единый интерфейс ускоряет рутинные операции.
2. Требования к сертификации. Когда проект требует использования ПО из реестра российских решений или сертификата ФСТЭК, RT.ClusterManager и RT.Warehouse закрывают эти требования.​
3. Команда с разными ролями. Если с кластерами работают разработчики, DBA, поддержка и менеджеры, ролевая модель позволяет разграничить доступ без дополнительных инструментов.

Зачем вообще делать что-то своё?

Я знаю, что вы можете подумать: «Почему бы просто не использовать Elasticsearch?» или «А что насчёт Algolia?» Это вполне рабочие решения, но у них есть нюансы. Нужно разбираться с их API, поддерживать инфраструктуру под них и учитывать все тонкости их работы.

Но иногда хочется чего-то более простого — такого, что:

• работает прямо с вашей текущей базой данных;
• не требует сторонних сервисов;
• легко понять и отладить;
• действительно выдаёт релевантные результаты.

Поэтому я и сделал свою систему поиска — такую, которая использует вашу существующую БД, вписывается в архитектуру проекта и даёт полный контроль над тем, как она работает.

Основная идея

Концепция проста: разбить текст на токены, сохранить их, а затем при поиске сопоставлять токены запроса с токенами в индексе.

Процесс выглядит так:

• Индексация. Когда вы добавляете или обновляете данные, система разбивает текст на токены (слова, префиксы, n-граммы) и сохраняет их вместе с весами.
• Поиск. Когда пользователь вводит запрос, он проходит такую же токенизацию. Затем система ищет совпадающие токены и подбирает подходящие документы.
• Оценка. Сохранённые веса используются для расчёта итоговой релевантности.

Вся суть — в том, как выполняется токенизация и как рассчитываются веса. Сейчас я покажу, что именно имеется в виду.

Строительный блок 1: схема базы данных

Для начала нам нужны всего две таблицы: index_tokens и index_entries.

index_tokens

В этой таблице хранятся все уникальные токены вместе с их весами, полученными от разных токенизаторов.

Важно: один и тот же токен может встречаться несколько раз с разными весами — по одному для каждого токенизатора.

Почему так?

Потому что разные токенизаторы создают один и тот же токен, но с разным весом.

Например, токен parser:

• WordTokenizer → вес 20
• PrefixTokenizer → вес 5

Чтобы итоговый механизм оценки релевантности работал правильно, нужны отдельные записи.

Ограничение уникальности в этой таблице — (name, weight).

То есть имя токена может повторяться, но вес — нет.

index_entries

Эта таблица связывает:

• токен
• документ
• конкретное поле документа

…и хранит итоговый вес, который нужен для процедуры ранжирования.

Структура таблицы index_entries

Что такое weight?

Это итоговый вычисленный вес токена для конкретного поля конкретного документа.

Формула:

Он уже включает всё, что понадобится позже при начислении очков.

Какие индексы добавляем?

Чтобы поиск работал быстро:

• (document_type, document_id) — для быстрого получения документов
• token_id — чтобы быстро находить все документы по токену
• (document_type, field_id) — для поиска по конкретному полю
• weight — для фильтрации по весам

Почему именно такая схема?

Потому что она:

• простая
• эффективно ложится на реляционные БД
• использует сильные стороны SQL
• позволяет масштабировать алгоритм без усложнений

Блок 2: токенизация

Что такое токенизация?

Это процесс разбивки текста на более мелкие части — токены, удобные для поиска.

Например, слово «parser» можно разбить разными способами:

• Как одно целое: ["parser"]
• На префиксы: ["par", "pars", "parse", "parser"]
• На n-граммы (последовательности символов): ["par", "ars", "rse", "ser"]

Зачем несколько токенизаторов?

Разные задачи требуют разных подходов к поиску:

• Один токенизатор для точных совпадений
• Другой — для частичных совпадений
• Третий — для учёта опечаток

Каждый из них играет свою роль в итоговом ранжировании.

Общий интерфейс токенизатора

Все токенизаторы реализуют простой интерфейс:

Простой и расширяемый контракт.

Токенизатор слов (WordTokenizer)

Разбивает текст на отдельные слова. Слово «parser» превращается в

Этот метод отлично подходит для точных совпадений.

Вес: 20 — высокий, для точных совпадений.

Префиксный токенизатор (PrefixTokenizer)

Создаёт префиксы слов, например:

→

(минимальная длина префикса — 4).

Это полезно для поиска по частям слова и автодополнения.

Вес: 5 — средний, для частичных совпадений.

Зачем минимальная длина?

Чтобы избежать слишком большого количества коротких токенов — префиксы короче 4 символов обычно слишком распространены и малоэффективны.

Токенизатор n-грамм (NGramsTokenizer)

Создаёт последовательности символов фиксированной длины (обычно 3).

Например,

→

.

Это помогает улавливать опечатки и частичные совпадения.

Вес: 1 — низкий, но улавливает редкие случаи и опечатки.

Почему длина 3?

Это компромисс между слишком большим количеством совпадений и пропущенными вариантами из-за опечаток.

Блок 3: Система весов

В нашей системе есть три уровня весов, которые работают вместе, чтобы определить важность каждого токена при поиске:

1. Вес поля — например, заголовок, основное содержание или ключевые слова. Разные части документа могут иметь разный приоритет.
2. Вес токенизатора — каждый тип токенизатора (слово, префикс, n-грамма) имеет свой вес. Эти веса хранятся в таблице index_tokens.
3. Вес документа — итоговый вес для конкретного токена в конкретном документе. Хранится в index_entries и рассчитывается по формуле:

Как рассчитывается итоговый вес?

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

Например:

• Вес поля заголовка: 10
• Вес токенизатора слов: 20
• Длина токена «parser»: 6

Тогда итоговый вес:

Почему используется ceil(sqrt())?

• Более длинные токены обычно более специфичны и важны — например, «parser» конкретнее, чем «par».
• Но мы не хотим, чтобы очень длинные токены имели слишком большой вес — 100-символьный токен не должен давать вес в 100 раз больше, чем короткий.
• Функция квадратного корня даёт убывающую доходность — вес растёт с длиной, но не линейно.
• ceil() округляет результат вверх, чтобы сохранить веса целыми числами.

Настройка весов под свои задачи

Вы можете гибко настраивать веса под свои нужды:

• Увеличить вес поля — например, если заголовки для вас важнее всего.
• Изменить вес токенизатора — повысить для точных совпадений (слов), понизить для менее важных (n-граммы).
• Изменить формулу для длины токена — вместо ceil(sqrt()) можно использовать логарифм или линейную функцию, чтобы по-другому влиять на вес длинных токенов.

Таким образом, вы можете точно контролировать, какие части текста и какие типы совпадений важнее при поиске, и подстроить систему под свои требования.

Блок 4: Служба индексирования

Служба индексирования отвечает за обработку документов и сохранение всех их токенов в базе данных для последующего быстрого поиска.

Интерфейс для документов

Чтобы документ мог индексироваться, он должен реализовать интерфейс

с тремя методами:

• getDocumentId() — возвращает уникальный идентификатор документа.
• getDocumentType() — возвращает тип документа (например, статья, пост, комментарий).
• getIndexableFields() — возвращает поля документа, которые нужно индексировать, вместе с их весами.

Пример реализации для статьи:

Когда индексируем?

• При создании или обновлении документа (например, через события).
• По командам в консоли — например, app:index-document или app:reindex-documents.
• Через задачи cron для массовой переиндексации.

Как работает индексирование — шаг за шагом

1. Получаем данные документа: его тип, ID и поля с весами.
2. Удаляем старый индекс для этого документа. Это важно, чтобы избежать дублирования данных.
3. Для каждого поля запускаем все токенизаторы, которые разбивают текст на токены.
4. Для каждого токена:Находим или создаём его в таблице токенов (чтобы не хранить одинаковые токены несколько раз).Рассчитываем итоговый вес по формуле:вес_поля × вес_токенизатора × ceil(квадратный_корень_из_длины_токена) Добавляем информацию в пакет для массовой вставки.Вставляем все новые записи в базу данных одним запросом — так быстрее и эффективнее.
5. Находим или создаём его в таблице токенов (чтобы не хранить одинаковые токены несколько раз).
6. Рассчитываем итоговый вес по формуле:вес_поля × вес_токенизатора × ceil(квадратный_корень_из_длины_токена) Добавляем информацию в пакет для массовой вставки.Вставляем все новые записи в базу данных одним запросом — так быстрее и эффективнее.

Зачем искать или создавать токены?

Токены — это общие элементы для всех документов. Если токен уже есть, используем его повторно, чтобы не хранить дубли и сэкономить место и время.

1. Ключевые моментыСтарый индекс удаляется перед созданием нового — это упрощает обновление.Используется пакетная вставка для производительности.Токены ищутся или создаются, чтобы избежать дубликатов.Итоговый вес считается динамически при индексации.
2. Ключевые моментыСтарый индекс удаляется перед созданием нового — это упрощает обновление.Используется пакетная вставка для производительности.Токены ищутся или создаются, чтобы избежать дубликатов.Итоговый вес считается динамически при индексации.
3. Старый индекс удаляется перед созданием нового — это упрощает обновление.
4. Используется пакетная вставка для производительности.
5. Токены ищутся или создаются, чтобы избежать дубликатов.
6. Итоговый вес считается динамически при индексации.

Блок 5: Служба поиска

Поисковый сервис принимает строку запроса, разбивает её на токены, ищет эти токены в индексах и возвращает список документов, отсортированных по релевантности.

Как это работает — шаг за шагом

1. Токенизация запроса

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

Пример:

• Индексация создала токены: par, pars, parse, parser (префиксный токенизатор).
• Поиск тоже использует префиксный и обычный токенизатор — так мы найдём не только точное слово parser, но и все его варианты.

Если запрос пустой (нет токенов), возвращаем пустой результат.

1. Уникальные токены

Из всех токенов берём только уникальные значения, чтобы не искать одинаковые токены по несколько раз.

1. Сортировка токенов

Токены сортируются по длине — сначала самые длинные. Это важно, потому что более длинные токены — более конкретные и дают более точные совпадения.

1. Ограничение количества токенов

Если пользователь отправит очень длинный запрос, мы ограничиваем число токенов (например, максимум 300), чтобы избежать нагрузок на систему.

1. Выполнение поискового SQL-запроса

Далее строится и выполняется оптимизированный SQL-запрос, который:

• Ищет документы, где встречаются эти токены.
• Считает оценку релевантности для каждого документа.
• Сортирует результаты по убыванию оценки.
• Возвращает ограниченное число результатов (например, топ-10).

Как считается оценка релевантности?

Оценка складывается из нескольких факторов:

• Базовый балл — сумма весов всех найденных токенов в документе.
• Разнообразие токенов — документы с большим количеством разных токенов получают бонус (логарифмическая шкала, чтобы не давать слишком большой перевес).
• Качество совпадений — чем выше средний вес токенов, тем лучше (например, совпадение в заголовке важнее, чем в теле текста).
• Штраф за длину документа — чтобы длинные документы не имели слишком большое преимущество.

В итоге оценка нормализуется на максимальное значение, чтобы можно было сравнивать разные поисковые запросы.

Почему нужен подзапрос с весом токенов?

В подзапросе проверяется, что документ содержит хотя бы один токен с весом выше порогового. Это исключает из результатов документы, которые совпадают только по «шумным» токенам с очень маленьким весом (например, незначительным n-граммам), что улучшает качество поиска.

Пример возвращаемого результата

Поиск возвращает список таких объектов — ID документа и его релевантность.

Как получить сами документы?

Мы берём ID из результатов поиска, и через репозиторий загружаем реальные объекты документов, сохраняя порядок релевантности.

Репозиторий гарантирует, что документы вернутся в том же порядке, что и результаты поиска (используется SQL-функция

Итог

В результате вы получаете мощную и гибкую поисковую систему, которая:

• Быстро находит релевантные документы через индексы в базе данных.
• Обрабатывает опечатки и частичные совпадения с помощью n-грамм и префиксных токенизаторов.
• Придаёт больше веса точным совпадениям (например, полным словам).
• Работает без внешних сервисов — только с базой данных.
• Легко отлаживается и настраивается за счёт прозрачного SQL и гибких весов.

Расширение системы

Добавление нового токенизатора

Чтобы добавить новый способ разбиения текста на токены (например, стемминг, лемматизацию, синонимы и т.д.), нужно:

• Реализовать интерфейс TokenizerInterface, например:

Зарегистрировать этот токенизатор в конфигурации сервиса — и он автоматически будет использоваться и для индексации, и для поиска.

Добавление нового типа документа

Чтобы индексировать новый тип документов (например, комментарии, статьи, профили), реализуйте интерфейс:

Изменение весов и формул

• Вес токенизаторов и полей легко настраивается через конфигурацию.
• Формулы подсчёта релевантности находятся в SQL-запросе — вы можете его изменить, чтобы подстроить оценивание под свои задачи.

Заключение

• Это простая и понятная поисковая система — нет сложных «черных ящиков» и магии.
• Она легко контролируется, настраивается и отлаживается.
• Подходит для большинства приложений, где не нужна гигантская инфраструктура типа Elasticsearch.
• Главное — вы полностью управляете системой, понимаете каждый её шаг и можете улучшать её под свои нужды.

Берите и делайте под себя — это ваш поиск, и он должен работать так, как вам нужно.

Задача в целом проста:

1. Открыть структуру таблицы
2. Скопировать названия колонок
3. Соотнести типы, которые существуют в спецификации (gRPC, OpenAPI, и т.п.)
4. Описать API метод
5. Проверить на соответствие стайл-гайду

Но это утомительно и отнимает драгоценное время разработчиков. Данную инструкцию за нас может выполнить инструмент db-exporter. В этой статье рассмотрим, как с его помощью автоматизировать процесс генерации CRUD-операций для gRPC, соблюдая стандарт Google AIP по ресурсно-ориентированному дизайну.

В последующих разделах мы подробно рассмотрим:

• Принцип работы db-exporter
• Процесс настройки и конфигурации
• Примеры генерации различных типов операций
• Валидацию сгенерированных proto файлов
• Как внедрить инструмент для постоянной работы с ним

Знакомимся с инструментом

db-exporter — это Open Source утилита для генерации кода и документации к схеме базы данных. «Экспортировать» можно в различные распространенные форматы: диаграмма классов, protobuf, код на Go и другие. На данный момент инструмент поддерживает PostgreSQL и MySQL. Реализована поддержка основных операционных систем. Инструмент достаточно молодой и активно развивается.

Для начала работы с db-exporter необходимо скачать его со страницы релизов. Далее разархивировать и переместить в /usr/local/bin. Или выполнить всё одной командой.

Mac OS

Linux

Теперь у нас установлен инструмент и мы почти готовы его запускать, но перед этим разберемся, составим пример таблицы, над которой будем проводить эксперименты.

Составим пример

Договоримся, что нашим примером для генерации кода будет являться таблица пользователей. У пользователей есть: id, имя, отчество, дата создания, статус (активен, заблокирован) и дата удаления.

Итого, схема выглядит так:

Данного примера достаточно для того, чтобы рассмотреть ключевые моменты:

• Генерация первичных ключей (поле id)
• Генерация опциональных полей (поле middle_name)
• Генерация временных меток (поля created_at, deleted_at)
• Генерация енамов (поле status, енам user_status)
• Работа с soft-delete

Генерируем protobuf

Для того, чтобы запустить db-exporter необходимо описать конфигурацию —делается это декларативно, в yaml-файле. db-exporter оперируют задачами, в которых описаны:

• Формат, в котором нужно выполнить генерацию. В нашем случае — это grpc-crud
  

• Директория, в которую сохранить файлы
• Специфичные формату параметры (далее: спека задачи)

Также важно не забыть указать подключение к базе данных. В нашем примере, используется PostgreSQL на 5432 порту. Для успешного запуска стоит убедиться, что БД запущена и в ней есть схема с таблицами.

Итого, конфигурация, описывающая перечисленные требования, выглядит следующим образом:

Сохраняем этот файл, как .db-exporter.yaml.

Далее запускаем инструмент, выполняя команду db-exporter и получаем отчет о проделанной работе — db-exporter сообщает о том, какие файлы были созданы и какой они имеют вес.

Разбираемся, что получили на выходе

В результате выполнения команды был сгенерирован файл users.proto, в котором используется синтаксис соответствует proto3. Файл содержит:

• UsersService с методами List, Get, Delete, Undelete, Create, Patch
• Сообщение User, отражающее таблицу users
• Енам UserStatus

Сообщение User и enum UserStatus

Сообщение User отражает структуру таблицы users и имеет вид:

Что здесь видим?

1. id - uuid'ы генерируются, как строки. Первичный ключ помечается, как OUTPUT_ONLY, говоря о том, что поле используется только для ответов.
2. name, email сгенерированы, как строки
3. Поля created_at, deleted_at обернуто в гугловый Timestamp
   
4. Для статуса пользователя сгенерирован енам UserStatus

UserStatus выглядит следующим образом

Метод для получения списка пользователя

Метод List принимает на вход ListUsersRequest и возвращает ListUsersResponse

Запрос включает в себя поле с массивом идентификаторов пользователей. db-exporter добавляет в тело запроса первичный ключ, если первичный ключ состоит из одного поля. Также в запросе присутствует флаг show_deleted, как того требует стандарт AIP-132, при работе с сущностями, поддерживающими soft-delete: по умолчанию сервер возвращает список активных пользователей, например, используя sql-запрос с фильтром deleted_at is null.

По умолчанию db-exporter добавляет token-based пагинацию, описанную в AIP-158. Такая пагинация удобна для межсервисного взаимодействия. Но если основной клиент вашего API — это фронтенд, то вероятнее всего, вам нужна офсетная пагинация. Ее можно включить, добавив в спеку задачи pagination: offset. Если пагинация уж совсем не требуется, то pagination: none.

В ответе же список пользователей и токен следующей страницы.

Метод получения пользователя

Стандарт по получению ресурса описывает достаточную простую конструкцию — Метод Get принимает на вход GetUserRequest и отдает на выход сообщение User.

Тело запроса включает в себя поле id, так как оно является первичным ключом.

Методы удаления и восстановления пользователя

Стандарт AIP-164 гласит: мало того, что сущность удаляется методом Delete, так еще нужно и мочь ее восстанавливать с помощью метода Undelete, если таблица поддерживает soft-delete.

Поэтому в результате генерации мы получаем методы Delete и Undelete: db-exporter самостоятельно определяет поддержку soft-delete у таблиц, смотря на поля deleted_at и delete_time.

Метод Delete принимает на вход DeleteUserRequest и отдает на выход DeleteUserResponse. Метод Undelete принимает UndeleteUserRequest и возвращает восстановленный ресурс User.

Тела запросов также, как и для метода Get, содержат поле первичного ключа — id.

По умолчанию возвращается google.protobuf.Empty, как требуется в стандарте. Возможна генерация пустого сообщения DeleteUserResponse — для этого нужно добавить параметр в спеку:

Методы создания и обновления пользователя

По стандартам AIP-133 и AIP-134 методы Create и Update имеют похожие сигнатуры.

Тела запросов также схожи, включают в себя ресурс User и возвращают его обновленную версию.

По стандарту поле update_mask предполагается использовать для частичного обновления сущности. FieldMask содержит в себе список полей, которые необходимо обновить у сущности User.

Добавляем HTTP пути к методам

В gRPC есть полезная опция google.api.http, с помощью которой можно указать HTTP адрес для метода. Ее полезно использовать, если вы используете REST поверх gRPC сервисов — например, с помощью grpc-gateway.

Наверняка, мы хорошие разработчики и версионируем свой API: установим версию v1 в параметре path_prefix.

И получаем вот такой результат:

Валидируем результат

Теперь, когда у нас есть файл users.proto — важно проверить, что он корректен синтаксически. Для этого соберем go-клиент, используя утилиту protoc.

Указываем Go пакет

Выше мы обсуждали gRPC контракты без привязки к конкретному стеку. Ну что ж, время пришло!

Для генерации Go-клиента в .proto файле необходимо указать опцию go_package. Мы можем сами поправить .proto файл, но при частом использовании db-exporter это будет не так удобно, поэтому скажем экспортеру, какой пакет нам нужен. Для этого нужно указать опцию в спеке задачи .db-exporter.yaml:

Нам остается еще раз сгенерировать users.proto, используя уже знакомую команду db-exporter.

Собираем зависимости

Сгенерированный users.proto импортирует зависимости google.api для указания HTTP методов/путей, обязательности полей. Их можно скачать с GitHub googleapis: http.proto, field_behavior.proto и annotations.proto.

Скачать зависимости можем следующим скриптом:

Итого мы должны были организовать следующую структуру файлов:

Теперь запустим генерацию гошного кода:

В результате выполнения команды в наш проект добавились 2 новых файла:

• pkg/api/users.pb.go — структуры для ресурса, запросов и ответов
• pkg/api/users_grpc.pb.go — rpc-сервис UserService и клиент к нему

Вывод: из сгенерированного db-экспортером .proto файла можно сгенерировать валидный програмнный код. Считаем проверку успешно выполненной

Непрерывная генерация

Перезапись файлов

Собранная нами конфигурация отлично подходит для «одноразовых генераций», но со временем, когда сервис обрастет новыми методами, использовать генератор будет неудобно из-за того, что он по умолчанию перезаписывает уже существующие файлы. Чтобы избежать такой ситуации, необходимо указать генератору, что мы не хотим перезаписывать файлы. Сделать это можно, добавив опцию skip_exists.

Теперь db-exporter не будет перезаписывать уже существующие файлы и будет генерировать только новые.

Генерация лишних таблиц

По умолчанию db-exporter генерирует файлы по всем таблицам из схемы БД. В проекте может десяток или десятки таблиц, не для всех из них нужна генерация CRUD-операций. Генератору можно передать список таблиц, по которым необходимо генерировать файлы.

Но править постоянно конфиг не очень удобно. Укажем переменную.

Теперь мы можем запускать генерацию по конкретным таблицам, например вот так:

Или обернуть это в Makefile:

Использовать эту конструкцию можно следующим образом:

Что в итоге?

В итоге мы собрали рабочую конфигурацию db-exporter, которая позволяет генерировать CRUD по схеме БД в валидный .proto файл, включая полезные опции: google.api.field_behavior и google.api.http. Собранную конфигурацию и необходимое окружение вы сможете найти по этой ссылке.

Надеюсь, этот пост был для вас полезным и поможет ускорить разработку крудов. Если у вас есть предложения по улучшению/расширению кодо-генератора, добро пожаловать в репозиторий.

В репозитории вы также сможете найти примеры генерации диаграмм классов, mermaid, markdown и так далее.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

Браузер — это, пожалуй, самое важное приложение на вашем компьютере. Именно через него проходит большая часть вашей цифровой жизни: работа, развлечения, коммуникации. Выбор браузера влияет не только на скорость загрузки страниц, но и на конфиденциальность, безопасность и удобство работы.

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

Safari быстрый, безопасный и не перегружен функциями. Единственный минус — библиотека расширений заметно скромнее, чем у конкурентов. Но для большинства задач базового функционала хватает.

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

Для максимально осторожных пользователей — это Chrome, из которого убрали всю телеметрию Google, отслеживание и облачные сервисы. Браузер работает, но требует ручной настройки: отсутствуют автоматические обновления и встроенная синхронизация между устройствами.

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

Миллионы людей продолжают использовать одни и те же слабые пароли на всех сайтах — или, что ещё хуже, держатся за классику вроде «123456». Даже сильные пароли мало помогают, если их повторяют или забывают. Конечно, большинство браузеров предлагают встроенные менеджеры паролей, но они ограничены, привязаны к одному браузеру и менее безопасны, чем специализированные решения.

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

Предлагает мониторинг даркнета, интеграцию VPN и плавный пользовательский опыт. Есть бесплатный тариф с ограниченными функциями, но премиум-версия конкурентоспособна.

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

Пропустите LastPass — когда-то фаворит, он упал в немилость после повторных утечек безопасности. Для душевного спокойствия лучше поискать в другом месте.

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

Независимо от того, пишете ли вы тексты, планируете проект, кодите или наводите порядок в цифровой жизни, правильные инструменты решают многое. Сегодня выбор топовых приложений для продуктивности и разработки — часто бесплатных — лучше, чем когда-либо.

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

Shotcut и Kdenlive — тоже сильные бесплатные варианты, предлагают более простой фукнционал с хорошим набором функций для новичков и продвинутых пользователей. CapCut, изначально мобильное приложение, теперь доступен на десктопе — идеально подходит для быстрых монтажей и роликов для соцсетей.

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

Выбор коммуникационных и мессенджерных приложений в первую очередь зависит от того, с кем вы общаетесь — с семьёй, друзьями, коллегами или игровым сообществом. Вот актуальная картина:

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

Одно из первых дел, которое стоит сделать после сборки ПК — убедиться, что компоненты соответствуют ожиданиям и работают корректно. К счастью, существует много инструментов, позволяющих мониторить, тестировать и настраивать железо.

Начать стоит с CPU-Z — классического бесплатного инструмента, показывающего информацию о CPU, материнской плате, оперативной памяти и других компонентах. Он также умеет запускать простой стресс-тест и бенчмарк для проверки стабильности.

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

Что вообще можно защитить в IT?

— В законодательстве есть собирательный термин «результаты интеллектуальной деятельности». К ним относятся произведения литературы, искусства, науки, в том числе программное обеспечение, базы данных, изобретение, полезная модель, промышленные образцы и прочее. Часть из них защищается авторским правом, а для части нужен патент.

В IT чаще всего авторское право действует на программы для ЭBM. А вот на стыке IT с инженерией могут возникнуть патенты. То есть патентным правом в большинстве случаев охраняют изобретения, способы передачи данных или другие разработки.

Авторское право и патент — в чём ключевая разница?

— Объектам авторского права ничего не нужно, чтобы получить защиту — право на них возникает сразу, как только создали произведение. Единственное, что надо учитывать, — право принадлежит непосредственному автору. Поэтому если мы говорим о служебном произведении, то сотрудник — это автор, и право возникает у него. А значит, работодатель должен учесть несколько нюансов (дальше о них поговорим).

А вот чтобы получить охрану своего изобретения, нужно регистрировать его в Роспатенте. К слову, право на программу, по желанию, тоже можно зарегистрировать. Это формирует дополнительную привлекательность для инвесторов, банков и государства.

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

Нужно ли вносить разработку в Реестр отечественного ПО и как это сделать?

— Вносить не обязательно, такого требования нет. Но чтобы получить господдержку, налоговые льготы — это нужно. Поэтому зачастую программы вносят в реестр с целью их выгоднее использовать, получить льготы для сотрудников и организации. Процедура кажется простой: подаёшь заявление, прикладываешь документы. Но есть условия: к примеру, в программе нельзя использовать западные платные источники, только открытое программное обеспечение. Также юристы рекомендуют сначала получить в Роспатенте свидетельство о том, что именно за тобой закреплено право на эту программу, а потом идти в реестр отечественного ПО.

Работодатель vs сотрудник: как не потерять права на продукт

Какие нюансы должен учесть работодатель, поручая сотруднику создать продукт? Нужно заключить договор о передаче авторских прав?

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

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

Зачем так сложно?

— С работниками нужно регулировать эти правоотношения, чтобы у работодателя было доказательство, что конкретно эту программу он получил и оплатил по договору. Кажется, что произведение, которое работник создал по заданию, по умолчанию должно принадлежать компании, но он же может его создать дома и потом говорить, что конкретно эту программу он не делал в рамках рабочих процессов.

Если это отдельный модуль или решение, которое сотрудник создал, а работодатель не зафиксировал, что работник сделал это именно в рамках должностных обязанностей, то существует риск утратить права на произведение. Такие споры в юридической практике существуют. Особенно в случаях, когда сотрудник потом уходит работать с этим модулем на себя или «относит» его другому работодателю.

К примеру, в деле N А40-202764/2018, по спору о правах на медицинский мессенджер Medsenger(спор между «Амедико» и «ТелеПат»), работодатель не смог доказать, что ему принадлежат права на программу. Суть в том, что айтишники, которые ранее работали у истца, уволились, создали собственное юрлицо и стали продавать программу, которую разработали на прежнем рабочем месте. Соответственно, бывший работодатель предполагал, что программа принадлежит ему, но доказать это не смог, хотя было понятно, что сотрудники создавали наработки на прошлом рабочем месте. Трудовой договор, который он предоставил как доказательство, оказался недостаточным аргументом в пользу работодателя, поскольку не было документов, которые подтверждали бы наличие служебного задания и доказывали бы факт создания программы в определенный период времени. Не было и актов приемки-передачи служебного произведения.

Фактически суд установил только то, что программа принадлежит самим сотрудникам, в том числе еще и потому, что они обратились в Роспатент и зарегистрировали это право.

Как нанимателю защитить себя заранее, как проверить, по каким договорам ранее работал исполнитель?

— С юридической стороны — никак, на 100% у него не получится защититься, здесь скорее вопрос того, насколько честен сотрудник. Вероятно, у нового работодателя не будет проблем, если его цель найма — создать собственный продукт, по своему уникальному заданию, а не повторить чужой. А вот если цель изначально недобросовестная и работодатель хотел схантить вместе с сотрудником часть программы, тогда надо быть готовым к претензиям и защите в суде.

Что делать, если права нарушили?

— Если нарушили твои исключительные права на произведение, то основной гражданско-правовой способ защиты — взыскать компенсацию в суде. По таким искам можно получить от 10 тыс. до 5 млн руб. А со следующего года — до 10 млн руб. Есть и другие способы расчёта — к примеру, двойная стоимость лицензии. То есть, если ты реализуешь лицензию на свою программу, а кто-то незаконно её использует, можешь отсудить у него двойную стоимость лицензии. Такой способ в основном используют в судах. Но можно разрешить спор и досудебно — подать претензию. Иногда на претензиях всё и заканчивается. Но если в претензионном порядке нарушитель не выплатит денежную компенсацию, то нужно будет обращаться в суд.

Помимо этого, есть административная и уголовная ответственность, в зависимости от того, какого объёма нарушения. То есть можно обратиться к правоохранительным органам, и они будут защищать права автора или обладателя исключительных прав.

Как разработчику и заказчику делиться правами?

— Когда разработчик выполняет заказ в частном порядке, прежде чем создавать произведение, ему необходимо урегулировать правоотношения с заказчиком по договору. В нём чётко прописать, кому будет принадлежать исключительное право и каким образом вторая сторона сможет использовать произведение — например, по лицензии. На практике бывает так, что исключительное право сохраняют за разработчиком, а заказчику передают только лицензию, потому что разработчик будет адаптировать свою же наработку под другие компании. То есть, если он хочет использовать свою наработку, блок, ядро программы в дальнейшем, то он не должен отдавать исключительное право заказчику.

Или он может отдать ядро, но тогда это будут совсем другие деньги. В этом случае необходимо сохранить за собой право использовать ядро для создания программ в дальнейшем. Это непростой вопрос, и чтобы оформить такие отношения с заказчиком, нужен юрист, потому что типовые договоры здесь не подходят, они редко решают эту задачу как нужно. В типовых договорах зачастую прописывают либо полное отчуждение прав, и вопрос лицензии практически не решают, либо наоборот, прописывают только лицензию, но неправильно определяют её объём. Поэтому важно скрупулёзно составлять индивидуальные договоры, учитывая все нюансы, которые устроят обе стороны.

Если проект финансирует инвестор, как ему вложить деньги и не остаться ни с чем?

— Инвесторам — сложнее всего. Естественно, соавторами они стать не могут, потому что соавтор — это тот, кто вместе с автором творческим трудом создал произведение, а не тот, кто профинансировал. Тем более, пока нет практики, когда исключительное право на программу или продукт принадлежит в долях. Соответственно, инвесторы не могут получить долю в непосредственном праве.

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

Особые случаи: работа с госзаказом и зарубежными клиентами

Если айтишник работает на оборонку, — там уже действуют другие договоры, другая ответственность?

— Там, безусловно, есть дополнительная ответственность за сохранение тайны разработки. В зависимости от того, что именно выполняет специалист, вероятно, там возникнет определённая степень допуска к гостайне. В остальном, скорее всего, действует такое же право, как на остальные разработки, с такими же ограничениями.

Какие договоры нужно заключать при работе с иностранными заказчиками? Есть ли особые условия ?

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

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

То есть знание наших законов не убережёт от проблем?

— Принципы взаимодействия похожи, но, например, в американской системе нет неимущественных прав, есть только имущественное право на произведение. А принципы отчуждения и лицензирования схожи с российскими, регулирование для разработчиков — тоже.

Юридический лайфхак: храните доказательства

Поделитесь кейсами из своей практики, когда приходилось разрешать спор между кодером и заказчиком.

— Был случай, когда кодер не смог подтвердить, что он что-то создавал, потому что не было задания. Это печальная история, потому что был договор — кодер проделал большую работу, но не получил за неё деньги и права на свой продукт. Он передал наработки и не подписал документы в надежде на порядочность заказчика, который в итоге не заплатил, сказав, что исполнитель ничего не сделал. Через суд истребовать ничего не удалось, потому что все данные удалили, у кодера не было доступа к своей разработке, чтобы доказать, что он её создал и передал. Причём backup-версия наработки у него осталась, но мы не нашли способ доказать, что он её передал, так как никто не вёл соответствующие документы.

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

Можно сделать простой вывод: фиксируйте задание и результат любым способом (например, в CRM, задачах). Сохраняйте все переписки и готовые продукты в облаке с историей изменений. Технологичные способы подтверждения надёжнее бюрократии, но и договор должен соответствовать тому, что происходит в жизни.

Потому что SQL, несмотря на свое превосходство в работе с данными, неудобен, ограничен и рискован в роли полноценного языка программирования.

Логика не по адресу

Как отмечает Эвальд Бенс, фуллстек разработчик и авторов популярного блога об IT, он предпочитает держать как можно больше логики в приложении, а не в SQL-хранилищах, представлениях и процедурах:

Я отношусь к базе как к тупому хранилищу данных. Вся логика — в коде. SQL просто не предназначен для сложных сценариев.

И дело не в том, что SQL чего-то «не умеет». Умеет — особенно с расширениями вроде PL/pgSQL или Oracle PL/SQL.

Но выразительность этих языков — далека от Python, TypeScript, Rust или C#, особенно когда речь идет о бизнес-логике, объектной модели или сложных расчетах.

Зачем выносить логику из базы?

1. SQL невыразителен

Для манипуляций с табличками и JOIN — он король. Но как только начинается рекурсия, классы, вложенные состояния или обработка ошибок — SQL превращается в монстра с BEGIN, IF, LOOP, EXCEPTION, RAISE, CURSOR, FETCH, WHILE и т.д...

2. Развертывание — боль

Обновить приложение можно за минуту, откатить — за две. А вот миграции на проде — это:

• повышенные права доступа;
• согласование с DBA;
• боязнь сломать что-то «наживую»;
• ручной откат схем.

3. Лочит на вендора

Логика, написанная на PL/SQL — это билет в один конец к Oracle. Переезд на PostgreSQL или SQL Server становится в 5 раз сложнее.

4. Меньше инструментов

Вокруг SQL есть утилиты, но полноценной среды с юнит-тестами, статическим анализом, форматтерами, профайлерами, линтерами и отладчиками — почти нет.

А что с производительностью?

Да, есть нюанс: иногда лучше обработать данные прямо в базе, чтобы не гонять десятки тысяч строк по сети. Это особенно актуально, если не хочется получить классическую проблему N+1-запросов.

Но даже в этом случае большинство специалистов советует сначала делать «просто и понятно», а не «оптимально заранее». До тех пор, пока не уперлись в реальные метрики, выносить логику в базу — преждевременная оптимизация.

Что делать?

Подход «база — хранилище, логика — в коде» стал де-факто стандартом во многих командах. Но это не догма:

• Для отчетности или простых ETL сценариев логика в SQL может быть уместной.
• Для монолитных решений без CI/CD и DevOps — процедурный SQL вполне оправдан.
• Но в современной разработке с частыми релизами, микросервисами и отказоустойчивостью бизнес-логика в приложении — просто удобнее и безопаснее.

Я всё думаю над тем, о чём говорить на своём канале. Казалось бы, инфы в интернете — вагон и маленькая тележка: бери, читай, вдохновляйся. Но вот что удивительно — про то, как тестировать данные, как они перетекают из одной таблицы в другую и не превращаются в тыкву, пишут мало.

А зря.

За свою практику я встречала разные подходы к организации Data QA. В этой статье я расскажу про самый простой и быстрый вариант, который можно «собрать на коленке», а потом уже развивать. С примерами кода и тем, зачем SQL нам нужен в этой жизни.

И небольшой дисклеймер. Если вы знаете, как сделать это на Python стильно модно молодежно, обязательно напишите мне об этом в комментариях, я с удовольствием почитаю про ваш подход.

Также подписывайтесь на мой ТГ, который я почти не веду.

Базовый сценарий

1. Есть таблица-источник source_table.
2. Разработчик запускает свой код (Spark, Airflow или что у него там), и данные магическим образом перекладываются + преобразуются.
3. На выходе получаем result_table.

Вопрос: как это тестировать?

Самый быстрый и простой путь

Подготовка:

1. Создаём таблицу-источник.
2. Наполняем её данными (синтетика или реальные примеры с прода).

Действие:

1. Запускаем ETL код.
2. Сравниваем данные «как было» и «как стало».

После теста:

1. Удаляем таблицу-источник.
2. Удаляем таблицу-приёмник.

На коленке это можно собрать так:

1. CREATE TABLE …
2. INSERT INTO …
3. Ручной запуск пайплайна (Spark/Airflow).
4. Какой-нибудь скрипт для сравнения результатов.

Рабочая схема? Да.

Удобная? Нет.

Где хранить эти скрипты?

Можно, конечно, прилепить их к задаче в Jira в виде файликов. Но выглядеть это будет как «фигня на палке». Через месяц никто не вспомнит, что это было и зачем.

Поэтому я решила собрать свой Python-проект для автоматизации. А вы можете склепать себе такой же, и жизнь сразу станет легче.

Архитектура проекта

Минимальный стек

1. Utils — мелкие, но полезные

Здесь мы храним всякую мелочёвку. Например, функцию для открытия JSON:

Важно отметить, что данные я всегда стараюсь хранить в виде массива с json. Так удобнее использовать.

2. APIClient — для триггеров

Здесь всё максимально тривиально: клиент для вызова API и запуска ETL джоб.

3. PostgreSQLClient — основной игрок

Класс для подключения, запросов, создания таблиц, вставки данных и удаления.

Фикстуры (conftest.py)

API фикстуры

Я показываю пример, как поднимаю один API клиент. Но у вас их может быть много: например, разные сервисы или разные перекладчики.

DB фикстура

Пример для дефолтной PostgreSQL, но вы можете добавить фикстуры для поднятия GreenPlum или ClickHouse.

Как хранить данные?

А теперь самый сок, которым я обмазываюсь сейчас.

Конечно, можно создать отдельный скрипт на чистом sql для создания и редактирования своих табличек: больших и маленьких. Но, если честно, это так *цензура* неудобно.

Поэтому я придумала хранить схему и данные в отдельных json файлах и налету генерить скрипты. Да, Америку я вновь не открываю, и очень жаль.

В директории тестов я создала папку resources, где храню эти файлы.

Конечно, в таком виде вы не передадите ничего в Postgres и ничего не слепите. Так что я услужливо предоставляю вам код, чтобы вы его копировали и вдохновлялись.

Вы можете взять и пропихнуть эти куски кода прямо в тело теста, но я предпочитаю оборачивать это дело в фикстуры-управленцы, которые будут делать это за меня и записывать отдельными шагами в Алюр:

Отдельное удовольствие мне даёт вот эта строчка кода db_client:PostgreSQLClient.Она значит, что если так вышло, что у меня есть куча разных PostgesSql, я могу в эту фикстуру прокинуть нужный мне клиент без дополнительных приседаний. И это, конечно, прекрасно.

Пример: подготовка данных

Самые внимательные уже заметили, что в примере выше я поднимала postgres-клиента.

Так что разницы почти никакой (ну, кроме тех случаев, когда внезапно очень даже есть 🙃).

И сам тест

Конечно, можно сравнивать всё это дело через всякие прослойки типа Pandas.

Но, камон, у меня что, куча времени сидеть, читать доки и писать суперсложные датафреймы ради пары простых проверок? Нет.

Позвольте мне радостно строчить свой первозданный код с дефолтными проверками и быть довольной этим минимализмом.

Это я отвлеклась. Вот такой код у меня получается. Я не очень люблю сверять даты и названия таблиц, у меня генерит тест на лету:

Итог

• Ручные скрипты → боль и страдания.
• Автоматизация через Python+pytest → быстро, удобно, воспроизводимо.
• JSON-файлы позволяют хранить схемы и данные в читаемом виде.
• Allure даёт красивые отчёты.

В итоге у вас появляется настоящий фреймворк для Data QA, который легко расширять и масштабировать.

Разработчики на передовой всё реже запускают новые сервисы на «тяжёлой в эксплуатации» связке сервисов Hadoop и предпочитают формат «всё в одном» — унифицированный подход, объединяющий хранение и аналитику. Если раньше архитектуру больших данных приходилось «собирать из кубиков», то теперь она всё чаще становится более монолитной архитектурой (all‑in‑one).

Кроме того, с быстрым развитием ИИ изменились и объёмы, и типы данных, поэтому на стороне вычислительных движков были проведены соответствующие оптимизации и обновления: например, для OLAP‑аналитики векторизация де‑факто стала стандартной возможностью, а форматы озёр данных эволюционируют к поддержке мультимодальности (о мультимодальном хранении — ниже).

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

Реализации распределённых вычислительных движков обычно состоят из компонентов «Server» и «Worker». Узлы Worker, как правило, распределяются по множеству хостов и под координацией Server выполняют параллельные вычисления. Хотя логика вычислений и оптимизации у разных движков реализована по‑разному, базовые этапы похожи.

Базовые этапы выполнения запроса

1. Parsing — разбор: SQL‑запрос разбирается в синтаксическое дерево для валидации структуры и выявления задействованных таблиц.
2. Planning — планирование: формируется логический план, описывающий необходимые операции (например, фильтры, соединения) и их порядок.
3. Optimization — оптимизация: логический план преобразуется в эффективный физический план с помощью стоимостной (CBO) или правил‑ориентированной оптимизации.
4. Compilation — компиляция: физический план компилируется в низкоуровневые операции, байт‑код или аппаратно‑специфичные инструкции, подготавливаясь к исполнению.
5. Execution — исполнение: план распределяется узлам Worker, которые параллельно сканируют данные, применяют преобразования и обмениваются данными; промежуточные данные/метаданные возвращаются в главный процесс.
6. Result Serving — формирование и отдача результатов: результаты агрегируются, форматируются и возвращаются пользователю или нижестоящим системам (downstream).

Классификация движков по назначению

• Универсальные вычислительные движки: например, Spark, Flink, MR (MapReduce), поддерживающие пакетные и сложные вычислительные задачи, различные типы данных и множество источников.
• Интерактивные движки запросов: например, Presto, Trino — для ad hoc‑запросов, где важно быстро получать результаты и применять оптимизации, обеспечивая высокую скорость выполнения и интерактивность анализа.
• OLAP‑движки: например, ClickHouse, StarRocks, Doris и др. — для быстрого анализа постоянно меняющихся данных. Поддерживают аналитику в реальном времени, субсекундную латентность запросов и серьёзные оптимизации в оптимизаторе выполнения.

Универсальные вычислительные движки

Среди универсальных движков наиболее широко используется Apache Spark: он поддерживает офлайн‑вычисления, обработку, близкую к реальному времени (near real time), и интеграцию с фреймворками машинного обучения. Spark изначально создавался для преодоления ограничений Hadoop MapReduce. Spark Driver — центральный координатор Spark‑приложения: он управляет использованием CPU и памяти, широковещательными переменными (broadcast variables, для эффективного совместного использования данных между узлами Worker) и создаёт наборы данных RDD.

Ниже — схема архитектуры Apache Spark.

Интерактивные движки запросов

PrestoDB был создан в 2012 году в Facebook (Meta)* для предоставления быстрых распределённых возможностей SQL поверх различных источников (включая HDFS, S3, MySQL и Cassandra) без перемещения или преобразования данных. Trino появился в 2019 году как форк Presto, созданный его оригинальными авторами, с фокусом на улучшении производительности и добавлении поддержки облачных и современных Lakehouse‑архитектур. Эти движки остаются очень похожими и после форка различаются лишь в деталях.

*Компания Meta признана экстремистской на территории РФ и запрещена

На следующей схеме показана архитектура Presto/Trino. В Presto и Trino координатор парсит и планирует запрос, затем создаёт набор задач и сплитов (splits) базовых внешних хранилищ; каждый сплит передаётся рабочим узлам для чтения соответствующих данных.

OLAP‑движки для работы в реальном времени

StarRocks — высокопроизводительное аналитическое хранилище данных (DWH), реализующее многомерную аналитику, аналитику в реальном времени и высокую конкурентность за счёт векторизации, MPP‑архитектуры, CBO, умных материализованных представлений и колоночного движка с возможностью оперативных обновлений.

Архитектура StarRocks поддерживает две модели: Shared‑nothing и Shared‑Data. В Shared‑nothing данные загружаются в формат StarRocks и хранятся непосредственно в локальном хранилище узлов StarRocks Backend. Shared‑Data позволяет напрямую запрашивать внешние источники данных без копирования их в кластер StarRocks — аналогично Presto/Trino/Spark.

Используются два типа узлов: Frontend (FE) и Backend (BE)/Compute (CN). Узлы FE отвечают за управление метаданными и построение плана выполнения. Узлы BE исполняют план и хранят данные, ускоряя запросы за счёт локального хранения и обеспечивая высокую доступность посредством репликации. В конфигурации с общими данными (Shared‑Data) вместо BE используются вычислительные узлы (CN), которые выполняют те же функции, но не хранят данные.

ClickHouse был разработан в 2009 году, изначально для сервиса Yandex.Metrica — высоконагруженной веб‑аналитической платформы, обрабатывающей миллиарды событий в день с низкой задержкой. Существующие базы данных не справлялись с таким масштабом для аналитики в реальном времени с высокой конкурентностью, особенно на сложных фильтрах, агрегациях и соединениях. В ответ появился ClickHouse — быстрая OLAP‑СУБД для решения этих задач.

Архитектура ClickHouse использует колоночное хранение; операции выполняются над векторами (колоночными блоками), а данные векторов размещаются в реплицируемых шардах ClickHouse, что обеспечивает быстрое выполнение запросов и отказоустойчивость. Кроме того, ClickHouse позволяет запрашивать данные из облачных хранилищ, аналогично внешним таблицам в традиционных DWH.

Каждый распределённый исполнительный движок имеет свои сильные стороны: хотя почти все исполняют один и тот же SQL, детали реализации заметно различаются — исполнительные подсистемы, подходы к оптимизациям, обработка shuffle, кэширование, уровни векторизации и т. п.

В сводной таблице ниже (по мотивам сравнения на сайте Onehouse и описанных в тексте критериев) каждому движку присваивается оценка: A = лучший вариант; B = хороший вариант; C = ниже среднего. Каждой оценке соответствует балл: A = 3, B = 2, C = 1. metascore — нормализованная сумма баллов по всем категориям.

Сводная таблица сравнения (оценки A/B/C и metascore)

Примечания:

• A = 3 балла, B = 2 балла, C = 1 балл.
• metascore рассчитан как сумма баллов по 5 категориям, нормализованная к максимуму 15 (деление на 15 и умножение на 100%).
• Таблица отражает выводы текста: «лучший/худший» в классе по каждой категории и качественные комментарии по архитектуре.

Рейтинг по metascore

1. StarRocks — 73%
2. ClickHouse — 73%
3. Presto — 67%
4. Apache Spark — 60%
5. Trino — 60%

Сравнение по ключевым критериям

Скорость выполнения. Одним из ключевых критериев качества вычислительного движка выступает время ответа на запрос; также важны пропускная способность, отказоустойчивость и ресурсоёмкость.

Оптимизации на базе SIMD (Single Instruction, Multiple Data), позволяющие одной инструкции CPU обрабатывать сразу несколько элементов данных, дают заметное преимущество над поэлементной обработкой.

— 🏆 Лучший в классе: StarRocks, ClickHouse

— ❌ Худший в классе: Spark

Масштабируемость. Способность масштабировать кластер вверх/вниз на старте и по завершении запроса — важная составляющая отличной производительности и оптимизации затрат. Архитектуры с разделением хранения и вычислений упрощают масштабирование. Presto обеспечивает наиболее простую операционную модель на больших масштабах. Локальное хранение у StarRocks/ClickHouse усложняет масштабирование. Spark чаще используется для крупномасштабных ETL‑заданий и менее удобен для эластики интерактивных нагрузок.

— 🏆 Лучший в классе: Presto

— ❌ Худший в классе: Apache Spark

Конкурентное чтение/запись. Нужна эффективная обработка больших объёмов одновременных запросов с приоритизацией, чтобы важные запросы не блокировались. ClickHouse предоставляет самый тонкий и гибкий контроль над исполнением запросов. В отношении транзакций большинство движков ориентированы на OLAP и уступают типичным OLTP/онлайн‑БД.

— 🏆 Лучший в классе: ClickHouse

— ❌ Худший в классе: Apache Spark

Поддержка хранения. В эпоху открытых табличных форматов (Data Lake) по стратегии Lakehouse важно уметь читать/писать множество форматов. Spark поддерживает самый широкий спектр: через источники данных — Parquet, JSON, ORC, Avro, CSV и др.

— 🏆 Лучший в классе: Apache Spark

— ❌ Худший в классе: ClickHouse

Поддержка языков запросов. В эпоху ИИ и аналитики главные способы работы — SQL и Python. Apache Spark с PySpark обеспечивает лучший опыт работы с Python и позволяет выражать бизнес‑логику в Python‑функциях; другие движки обычно требуют определять логику на SQL через клиентские обёртки. Spark можно бесшовно использовать как Python‑библиотеку и как распределённый SQL‑движок.

— 🏆 Лучший в классе: Apache Spark

— ❌ Худший в классе: Trino, Presto

Выводы

Выбор оптимального движка для решения бизнес‑задач не ограничивается желаемыми техническими целями — он должен учитывать будущие потребности бизнеса и направление эволюции архитектуры.

Каждый движок имеет свои сильные стороны:

1. Apache Spark обладает самой широкой поддержкой хранилищ и языков; он может подключаться к практически любым типам данных и работать с ними.
2. Trino — отличный интерактивный SQL‑движок для ad hoc‑аналитики.
3. Presto имеет общую историю с Trino, предоставляет превосходный интерактивный SQL и эффективно масштабируется.
4. StarRocks предлагает сверхбыстрый векторизованный движок, но поддержка форматов файлов у него не так широка.
5. ClickHouse также даёт сверхбыстрый векторизованный движок для ускорения OLAP, но ему не хватает эластичности масштабирования.

Независимо от выбора движка, настоящая сила — в умении комбинировать движки, масштабировать их и интегрировать с другими компонентами экосистемы под задачи бизнеса, не заковываясь в единственную архитектурную парадигму.

Bank of Hangzhou Consumer Finance — лицензированная организация потребительского финансирования. Столкнувшись с вызовами, связанными с быстрым ростом бизнеса, компания начала трансформацию своей инфраструктуры данных, кульминацией которой стало создание платформы GLH Lakehouse на базе Mirrorship.

Платформа GLH представляет собой результат исследований и практического внедрения архитектуры Lakehouse, служа критически важным мостом, соединяющим бизнес-операции с передовыми технологиями.

I.Предпосылки создания платформы GLH: Инновации, продиктованные «болевыми точками» в данных

1. Требования бизнес-сценариев

Как организация, чья деятельность основана на «данных, сценариях, управлении рисками и технологиях», мы столкнулись с тем, что традиционная архитектура обработки данных больше не могла справляться с растущими потребностями. Эти потребности влияли не только на повседневные операции, но и на стратегические решения и соблюдение нормативных требований.

• Актуальность данных для стратегий: стратегии управления финансовыми рисками требуют своевременных данных для принятия решений. Задержка даже в несколько минут может привести к сбою в контроле рисков.
• Консистентность данных между таблицами: синхронизация данных между различными базами и таблицами должна поддерживать консистентность на определённый момент времени. Любое расхождение могло нарушить бизнес-логику.
• Точность бизнес-данных: ежедневные отчёты для руководства должны быть точными и своевременными, так как они напрямую влияют на стратегическое направление компании.
• Потребности в сверке данных: внутридневные данные необходимы для процессов сверки, и традиционные ETL-процессы не могли обеспечить требуемую оперативность.
• Соблюдение нормативных требований: данные, предоставляемые регуляторам, должны соответствовать строгим стандартам своевременности и точности.

2. Анализ ключевых «болевых точек»

При использовании традиционной архитектуры данных компания столкнулась с несколькими критическими проблемами:

Проблема 1: Сложность отслеживания данных (Data Traceability)

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

Проблема 2: Отсутствие детализированных записей об изменениях

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

Проблема 3: Неточность данных на определённый момент времени (Point-in-Time Data)

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

Проблема 4: Проблемы с ежедневным закрытием операционного дня (Daily Cut-off)

В сценариях сверки транзакций по погашению платежей разные системы (например, транзакционная и бухгалтерская) обрабатывали одну и ту же операцию в разное время. Это приводило к серьёзным неточностям в данных к концу дня, что напрямую влияло на сверку.

Эти «болевые точки» были не просто техническими трудностями — они создавали прямую угрозу для развития бизнеса. Невозможность синхронизировать данные в реальном времени снижала эффективность бизнес-стратегий, несогласованность данных затрудняла сверку, низкое качество данных создавало риски для комплаенса, а сложность отслеживания делала аудиты долгими и дорогостоящими.

II. Построение архитектуры Lakehouse с помощью Mirrorship

1. Техническая архитектура платформы GLH

Платформа GLH была спроектирована с использованием четырехуровневой архитектуры:

• Уровень приложений (Application Layer): включает узел управления (Manager Node), узлы выполнения (Execute Nodes), кастомные плагины и узел оповещений (Alerting Node).
• Уровень технических компонентов (Technical Component Layer): использует экосистему Spring Framework, MyBatis, собственный RPC-фреймворк, Log4j и др.
• Уровень промежуточного ПО (Middleware Layer): задействует ZooKeeper, Kafka и MySQL.
• Уровень эксплуатации (DevOps Layer): основан на Git, Jenkins, Docker & Kubernetes, Maven.

Эта архитектура не только отвечала функциональным требованиям, но и обеспечивала стабильность, масштабируемость и удобство сопровождения системы, заложив прочный фундамент для платформы Lakehouse.

2. Почему для замены GreenPlum выбрали Mirrorship?

Выбор хранилища данных был критически важным решением. После всесторонней оценки и тестирования команда выбрала Mirrorship (корпоративную версию StarRocks) в качестве основного движка для хранения и аналитики.

Выбор было продиктован насущными проблемами — производительность существующего 26-узлового кластера GreenPlum снижалась по мере роста объёма бизнеса, а расширение требовало значительных инвестиций.

• Снижение затрат и повышение эффективности: лицензионные платежи и стоимость горизонтального масштабирования GreenPlum были высокими. Mirrorship предложила более экономически эффективное решение, соответствующее стратегической цели компании.
• Возможности ingest-а данных в реальном времени: в отличие от традиционных инструментов, таких как Hive, Mirrorship поддерживает real-time ingest и транзакционные запросы, что дает ей естественное преимущество в сценариях с данными реального времени.
• Единая платформа данных: данные были разбросаны по разным системам, создавая «острова данных». Mirrorship предоставила единую платформу для хранения и вычислений, консолидировав данные и упростив доступ к ним.
• Дизайн архитектуры Lakehouse на базе Mirrorship

В новой архитектуре платформа GLH глубоко интегрирована с Mirrorship для создания истинной Lakehouse.

• Архитектура с разделением хранения и вычислений (Shared-Storage): в качестве базового хранилища используется HDFS (с планами миграции на S3), что обеспечивает гибкость для управления ростом данных при контроле затрат и сохранении производительности.
• Использование нескольких моделей таблиц: используя возможности Mirrorship для работы с детализированными (Detail tables) и широкими таблицами (Wide tables), команда разработала кастомные структуры таблиц, поддерживающие анализ временных рядов и отслеживание данных для различных бизнес-задач.
• Унифицированная обработка данных: придерживаясь принципа «сбор один раз, обработка многократно», все данные управляются через единый конвейер обработки. Это позволило избежать дублирования разработки, значительно повысив эффективность и консистентность данных.
• Гибкое распределение данных: платформа поддерживает распределение данных в другие системы через Kafka, что обеспечивает работу сценариев, таких как Flink CDC, и создает открытую, гибкую экосистему.

III. Результаты: баланс между производительностью и экономической эффективностью

В ходе внедрения команда накопила ценный опыт:

• Оптимизировали время пакетной обработки: команда применила дифференцированную стратегию синхронизации данных, настраивая интервалы в зависимости от бизнес-потребностей — от 5 секунд для одних таблиц до нескольких минут для других.
• Оптимизировали партиционирование и бакетирование: анализ бизнес-характеристик позволил переработать стратегию партиционирования, чтобы уменьшить накладные расходы на уплотнение (compaction) мелких файлов, что привело к значительному повышению производительности.
• Рационально распределили ресурсы: оптимизировано соотношение ресурсов между вычислительными узлами и узлами хранения. Мониторинг показал, что кластер стабильно работает с загрузкой ЦП ниже 50%, легко справляясь с пиковыми нагрузками.

Бизнес-результаты

Платформа GLH достигла впечатляющих результатов:

• Полный охват данных: более 3800 таблиц из всех бизнес-систем компании подключены к real-time потоку данных.
• Синхронизация на минутном уровне: время от генерации данных до их доступности сократилось до минут, что многократно повысило скорость реакции бизнеса по сравнению с традиционной моделью T+1.
• Увеличение мощности пакетной обработки: платформа обрабатывает более 6500 заданий в день, включая более 800 задач для хранилища данных, со значительным ростом эффективности.
• Углубление интеграции с бизнесом: снято ограничение на выполнение только пакетных запросов, благодаря открытию real-time query API, что позволило бизнес-системам напрямую получать доступ к актуальным данным.

Эти достижения — не просто цифры. Они трансформировались в ускоренную реакцию бизнеса и улучшенный клиентский опыт, внеся ощутимый вклад в повышение конкурентоспособности компании.

IV. Перспективы развития

Платформа GLH завершила разработку основного функционала. Будущее развитие будет сосредоточено на следующем:

1. Более открытые интерфейсы: поддержка интеграции с более широким спектром вычислительных и движков хранения.
2. Богатая экосистема плагинов: разработка большего количества плагинов для обработки данных.
3. Более глубокая интеграция с бизнес-процессами: дальнейшая интеграция с бизнес-системами для предоставления более точных данных.
4. Постоянное технологическое развитие: отслеживание развития технологий хранения с запланированной миграцией на объектное хранилище S3.

Владение Django — это старт, а не финиш. Чтобы оставаться востребованным, нужно постоянно расширять знания и навыки. В этой статье разберем пути и направления для улучшения своих компетенций.

Почему владение Django — не предел для разработчика

Особенности Django

Django используют для разработки веб-приложений разной сложности: при работе с большими базами данных, для создания сервисов, способных обслуживать большое количество пользователей. На нём создают соцсети, новостные сайты, веб-версии приложений, онлайн-магазины.

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

Задача — создавать продукт, который будет нужен конечному потребителю.

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

Flask — минималистичный микрофреймворк, даёт полную свободу в выборе компонентов. Используют для небольших приложений и микросервисов.

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

Можно пойти по пути расширения компетенций за пределы основной специализации. Важно не только уметь писать код, но и понимать, как приложения разворачиваются и работают в продакшене. Знание DevOps-практик помогает наладить эффективное взаимодействие между разработкой и эксплуатацией.

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

Python часто используется для автоматизации рутинных задач: парсинга данных, обработки файлов, интеграции систем, генерации отчетов. Создание скриптов для автоматизации бизнес-процессов помогает повысить эффективность работы и снизить количество ошибок.

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

Хотя сейчас популярность уходит к вебу и мобильным платформам, десктопные приложения на Python востребованы в таких сферах: инструменты для анализа, редакторы, утилиты.

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

Например, с помощью Python на Raspberry Pi можно разрабатывать датчики для мониторинга состояния оборудования на производстве и разрабатывать прототипы носимых устройств для сбора данных о здоровье.

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

Всем привет! Я Павел, системный аналитик. Хочу поделиться с вами своим опытом и опытом своих коллег, как мы в нашей компании «Аксеникс Инновации» упростили свою работу с брокерами сообщений и REST-запросами.

Работа с брокерами сообщений, HTTP-сервисами и СУБД часто требует множества рутинных действий: отправки тестовых сообщений, создания шаблонов, настройки интеграций между сервисами, написания скриптов для нагрузочного тестирования. Иногда это занимает больше времени, чем сама разработка.

Для решения данной проблемы, мы разработали BrOk.

BrOk — это графический low-code инструмент, который помогает разработчикам, тестировщикам и системным администраторам (и не только им =) ) работать с брокерами сообщений, базами данных и веб-сервисами через удобный интерфейс. Он позволяет создавать сложные интеграционные процессы, запускать их по расписанию, отлаживать и сохранять шаблоны — всё это без необходимости писать десятки строк кода.

Если вы работаете с Apache Kafka, RabbitMQ, ActiveMQ Artemis, Redis, NATS, ETCD, REST API или СУБД, то BrOk может стать вашим единым “командным пунктом” для управления этими системами.

Сразу хочу предупредить, что BrOk можно бесплатно скачать тут и во время прочтения статьи самостоятельно просматривать функционал.

Читать всего совсем не нужно, читать нужно только то, что отвечает на возникшие в душе вопросы.

Основные функции и возможности BrOk

1. Поддержка множества брокеров сообщений

Первая и главная возможность BrOk — это поддержка работы с популярными брокерами сообщений:

• Apache Kafka
• RabbitMQ
• Apache ActiveMQ Artemis
• Redis
• NATS

Вот так выглядит экранная форма для подключения брокеров.

Пример создания подключения к брокеру Apache Kafka.

Создав подключение, вы можете посмотреть топики.

Так же вы можете создать топик, очистить в нем сообщения, удалить топик или отправить в него сообщение.

Теперь давайте перейдем в один из топиков. В нем вы можете смотреть и отправлять сообщения.

Преимущество 1

В BrOk есть продвинутые фильтры для поиска сообщений в Kafka, Artemis, Rabbit MQ.

Преимущество 2

Не надо постоянно с нуля создавать сообщения, так как можно создать шаблон и использовать его для быстрого создания сообщений.

На картинке ниже представлен список моих шаблонов для топика.

Рассмотрим форму для отправки сообщения в топик.

Вы можете нажать на кнопку “Шаблоны” и выбрать нужный из списка. После этого он автоматически подставится в соответствующие поля сообщения.

Преимущество 3

Для создания большого количества тестовых сообщений можно использовать в шаблоне параметры. При отправке сообщения параметр заменяется на значение, зависящее от его типа.

BrOk поддерживает множество различных типов параметров: от случайных строк и UUID до дат и т. д. Также он работает со словарями, из которых подставляет нужные значения.

Преимущество 4

При отправке сообщения можно указать, сколько раз его нужно отправить. Для этого надо заполнить поле “Количество повторений”.

Мини-вывод о преимуществах

Одна из рутинных задач при тестировании — повторная отправка однотипных сообщений. BrOk решает эту проблему за счёт сочетания упомянутых преимуществ, которые позволяют быстро создавать множество уникальных сообщений для разных брокеров. Это особенно полезно при тестировании.

2. Работа с HTTP(s) запросами

В BrOk вы можете использовать HTTP(s)-запросы: GET, POST, PUT и другие методы. Кроме того, доступна работа с заголовками, авторизацией и телом запроса.

Во время своей работы я часто использую возможность экспортировать или импортировать коллекцию в BrOk в формате “Postman” или “OpenApi”.

Данная возможность позволяет загрузить спецификацию из Swagger в BrOk или наоборот. Поэтому не обязательно делать всё в Swagger. Можно сначала создать коллекцию в BrOk, потестировать её, а потом экспортировать в формате OpenApi.

3. Визуальный конструктор сценариев

Одним из ключевых преимуществ BrOk является его low-code конструктор сценариев , который позволяет строить сложные процессы взаимодействия между сервисами через удобный графический интерфейс.

Сценарии в BrOk — это не просто набор команд. Это полноценные процессы, которые могут включать отправку сообщений в брокеры сообщений, выполнение SQL-запросов к БД, REST-вызовы, паузы, обработку ошибок, запуск Groovy-скриптов и даже вызов другого сценария из основного сценария. Всё это можно собрать как конструктор, перетаскивая блоки (таски) и соединяя их линиями.

Пример использования

Представьте, что вам нужно протестировать интеграцию между микросервисами через Kafka и PostgreSQL.

Вы создаете сценарий, в котором:

• Таска “Отправка сообщения” для отправки тестового сообщения в Kafka.

• Таска “Слушатель” для ожидания ответа от другого сервиса.

• Таска “SQL” для записи результата в БД через SQL-запрос.

• Таска “REST” для отправки запроса, если возникнет ошибка.

Сценарий действий:

• Отправка тестового сообщения в Kafka.

• Ожидание ответа от другого сервиса с помощью таски “Слушатель”.

• Запись результата в БД через SQL-запрос.

• Если произошла ошибка — отправляется уведомление по REST API.

• Сохраняете этот сценарий и настраиваете его запуск раз в час.

Такой подход позволяет полностью автоматизировать тестирование.

Заключение

BrOk — это больше, чем ещё один GUI для работы с брокерами. Это полноценное приложение, которое объединяет разрозненные технологии в единый, логичный и удобный интерфейс. Неважно, работаете ли вы с Kafka, RabbitMQ, Artemis, Redis или NATS — с помощью BrOk вы получаете не только доступ к сообщениям, но и мощный low-code конструктор сценариев, систему шаблонов и универсальный клиент для REST.

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

Попробуйте BrOk. Возможно, он именно то, что вам нужно.

Официальная страница: https://axenix-innovation.pro/brok/

Скачать и начать использовать можно уже сейчас!

Если у вас есть вопросы, пишите в комментариях или скачайте BrOk. Там вы найдете форму обратной связи, где можно задать свой вопрос или написать предложение по улучшению.

Чтобы открыть форму обратной связи, нажмите на иконку выпадающего списка, которая находится в правом верхнем углу приложения.

Спасибо, что прочитали статью до конца!

Классические ошибки повторяются с завидным постоянством. В недавнем выпуске подкаста «Техно.Логично» наши коллеги Владимир Герциков и Николай Волынкин как раз обсуждали типичные проблемы с базами данных — от выбора инструментов до падений в продакшне. Послушав коллег, мы решили не пересказывать их беседу целиком, а на основе их беседы сделать практический список вредных советов.

Получился антигайд: как гарантированно завалить базу данных — и что делать правильно. Если узнаете себя в этих советах, не расстраивайтесь. Через подобное проходят все. А если хотите услышать полную дискуссию о современных СУБД, инструментах и миграции на open source — послушайте оригинальный выпуск.

1. Временные файлы бесконечны — лейте терабайты джойнов

Берите две таблицы по миллиону записей каждая, смело делайте JOIN без WHERE, сортируйте результат — и удивляйтесь, почему закончилось место под временные данные.

Что происходит: PostgreSQL создает временные файлы в pg_tmp для обработки больших запросов. Когда места не хватает, падают конкретные запросы с ошибкой No space left on device, а не весь сервер. Особенно болезненно там, где несколько таких запросов запускаются параллельно — временное пространство переполняется быстрее, чем успевает сработать мониторинг.

Как делать правильно: Планируйте размер временных данных заранее. Добавляйте фильтры перед джойнами, разбивайте сложные запросы на этапы. Настройте temp_file_limit для ограничения временных файлов на запрос и мониторинг заполнения. Если ваш запрос генерирует терабайты промежуточных результатов, скорее всего, есть способ сделать это эффективнее.

2. Суперпользователь для всех задач — что может пойти не так

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

Реальная история: Разработчик развернул постгрес на виртуалке с дефолтными настройками — порт 5432 открыт, пользователь postgres/postgres с правами суперпользователя. Через семь (!) секунд в базу начали ломиться боты. Боты сканируют интернет на стандартные порты СУБД постоянно и превращают сервер в майнинг-ферму быстрее, чем вы успеете допить кофе. Диск переполнился от созданных таблиц, установились неизвестные расширения, начались HTTP-вызовы из базы наружу. Сервер превратился в часть ботнета.

И так все понятно, но еще раз напомним: Суперпользователь может подключить postgres_fdw, dblink и читать/писать любые базы кластера, создавая запросы, которые переполнят временное пространство за минуты. Неподписанные расширения могут содержать что угодно — от бэкдоров до майнеров. А если расширение вызовет segmentation fault, упадет вообще все.

Принцип минимальных прав: Создавайте отдельных пользователей с минимально необходимыми правами. Устанавливайте только официально поддерживаемые расширения. Закрывайте базу от внешнего доступа файрволом, настройте TLS для шифрования трафика, используйте fail2ban против брутфорса и уникальные пароли. Это кажется очевидным, но количество баз с дефолтными паролями в интернете говорит об обратном.

3. Держите транзакции открытыми — счетчик XID все стерпит

Открывайте длинные транзакции и держите их днями. Постгерс умный, сам разберется.

Что сломается: У PostgreSQL есть счетчик транзакций (XID), который может переполниться. Когда возраст транзакций становится критическим, сервер блокирует обычные подключения и пускает только суперпользователя для выполнения VACUUM FULL. Все приложения встают, начинается паника.

Как избежать: Настройте timeout для idle in transaction состояний. Разбивайте большие батчи на маленькие операции. Мониторьте возраст самых старых транзакций. И запомните: транзакция, которая висит неделю, — это не фича, это бомба замедленного действия.

4. На каждый SELECT — свой индекс

Создавайте индекс под каждый запрос. Чем больше индексов, тем быстрее будет работать.

Почему это убивает PostgreSQL: В отличие от других СУБД, PostgreSQL при UPDATE создает новую версию записи, а старую помечает как мертвую. Если у таблицы 30 индексов, каждый UPDATE генерирует 30 мертвых ссылок в индексах. VACUUM начинает работать постоянно, производительность рушится.

Правило 20/80: Покройте индексами 20% самых частых запросов, которые дают 80% нагрузки. Остальную аналитику выносите на реплику для чтения. Регулярно анализируйте статистику использования индексов — неиспользуемые безжалостно удаляйте .

5. Сайзинг не нужен

Ресурсы бесконечны. А DBA разберутся, как бэкапить ваши 100 терабайт.

Физические ограничения: Таблица в PostgreSQL не может быть больше 32 терабайт при дефолтном размере блока. Ограничение можно обойти партиционированием или пересборкой с увеличенным размером блока, но лучше планировать заранее.

Экономика: «Эта функция будет стоить как два сервера, потому что нам нужно оборудование для бэкапа 50-терабайтной базы». В этот момент «бизнес» делает большие глаза и внезапно появляется мотивация оптимизировать архитектуру.

Планирование: Считайте размер данных на год-два вперед. Внедряйте партиционирование с первого дня, если ожидаете рост. Архивируйте старые данные. Удалить лишнее проще, чем добыть дополнительные терабайты дискового пространства в пятницу вечером.

6. Пихайте СУБД в контейнеры

Kubernetes решает все проблемы! Поэтому переносим в контейнеры все, базы данных тоже. Если что-то работает на виртуалках, то в контейнерах точно будет работать лучше.

Проблемы слоеного пирога: Мы слышали, тебе нравится виртуализация, поэтому мы добавили виртуализацию в твою виртуализацию. В результате кратное усложнение отладки. Где тормозит база: железо, гипервизор, менеджер контейнеров?

Где контейнер оправдан? В CI/CD, локальной разработке, тестовых средах. В продакшне контейнеры тоже работают, если использовать Kubernetes-операторы (Patroni, CloudNativePG), правильно настроить Persistent Volumes и протестировать поведение при рестартах. База должна жить в памяти, прогревать кэши, работать стабильно. Но это требует серьезной экспертизы в Kubernetes и готовности разбираться с проблемами на стыке технологий. Если команда не готова изучать все тонкости — лучше не начинать.

Компромисс: Если выбираете контейнеры для продакшна, используйте StatefulSet, настройте правильные storage-классы и OOM-политики. Для stateless-сервисов контейнеры — отличный выбор.

7. Всю бизнес-логику держим в хранимках — так быстрее

Переносите всю логику в базу. Зачем нужны сервисы приложений?

Пример из практики: Система с хранимыми процедурами Oracle обыграла Java-реализацию в тестах производительности. Логика выполнялась рядом с данными, без сетевых задержек. Но когда нагрузка выросла в разы, уперлись в лимит CPU на сервере баз данных. Добавить ресурсы оказалось сложнее, чем масштабировать stateless-сервисы.

Компромисс: Тяжелые агрегации и отчеты делайте в функциях базы. CRUD-операции выносите в сервисы приложений. Следите за загрузкой CPU на сервере БД — когда она приближается к пределу, начинайте выносить логику наружу.

8. Коммерческая СУБД — единственный путь

Только коммерческие решения подходят для серьезных задач. Oracle и SQL Server проверены временем, а всякие open source базы — это для студентов и стартапов.

Что изменилось: События последних лет заставили многие компании пересмотреть подход к выбору СУБД. Компании массово переходят на PostgreSQL Pro и другие open source решения. Тренд только усиливается — игнорировать open source значит отстать от рынка и пропустить инновации, которые часто появляются именно в открытых проектах.

НО: Vanilla PostgreSQL без поддержки — это действительно риск. Когда расширение Oracle FDW падает с разными структурами таблиц, а автор из коммьюнити отвечает «мне в голову не приходило, что кто-то будет так делать», понимаешь ценность платной поддержки. Поэтому open source, но с поддержкой от надежных вендоров.

Заключение

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

Выберите один совет из этой статьи и примените его сегодня. Возможно, это сэкономит вам несколько часов сна в будущем. А коллеги-DBA скажут спасибо.

Ранее о подобной атаке заявили в «Неофарме» и аптеке «Столичка».

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

Какие сбои уже зафиксировали

Кроме проблем в «Семейном докторе», есть и другие пострадавшие. «Альфа‑Центр Здоровья», например, подтвердил сбои в внутренних сервисах и невозможность доступа к пациентскому порталу, также сообщая о технических неполадках сервисов онлайн-записи и личного кабинета.

По данным Regnum, в аптечных сетях пользователи потеряли возможность брони и доступа к программе лояльности.

Прецедент: атака на «Столичку» и «Неофарм»

Накануне аналогичные кибератаки обрушили работу аптек «Столичка» в свыше 1000 точках в 80 городах: сотрудники были освобождены от смен, клиенты не могли воспользоваться услугами. Подобным образом пострадал и «Неофарм».

Возможные причины и мотивы

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

Что дальше?

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

Просто напоминание

Напомним, что вчера случился один из крупнейших взломов за всю историю российской авиации.

Жертвой оказалась компания «Аэрофлот», а ответственность за атаку взяли на себя украинские хакеры.

1. Yonote

Yonote — российская база знаний и система для работы с проектами. Помогает командам и отдельным пользователям собирать и систематизировать информацию, вести базы знаний, планировать проекты и обмениваться документами. Платформа сочетает гибкий интерфейс, как в Notion, и функциональность KMS-систем: блочный редактор, доски, таблицы и базы данных работают в одном окне. Отличие Yonote — бесконечные доски для визуального планирования, поддержка on-prem-развёртывания и хранение данных в России.

Сценарии использования

Yonote подходит для:

• Командной работы: планирование задач, контроль
  сроков, управление проектами, CRM, сбор и визуализация отчётов, хранение
  инструкций и регламентов.
• Личных целей: заметки, трекер задач,
  бюджетирование, планирование поездок, учёба и хранение материалов.
• Создания Wiki: организация базы знаний о
  продукте с древовидной структурой, вставкой таблиц, диаграмм и медиа, историей
  изменений и комментариями.
• Ведения
  документации: базы данных по
  клиентам, проектам и инвентарю с таблицами, фильтрами, канбан-досками и
  календарями, прикреплением файлов и ссылок.

Формат работы

Yonote работает через web-интерфейс с удобным Markdown-редактором, поиском и историей изменений. Можно встраивать код, схемы и embed-ссылки из GitHub, Figma, Miro и других сервисов.

Поддерживается полный доступ по API, импорт и экспорт в Markdown и PDF, хранение на своих серверах (on-prem) и в облаке. Yonote предлагает более 30 интеграций, включая GitHub, Jira, Trello, Telegram, Miro и Airtable. Настраиваются уровни доступа: можно создавать гостевые аккаунты, разграничивать права на чтение и редактирование, делиться публичными ссылками.

Yonote заменяет несколько инструментов сразу (Trello, Google Docs, Confluence, личные заметки), легко адаптируется под любые задачи, подходит для госорганизаций, частных компаний и личного использования.

Тарифы

• Базовый — бесплатно, 5 ГБ, до 5 пользователей и 10 гостей.
• Старт — 149 ₽ за пользователя в месяц, 20 ГБ, до 50 гостей.
• Про — 249 ₽ за пользователя в месяц. Доступен безлимит гостей, неограниченное хранилище, SSO.
• Enterprise — тариф для организаций с расширенной поддержкой и контролем.

2. Anytype

Anytype — «приложение для всего», которое предлагает создать собственную локальную сеть для хранения знаний, заметок, трекеров привычек, рецептов и канбан-досок. По принципу работы похоже на Notion: блоковая структура, гибкие базы данных и визуальные представления информации.

Главное отличие — Anytype полностью локален и использует P2P-синхронизацию без серверов и посредников, данные остаются только у вас, никто не имеет к ним доступа. Приложение с открытым кодом и доступной архитектурой, работает без интернета и требует установки на устройство.

Сценарии использования

Личные цели: создание ежедневников, трекеров привычек, расписаний, конспектов, ведение стратегических заметок в одном месте, даже без подключения к интернету.

Работа в команде: организация командных вики и канбан-досок, совместная работа в группах, ведение календарей.

Сообщество и креатив: управление блогом, создание лент-контента, рекомендаций и курируемых подборок, построение сообщества с объявлениями и вики-страницами.

Формат работы

Anytype работает офлайн на мобильных и десктопных устройствах (iOS, Android, Windows, macOS, Linux), без веб-версии. Скоростная P2P-синхронизация возможна через локальные сети.

Интерфейс основан на визуальном код-фри (no-code) редакторе: можно создавать базы данных, таблицы, канбаны, галереи и граф-связи между объектами.

Важно: все данные хранятся в локальном зашифрованном «хранилище» пользователя. При создании аккаунта генерируется ключ из 12 слов, который нужно хранить отдельно — без него доступ не восстановить.

Для разработчиков:

• Поддерживает локальное хранение данных и самостоятельный бэкап в любое место по выбору пользователя.
• Нет API в привычном виде, но возможно расширить функциональность за счёт открытого кода и протоколов.
• Настройки доступа гибко регулируются на уровне устройства, команды и отдельных объектов в приложении.

Цена и условия пользования

• Explorer — бесплатно, подходит для личного использования.
• Builder — $99 в год за пользователя, открывает расширенные функции и поддержку командной работы.
• Co-Creator — $299 в год за пользователя, с расширенными возможностями и дополнительной свободой кастомизации.

Весь интерфейс и работа — на английском языке.

3. Obsidian

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

Сценарии использования

Есть несколько сценариев:

• Личные заметки и дневники: быстрый доступ к записям на устройстве, структурирование мыслей, создание связей между идеями.
• База знаний и обучение: построение персональных вики с перекрёстными ссылками, графами связей и быстрым поиском.
• Управление проектами и исследованиями: создание канбанов и карт идей в Canvas для планирования и брейншторминга, публикация заметок для команды

Формат работы

Obsidian — десктопное и мобильное приложение (Windows, macOS, Linux, iOS, Android). Доступны следующие форматы:

1. Поддержка открытых форматов файлов (Markdown), которая обеспечивает долгосрочное хранение данных без зависимости от сервиса.
2. С помощью Obsidian Publish можно публиковать заметки как публичную вики, документацию с настраиваемым внешним видом и быстрым поиском.

Плагины позволяют создавать интеграции и автоматизировать процессы в зависимости от потребностей команды.

Есть поддержка истории версий и работы с командой в рамках общих хранилищ, при этом приватность отдельных файлов сохраняется.

Цена и условия пользования

• Бесплатно: использование приложения для личных нужд, хранение данных локально.
• Sync — $4 в месяц за пользователя при оплате за год, синхронизация заметок между устройствами с шифрованием, история версий, совместная работа в общих хранилищах.
• Publish — $8 в месяц за сайт при оплате за год, публикация заметок на сайт без технических знаний, настройка тем и структуры.

4. Gramax

Gramax — платформа для подготовки документации в подходе Docs as Code. Позволяет создавать и редактировать статьи в визуальном редакторе, хранить исходники в Markdown и версионировать их с помощью Git. Подходит для тех, кто хочет управлять документами, знаниями и любым другим контентом в своей инфраструктуре гибко и безопасно.

Как и в Notion, в Gramax есть совместное использование, комментарии и AI-функции (создание и форматирование текста, перевод, поиск по статьям). Отличие — в Git‑first подходе, открытом коде и возможности использовать платформу бесплатно без ограничений.

Сценарии использования

Gramax особенно полезен для:

• Документации по продукту: создание портала с инструкциями, оформленного в корпоративном стиле, с быстрым обновлением и AI-поиском.
• Внутренней проектной документации: база знаний с версиями, Merge Request, поддержкой OpenAPI и технических требований.
• Базы знаний для команд: хранение описаний процессов и систем с удобным поиском и доступом через Git.

Формат работы

Gramax делится на:

• Редактор: web и десктоп на Win/Mac/Linux, можно использовать офлайн.
• Git-хранилище: подключается GitLab, GitHub, Bitbucket и другие, команды Git встроены в интерфейс.
• Портал документации: разворачивается как статический сайт или через Docker.

Для разработчиков есть поддержка диаграмм (Mermaid, Draw.io, PlantUML), подсветка кода (100+ языков), механизм сравнения версий, мультиязычность. Также на портале для чтения можно отображать документацию на разные версии ПО.

Gramax также поддерживает API для передачи данных в сторонние системы и CLI для интеграции в CI/CD, позволяя автоматически собирать документацию в HTML, PDF и DOCX. Есть импорт из Confluence, Notion и Yandex Wiki, экспорт в DOCX и PDF с фирменным стилем.

Цена и условия

• Open Source — бесплатно, без ограничений. Управление доступом на уровне репозиториев.
• Gramax Enterprise Server — 54 000 ₽ за редактора навсегда, первый год обновления бесплатно, далее 40% от лицензии. Управление доступом — по ролям и группам с SSO и корпоративными политиками.

5. KMS Gran

KMS Gran — база знаний с API и выстроенными бизнес-процессами. Помогает создавать и структурировать проектную документацию, управлять знаниями в команде и автоматизировать рутину. Платформа сочетает возможности вики, систем управления документами, визуальных блок-схем и AI-инструментов для поиска и анализа.

Как и в Notion, в KMS Gran есть WYSIWYG-редактор, мобильная версия и AI для работы с текстом. Отличие в том, что на платформе есть модуль «Скриптинг» для построения процессов и гибкая система прав доступа. Подходит командам, которым важно хранить данные локально и быстро строить рабочую рутину.

Сценарии использования

• Вики по продуктам и техдокументация. Доступно создание структурированных статей, глоссариев, руководств и спецификаций. Удобный поиск с морфологией и AI-помощником помогает находить информацию, а кириллица поддерживается корректно.
• Автоматизация бизнес-процессов. С помощью модуля «Скриптинг» можно строить визуальные блок-схемы процессов, задавать условия и добавлять к шагам инструкции и файлы. Подходит для команд поддержки и контакт-центров.
• AI-помощник для пользователей. Индексирует статьи и отвечает на вопросы по проектам с указанием источников. Сохраняет контекст диалогов, позволяет оценивать ответы и формирует отчеты для анализа востребованности контента.

Формат работы

KMS Gran работает через web-интерфейс с удобным WYSIWYG-редактором, поддерживающим Markdown, и адаптирован под мобильные устройства. В системе доступен полнотекстовый поиск с морфологией и возможностью получать ответы от AI, а также версионирование с откатом и архивацией статей. Для согласования внутри команды предусмотрена отметка о прочтении. В документы можно вставлять код и схемы через интеграцию с Draw.io, но подключение embed-ссылок из GitHub и Figma не поддерживается.

Платформа поддерживает работу через API для интеграции с внешними системами, хотя CLI в ней не предусмотрен. Можно настроить подключение к Slack, GitHub, CI/CD и Jira через API. Гибкая система управления доступом позволяет задавать роли как на уровне всей системы, так и в отдельных проектах и разделах, а также управлять доступом к разным документам.

Цена и условия

• SaaS: аренда по подписке, ежемесячная оплата за пользователя. Включены базовый функционал, серверные ресурсы и поддержка 9×5, опционально AI-модуль.
• On-Premise: развёртывание у заказчика, лицензия на длительный срок, поддержка AI-модуля и техподдержка.
• AI-модуль доступен как в SaaS, так и On-Premise.

Условия зависят от объема лицензий, срока использования и набора функций, обсуждаются индивидуально. Все тарифы включают базовый функционал.

Как выбрать платформу для базы знаний

Выбор платформы зависит от ваших задач. Для удобства собрали таблицу с особенностями платформ.

Таким образом:

Если приоритет — работа с документацией как с кодом, версионирование и публикация через Git — ваш выбор Gramax.

Нужна визуализация, работа с таблицами, досками и интеграции для команды — стоит обратить внимание на Yonote.

Если вы ищете корпоративное решение с AI, разграничением прав доступа и встроенными процессами — подойдёт KMS Gran.

Anytype или Obsidian подойдут тем, кто ценит контроль над данными и гибкость кастомизации.

1. Pandas

Pandas — библиотека для работы с данными в Python, позволяющая легко загружать, анализировать, очищать и преобразовывать числовую информацию в удобной табличной форме. По сути, это Excel, который смог, и позволяет делать всё автоматизировано и на порядки быстрее.

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

Ниже разберём простейший кейс: нужно загрузить данные о зарплатах разработчиков из CSV, посчитать среднюю зарплату по языкам программирования и отобрать топ-5.

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

Для аналитика Pandas превращается в главный рабочий инструмент, позволяя не просто проверять гипотезы и делать сводные таблицы, а строить полноценные отчётные пайплайны, автоматизировать рутинные выгрузки и концентрироваться на сути данных, а не на правках ручками.

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

Django подходит как стартапам, которым нужно быстро выйти на рынок, так и крупным проектам с миллионами пользователей. Это не просто библиотека, а полноценный каркас для построения и сопровождения веб-сервисов.

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

Сегодня PyTorch используется в продакшен системах, научных исследованиях, компьютерном зрении, NLP и генеративных моделях, занимая ведущее место в индустрии.

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

PyTorch — билет в мир современной разработки AI и машинного обучения. Владение инструментом даёт разработчику возможность уверенно войти в области, которые продолжают оставаться топовыми на рынке: искусственный интеллект, компьютерное зрение, NLP, генерация изображений и видео и т.д.

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

PyTorch в целом помогает расширять портфолио: с ним можно создавать генеративные модели, строить LLM, участвовать в соревнованиях и работать с самыми современными подходами в машинном обучении.

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

Для дата-сайентистов Polars даёт возможность анализировать больше данных за меньшее время, быстро итерировать гипотезы и ускорять исследования. Его API достаточно близок к Pandas, поэтому переход не требует месяцев переучивания.

Освоение Polars показывает работодателям, что ты не просто знаешь стандартные инструменты, но умеешь выбирать оптимальные решения для реальных задач, повышая эффективность работы команды. В эпоху роста данных это критично для любого Python-разработчика, работающего с аналитикой и машинным обучением.

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

Для ML-специалиста FastAPI становится инструментом для деплоя моделей: можно обернуть пайплайн предсказаний в API, подключить авторизацию или логирование и получить работающий сервис за считанные дни.

Вообще умение быстро поднимать и поддерживать API — навык, который ценят в бигтехе и стартапах. На разработчиков, которые владеют FastAPI, часто равняются: они умеют превращать идеи бизнеса в работающие сервисы за минимальное время.

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

В результате в терминале получится цветная таблица, которая выглядит понятно и презентабельно.

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

Благодаря единым абстракциям, можно гибко комбинировать цепочки, память и вызов внешних инструментов, не усложняя код.

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

SQLAlchemy меняет карьеру Python-разработчика тем, что даёт понимание системной работы с данными, архитектуры приложений и взаимодействия с реальными базами данных. Вы учитесь строить продуманные бэкенды, которые работают с транзакциями, миграциями, связями между таблицами и сложными выборками.

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

В три строки мы получаем чистый и читаемый ящик с усами, показывающий, как счет за ужин распределяется по дням недели.

Для построения более сложных графиков можно использовать диаграмму рассеяния:

Тут мы добавляем цветовую кодировку по полу, чтобы увидеть зависимости между переменными.

Почему это меняет карьеру

Seaborn меняет карьеру, потому что даёт навык визуального анализа данных, что критично в современной аналитике и дата-инженерии. Умение быстро строить графики и видеть аномалии, распределения и взаимосвязи между переменными превращает работу с данными из слепого копания в числах в структурный анализ.

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

Seaborn также учит пониманию данных через визуальные паттерны, что улучшает навыки построения моделей машинного обучения (так понятнее, какие признаки важны), и помогает создавать наглядные отчёты для продуктовых решений, где результат анализа нужно доносить до людей не из айти-индустрии.

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Что такое счётчик транзакций и зачем он нужен?

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

Чтобы понять, как функционирует MVCC, представьте, что у каждого пользователя базы есть свой «моментальный снимок» данных. Когда вы начинаете работать, вы видите состояние данных на этот конкретный момент времени. Изменения, которые делают другие пользователи, не влияют на ваш снимок, пока вы не завершите свою операцию и не начнете новую. Это позволяет нескольким пользователям одновременно читать и изменять данные, не мешая друг другу.

MVCC в PostgreSQL работает похожим образом:

• Каждая транзакция — это как отдельный пользователь, работающий с документом. Транзакция видит «снимок» базы данных на момент своего начала.
• Когда транзакция изменяет данные, она не перезаписывает старые. Вместо этого создаётся новая версия изменённых строк.

Каждая версия строки имеет специальные метки:

• xmin — идентификатор транзакции, которая создала версию.
• xmax — идентификатор транзакции, которая удалила (или обновила) версию. Если строка ещё не удалена, xmax пустой.

Когда транзакция читает данные, PostgreSQL определяет, какую версию строки ей показывать, на основе правил видимости:

• транзакция видит строки, созданные до её начала (xmin меньше её идентификатора), и не помеченные как удалённые (xmax пустой или больше её идентификатора);
• транзакция видит строки, созданные ею самой;
• транзакция не видит строки, созданные транзакциями, которые начались позже неё (xmin больше её идентификатора).

Пример:

Допустим, у нас есть таблица users с данными:

1. Транзакция 1 (xid=100) начинается и читает таблицу Она видит обе строки, потому что они были созданы до её начала, и xmax у них пустой.

2. Транзакция 2 (xid=105) начинается и обновляет возраст Alice на 31. PostgreSQL не перезаписывает строку Alice, а создаёт новую версию:

3. Обратите внимание, что у старой версии Alice xmax теперь равен 105 (идентификатор транзакции 2), а у новой версии xmin равен 105.

4. Транзакция 1 снова читает таблицу. Она по-прежнему видит старую версию Alice (возраст 30), потому что новая версия была создана транзакцией, которая началась позже (105 > 100), а старая помечена как удалённая транзакцией с большим номером.

5. Транзакция 2 фиксируется.

6. Транзакция 3 (xid=110) начинается и читает таблицу Теперь она видит новую версию Alice (возраст 31), потому что транзакция 2, которая её создала, уже зафиксирована, и её xid меньше чем у транзакции 3.

Важно: номера транзакций (xid) не стоит сравнивать как обычные числа («больше» или «меньше»). Корректнее говорить «старше» или «младше». Дело в том, что номера транзакций сравниваются по модулю 232, образуя кольцо. Транзакции, отстающие от текущей на 231 назад, считаются «старше» («в прошлом»), а на 231 вперёд — «младше» («в будущем»).

Представьте себе круг:

• текущая транзакция — это точка на круге;
• «прошлые» транзакции — это точки слева от текущей, если двигаться против часовой стрелки;
• «будущие» транзакции — точки справа.

Каждая запись в базе данных имеет служебные поля xmin и xmax. В xmin записывается номер транзакции, создавшей запись, а в xmax — номер транзакции, удалившей её. Учетом этих номеров и занимается счетчик транзакций.

Как развивался счётчик транзакций

До версии PostgreSQL 8.2 при достижении максимального значения счётчика транзакций (примерно 4 миллиарда) PostgreSQL просто «падал». Чтобы продолжить работу, нужно было сделать дамп базы данных и создать её заново.

В версии 8.2 появился механизм циклического перезапуска счётчика. Для этого в фоновом режиме запускается процесс очистки (VACUUM).

Как это работает:

1. «Заморозка» старых транзакций: Когда на VACUUM передаётся значение, что счётчик транзакций скоро переполнится, он начинает помечать старые транзакции специальным идентификатором FrozenTransactionId. По сути, VACUUM говорит: «Эти транзакции настолько старые, что мы считаем их замороженными. Мы всегда будем считать их старше любых других транзакций.»
2. Счётчик эпох: Чтобы PostgreSQL знал, сколько раз счётчик уже «перезапускался», используется счётчик эпох. Каждый раз, когда счётчик транзакций доходит до конца и начинает заново, счётчик эпох увеличивается на единицу.
3. Циклический перезапуск: После того как VACUUM «заморозит» старые транзакции, счётчик транзакций может безопасно начать считать заново с трёх. PostgreSQL теперь знает, что все транзакции с идентификатором FrozenTransactionId старше любых других транзакций, даже если их номера меньше.

Это решило проблему «падения», но возникла новая: если VACUUM не успевает отработать вовремя, сервер может остановиться и потребовать запуска в монопольном режиме для очистки, что ведёт к простою.

В чём же проблема?

Сам по себе механизм счётчика транзакций работает хорошо. Проблема в том, что он создавался, когда 32-битное число (более 4 миллиардов) казалось огромным. Сейчас же, в системах с высокой нагрузкой (ретейл, крупные заводы, госучреждения), счётчик может оборачиваться раз в сутки.

Дополнительные сложности:

Среди служебных данных записи есть поле флагов. Для старых записей нужно периодически запускать VACUUM FREEZE, который помечает их как «замороженные» (FrozenTransactionId).

Для стабильной работы нужно, чтобы:

• разница между номером текущей транзакции и номером самой старой записи не превышала 2^32;
• VACUUM FREEZE выполнялся до нарушения первого условия.

В реальном мире это сложно:

• «долгие» транзакции мешают VACUUM FREEZE;
• сложно определить, когда транзакция «долгая», а когда «зависшая»;
• непонятно, когда бить тревогу из-за исчерпания идентификаторов;
• администратор БД несёт ответственность за потери бизнеса из-за своих действий.

Если вы можете остановить кластер БД, запустить его в монопольном режиме и подождать несколько часов, эта проблема вас не касается. Но в системах с высокими требованиями к доступности простой — недопустим.

Отдельно стоит упомянуть базы данных, в которые данные только добавляются (insert-only). В них VACUUM всё равно запускается для «заморозки» старых записей.

Решение: 64-битные идентификаторы транзакций

Казалось бы, простое решение — увеличить размер счётчика до 64 бит. Но это сложно:

• весь код PostgreSQL ожидает «видеть» 32-битные числа;
• в каждом кортеже (записи) хранятся xmin и xmax. Увеличение их размера с 8 до 16 байт значительно увеличит размер базы.

Мы в Postgres Professional разработали реализацию 64-битных идентификаторов транзакций (xid), увеличив их количество до 18 446 744 073 709 551 615 (264). Это решение используется во многих форках PostgreSQL. Проблема переполнения счётчика становится гипотетической (при высокой нагрузке 64-битный счётчик исчерпается примерно через 400 лет).

Патч с реализацией был предложен сообществу PostgreSQL, но пока не принят из-за его сложности. Однако многие разработчики форков PostgreSQL уже заявили о поддержке 64-битных xid в своих дистрибутивах.

Цель Postgres Professional — не продвигать свой вариант как единственно верный, а привлечь внимание к проблеме и стимулировать сообщество к поиску оптимального решения. Первая часть удалась: идея получила внимание. Но внедрение таких изменений — долгий процесс. Рост нагрузок на СУБД во всём мире показывает важность этой проблемы.

Мы надеемся, что PostgreSQL сможет адаптироваться к растущим нагрузкам и укрепить свои позиции на рынке.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

Когда мы говорим об углеродном следе ПО, важно понимать: код не существует в вакууме. Каждая строка, каждый запрос и каждая операция требуют физических ресурсов — электричества, серверного оборудования, систем охлаждения. В 2025 году эта цепочка стала еще сложнее из-за взрывного роста облачных вычислений и ИИ.

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

Эти тренды нацелены на долгосрочное действие и в перспективе должны полностью изменить текущую концепцию в разработке.

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

Компании, внедрившие принципы устойчивого развития в IT, уже в 2025 году получают на больше инвестиций и быстрее проходят аудит регуляторов. Экологичность перестала быть затратой — теперь это конкурентное преимущество.

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

Экологичность в IT — не благотворительность и не актуальная повестка, а реальная экономия. Плюс работа на перспективу. Оптимизация кода снижает счета за облака и повышает производительность.

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Почему так? В 2024–2025 годах США ужесточили ограничения: VMware NSX и Cisco ACI официально заблокированы. Казалось бы, идеальный момент для отечественных решений вроде Basis SDN от «Базиса». Но сегодня их доля на рынке — не выше 3%.

Выясним, почему российские SDN, несмотря на импортозамещение, пока так и не стали массовыми, и что мешает бизнесу переходить на отечественные продукты — от дефицита специалистов до проблем с legacy-инфраструктурой. Только факты, кейсы внедрений и прогнозы на 2026–2030 годы с опорой на отчеты Ростелекома, аналитику 6Wresearch и документы OFAC.

SDN в России-2025: почему мир перешел на «сети из кода», а мы настраиваем маршрутизаторы вручную

SDN (Software-defined networking) — это когда сетью управляют не железки, а код. Представьте, что вместо того, чтобы вручную прописывать правила на каждом коммутаторе, вы просто пишете скрипт, и сеть мгновенно перестраивается под ваши задачи. Контроллер SDN решает, куда направить трафик, как распределить нагрузку и какие политики безопасности применить. Все это — без манипуляций с командной строкой и конфигурационных файлов.

Мировой контекст: SDN как новая норма

Глобальный рынок SDN к 2025 году оценивается в $12+ млрд, а темпы роста превышают 18% в год. Причины просты:

• Облака и гибридные инфраструктуры требуют гибкости, которую традиционные сети дать не могут.
• Киберугрозы теперь атакуют не отдельные устройства, а всю сеть. SDN позволяет изолировать зараженные сегменты за секунды — например, отрезать атакованный филиал до того, как он заразит головной офис.
• 5G и IoT без SDN просто не работают. Виртуальные срезы сети (network slicing) — единственный способ гарантировать приоритет критичному трафику, будь то телемедицина или беспилотники.

Но главный драйвер — экономика. Компании устали переплачивать за «умное» железо Cisco и Juniper, когда всю логику можно перенести в софт. К 2025 году 70% корпоративных сетей в ЕС и США управляются через SDN-контроллеры — просто потому, что это дешевле и быстрее.

Россия: технологический суверенитет vs. реальность

В 2024–2025 годах санкции добили то, что не успели в 2022-м:

• VMware NSX официально заблокирован для российских компаний.
• Cisco ACI и Huawei CloudFabric доступны только через «серые» схемы, но их поддержка практически не работает.
• Оборудование попало под прямые ограничения: даже нейтральные производители вроде Arista отказываются поставлять коммутаторы из-за риска вторичных санкций.

Казалось бы, идеальный момент для российских SDN-решений. Но доля отечественных продуктов на рынке — единицы. Причины такой ситуации вполне объективны:

• «Железная» зависимость. Большинство российских SDN работают только с оборудованием конкретных вендоров — YADRO, Aquarius, «Бифорком». Если у компании инфраструктура на старых Cisco или Huawei, миграция потребует полной замены «железа».
• Функциональные пробелы. Тот же Basis SDN декларирует 80% функционала VMware NSX, но ключевые фичи вроде автоматического восстановления после сбоев (self-healing) или глубокой аналитики трафика через ИИ пока в разработке.
• Дефицит экспертов. В России менее 1000 сертифицированных специалистов по SDN — против 25 000 в США и ЕС. Обучение нового инженера с нуля занимает 1.5–2 года — бизнес не готов ждать.

Спрос есть, но внедрять некому

Опросы специализированных изданий показали, что более трети крупных отечественных компаний хотели бы перейти на отечественные SDN, но многие из них не верят в стабильность российских решений, не готовы инвестировать в замену инфраструктуры, не могут найти подрядчика с нужной экспертизой.

При этом Basis SDN — единственное решение, которое хоть как-то закрывает дыру. Его пилоты запустили Ростелеком, СберТех и несколько госструктур. Но даже они признают: продукту не хватает открытости API и поддержки мультивендорных сред.

Вывод: мир уже живет в эпоху «сетей как кода», а Россия только учится настраивать контроллеры. Без массовых инвестиций в R&D (Research and Development, научные исследования и разработки) и образование разрыв будет расти. К 2030 году мы рискуем остаться с SDN «на бумаге», пока глобальные игроки перейдут на следующую ступень — IBN (intent-based networking) — сеть, основанную на намерениях с полной автономией ИИ.

Свои SDN: роскошь или необходимость?

Блокировки лишили российские компании доступа к обновлениям и техподдержке. Санкции против YADRO и других производителей сетевого оборудования усугубили проблему: даже если «железо» физически есть, его нельзя масштабировать без лицензий. Сложность в том, что технологический суверенитет нельзя купить — его нужно строить.

Технологический суверенитет — не лозунг, а вынужденная мера

В 2025 году термин «импортозамещение» уже не вызывает иронии. Сегодня российский бизнес столкнулся с простым фактом: зарубежные SDN-решения либо недоступны, либо работают с перебоями.

Компании, которые в 2024-м надеялись на «серые» поставки VMware NSX, теперь тратят на 40% больше на поддержку устаревших версий.

Basis SDN — пока единственная рабочая альтернатива. Разработка «Базиса» и Angie Software изначально создавалась под санкционные реалии:

• полная независимость от зарубежного ПО — даже гипервизор работает на KVM;
• поддержка российского «железа» (YADRO, Aquarius) без необходимости доработок;
• цена ниже VMware NSX до его ухода с рынка.

Но главное — это не просто клон VMware, а адаптация под российские условия. Например, здесь изначально заложена поддержка требований ФСТЭК к шифрованию трафика, что для госсектора критично.

Преимущества, которые оценит даже скептик

Рассмотрим подробно плюсы перехода на отечественные программно-определяемые сети.

Централизованное управление: оптимизация времени и расходов

Вместо настройки каждого коммутатора вручную вы управляете всей сетью через одну веб-панель. Нужно изменить политику безопасности для филиала? Все делается элементарно: не надо ехать на место или объяснять по телефону — правила применяются мгновенно.

Так работает Basis SDN:

• единый контроллер заменяет десятки разрозненных консолей Cisco Prime или Huawei eSight;
• автоматизация рутинных задач — например, выделение VLAN под новый отдел занимает минуты вместо часов;
• мониторинг в реальном времени — аномалии трафика (DDoS, утечки) система обнаруживает сама и предлагает решения.

Микросегментация: безопасность без головной боли

В 2025 году кибератаки стали точечными: злоумышленники не ломают всю сеть, а ищут слабые звенья — бухгалтерию, базы данных, IoT-устройства.

SDN позволяет изолировать критичные сегменты без физического разделения:

• финансовые системы можно отрезать от общего трафика, даже если они используют те же коммутаторы;
• доступ к данным регулируется не только логинами, но и контекстными правилами (например, запрет копирования файлов после 18:00);
• в случае атаки зараженный сегмент автоматически блокируется — без остановки всей сети.

Совместимость: работает здесь и сейчас

Типичная претензия к российскому ПО — «а вот у Cisco…». Но Basis SDN уже сегодня поддерживает:

• Astra Linux и «Альт» — без костылей в виде дополнительных драйверов;
• оборудование YADRO, БСТ, Aquarius — с гарантией обновлений;
• облачные платформы на базе KVM и отечественных гипервизоров.

При этом система не требует полного отказа от legacy-инфраструктуры. Например, можно оставить старые коммутаторы Cisco, но управлять ими через SDN-контроллер — это вдвое дешевле, чем менять все железо.

Рыночные перспективы: куда движется отрасль

Объем рынка SDN в России пока относительно невелик, но к 2031-му прогнозируют его рост до 32 млрд.

Основные драйверы:

• Госсектор: с 2024 года все госкомпании обязаны использовать «третьи ключи шифрования» — без SDN это нереализуемо.
• Телеком: Ростелеком и МТС тестируют SDN для 5G-сетей — ручное управление таким трафиком уже невозможно.
• Средний бизнес: облачные CRM и ERP требуют гибких сетей, а аренда VMware NSX теперь недоступна.

Вывод: свои SDN — это про выживание

В 2025 году вопрос уже не в том, «зачем свои SDN», а в том, как быстро компании смогут перейти на них. Ожидать возвращения VMware бессмысленно и нерационально.

При этом:

• Basis SDN — не идеален, но это практически единственное рабочее решение;
• без микросегментации скоро не получится пройти даже базовый аудит ФСТЭК;
• гибридные облака без SDN превращаются в кошмар админа.

Те, кто внедрит российские SDN сейчас, через 2–3 года получат снижение затрат на 25–40% по сравнению с теми, кто цепляется за «серые» Cisco и Huawei. Остальные рискуют остаться с сетью, которую некому и нечем администрировать.

Проблемы отечественных SDN: почему российские «сети из кода» пока не взлетели

Однако в 2025 году российские SDN-решения пока далеки от совершенства. Basis SDN от «Базиса» и аналоги от VK Tech («Спрут») — первые ласточки, но их внедрение сталкивается с тремя группами проблем: технологическими, экономическими и рыночными. Разберем каждую.

Технологические вызовы: когда железа много, а экспертов нет

Эта группа проблем наиболее показательна для отечественных решений.

Дефицит экспертизы. Для разработки конкурентоспособного SDN нужны специалисты высшего уровня, которых в РФ катастрофически не хватает.

Функциональные пробелы. Basis SDN декларирует 80% функционала VMware NSX, но критичные фичи вроде автономного восстановления после сбоев или глубокой аналитики трафика через ИИ появятся не раньше 2026 года. Для корпоративных клиентов это риск: например, без self-healing атака на один сегмент может парализовать всю сеть.

Совместимость с legacy-инфраструктурой. Большинство российских SDN работают с оборудованием YADRO, Aquarius или «Бифорком». Если у компании стоят старые Cisco или Huawei, миграция потребует полной замены «железа» — а это +30–50% к бюджету проекта.

Пример: В 2024 году Ростелеком-ЦОД пытался интегрировать Basis SDN с унаследованными коммутаторами Juniper. Проект забуксовал — пришлось докупать российские аналоги, что увеличило сроки внедрения на 4 месяца.

Экономические и регуляторные барьеры: санкции vs. окупаемость

Высокая стоимость разработки. Создание Basis SDN обошлось в сотни миллионов рублей. Для сравнения: бюджет VMware NSX превышает $1 млрд, но его распределяют на глобальный рынок. Российским вендорам приходится компенсировать затраты за счет узкой локальной аудитории.

Давление санкций. С июня 2024 года США запретили ИТ-консалтинг и облачные услуги для российских компаний. Это ударило по поддержке гибридных инфраструктур. Стало невозможно заказывать аудит сети у зарубежных вендоров, а облачные платформы вроде VMware Cloud Foundation недоступны даже через «серые» схемы.

Долгая окупаемость. По прогнозам «Базиса», Basis SDN окупится за 2–3 года. Но малый бизнес не готов ждать — ему нужны решения здесь и сейчас.

Рыночное недоверие: почему бизнес не верит в свои SDN

Культ «проверенных» зарубежных решений. Даже санкционные Cisco ACI и VMware NSX остаются в топе запросов у российских интеграторов.

Причины:

• Документация. У Cisco — 500+ страниц детальных мануалов, у Basis SDN — 80, и половина на уровне «как включить контроллер».
• Сообщество. Для VMware NSX есть 1000+ готовых скриптов на GitHub, для Basis SDN — меньше 50.

Низкая осведомленность малого бизнеса. Опрос бизнес-лаборатории «КРОК» показал: 60% компаний с оборотом до 1 млрд руб. считают SDN «дорогой игрушкой для корпораций». При этом они не знают, что микросегментация в Basis SDN снижает риски утечек на 40% — но об этом не пишут в СМИ.

Российские SDN не смогут конкурировать с зарубежными, пока:

• не сократится разрыв в экспертизе — нужны образовательные программы уровня Cisco Networking Academy;
• не появятся гарантии долгосрочной поддержки — например, госсубсидий на 5–10 лет;
• не изменится восприятие рынка — тут нужны кейсы уровня «Сбербанк полностью перешел на Basis SDN».

Сейчас Basis SDN остается нишевым продуктом для госсектора и Ростелекома.

Кейсы и перспективы: где российские SDN уже работают и куда движутся

В 2025 году российские SDN-решения перестали быть лабораторными проектами — они постепенно внедряются в реальную инфраструктуру. Но масштабы пока несопоставимы с зарубежными аналогами.

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

Basis SDN: первый крупный кейс — «Ростелеком-ЦОД»

В мае 2025 года «Базис» завершил пилотное внедрение своего SDN-решения в дата-центрах Ростелекома.

Проект показал:

• Сокращение времени настройки VLAN с 4 часов до 15 минут за счет централизованного управления.
• Микросегментация финансовых сервисов — изоляция платежных систем снизила риски атак на 40% по данным внутреннего аудита.
• Совместимость с оборудованием: 70% старых коммутаторов Cisco удалось интегрировать через шлюзы на базе KVM, хотя изначально Basis SDN разрабатывался для российского «железа» YADRO и Aquarius.

Потенциальные рынки: где российские SDN могут закрепиться

В июне 2025 года «Базис» анонсировал партнерство с телеком-оператором в ЮАР.

Причины интереса:

• Цена: $15 000 за контроллер против $30 000 у VMware NSX.
• Санкционная нейтральность: в Африке нет давления на использование российского ПО, а китайские аналоги (например, ZTE SDN) проигрывают в функционале.

Планируются поставки в Бразилию (интеграция с облачной платформой на базе OpenStack) и Казахстан (совместный проект с «Казтелеком»).

Согласно прогнозам, к 2031 году объем рынка SDN в РФ вырастет в 2-3 раза, но 80% спроса будет приходиться на госсектор и госкомпании.

Малый бизнес пока остается в стороне. Проблема в том, что Basis SDN ориентирован на крупные внедрения. Для малого бизнеса нет «облегченных» версий — аналогов Cisco ACI Essentials.

Рекомендации: как сделать российские SDN массовыми

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

Кадры — основа всего. Чтобы ускорить подготовку специалистов, нужно:

• ввести грантовые программы по типу «Цифровых профессий», но с фокусом на сетевые технологии;
• интегрировать модули по SDN в вузовские программы — пока лишь единицы технических университетов включают их в учебные планы.

Без этих шагов бизнес будет сталкиваться с той же проблемой, что и сейчас: даже купив Basis SDN, компании не смогут его эффективно использовать из-за нехватки компетенций.

Госсектор стал основным драйвером спроса на отечественные SDN, но для массового внедрения нужны меры, стимулирующие переход коммерческих компаний. Опыт Китая показывает, что субсидии на 50% затрат при миграции с VMware/Cisco резко увеличивают долю локальных решений.

Кроме того, стоит рассмотреть налоговые каникулы для стартапов в области сетевой виртуализации и заняться софинансированием пилотных проектов в среднем бизнесе — например, через Фонд развития цифровой экономики.

Одна из главных претензий к Basis SDN — слабая интеграция со сторонними платформами. Для сравнения: VMware NSX поддерживал свыше 200 приложений, а у российского аналога их на порядки меньше.

Без этого Basis SDN так и останется «закрытым» продуктом для узкого круга заказчиков. Российские SDN не станут массовыми сами по себе — нужна скоординированная работа бизнеса, образовательных учреждений и регуляторов.

Итоги: отечественные SDN требуют долгосрочной стратегии

Российские решения вроде Basis SDN доказали, что могут работать в реальных условиях. Но чтобы конкурировать глобально, нужно:

• увеличить долю рынка внутри страны — пока она менее 5%;
• снизить порог входа для малого бизнеса;
• выйти за пределы госзаказов — иначе продукт останется нишевым.

Жизнеспособность у проекта есть. Basis SDN закрывает 80% базовых потребностей бизнеса: микросегментация, централизованное управление, совместимость с российским «железом». Но критичные функции вроде автономного восстановления сетей появятся только к 2026 году.

Аналитики предсказывают рост рынка SDN в России, но это произойдет только если появятся новые фичи: например, интеграция с ИИ для прогнозирования сетевых аномалий, снизится порог входа и вырастет число специалистов.

Что может сделать каждый:

• Тестировать. «Базис» активно привлекает IT-комьюнити к доработке Basis SDN. Участие в пилотах — способ повлиять на развитие продукта.
• Развивать open-source. Проекты вроде OpenDaylight и OpenStack — основа для российских SDN. Чем больше контрибьюторов, тем быстрее сократится разрыв с зарубежными аналогами.
• Требовать документирования. Одна из главных претензий к Basis SDN — скудные мануалы. Если разработчики увидят запрос от сообщества на детальные гайды, они быстрее их выпустят

Главный вывод: SDN — не просто технология, а новая сетевая парадигма. Россия может занять в ней свое место, но для этого нужны не точечные успехи, а системные изменения.

Больше инфоповодов — в нашем тг-канале.

Почему «тормоза» — это не всегда про код

Когда пользователь жалуется на «медленное приложение», большинство разработчиков по привычке лезет в код. Профилируем, ищем неэффективные циклы, оптимизируем до запятых. Но в реальности причина часто не в логике, а в том, что её окружает.

Современное приложение — это сложный организм: десятки микросервисов, базы данных, кэши, брокеры, сети. И тормозить может любой из этих компонентов. А ты в это время профилируешь ни в чём не виноватый for.

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

Многие из них — не баги, а последствия архитектурных решений. В дев-среде всё летает, потому что:

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

Когда приложение тормозит, мы часто копаемся в отдельных компонентах — фронте, бэке, базе. Но bottleneck может быть не внутри компонента, а между ними: в конфигурации, связях, сетевых задержках, очередях вызовов.

Чтобы понять, где искать узкое место, нужно пройтись по всей цепочке — от клиента до внешних сервисов.

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

• Непрозрачная маршрутизация — скрытые таймауты, ошибки ретраев.
• Сборка ответов из микросервисов — цепочка из 5 вызовов на каждый клиентский запрос.
• Синхронные вызовы без деградации — если один микросервис недоступен, падает весь endpoint.

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

Оптимизация кода важна. Но если система тормозит, искать нужно по всей цепочке — от кнопки на фронте до брокера в соседнем дата-центре.

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

Архитектура доступа к данным: как закладываются тормоза

Архитектура доступа к данным — фундамент, на котором держится производительность всей системы. Даже идеальный алгоритм или быстрый backend не спасут, если данные извлекаются медленно, неэффективно или избыточно.

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

• Очередь перегружена, и событие просто стоит в хвосте.
• Обработчик падает или рестартится, и событие ждёт.
• Политики повторной обработки не настроены — событие крутится бесконечно.
• Слишком много этапов внутри одного воркера: валидация, запись в БД, вызов API — всё это задержки, которые суммируются.

Что происходит, когда очередь переполнена — и почему это тяжело заметить

Когда очередь переполняется, события в ней начинают задерживаться или теряться, в зависимости от конфигурации. Но хуже всего то, что это происходит тихо. Формально система работает: события принимаются, воркеры их обрабатывают. Но обработка начинает всё сильнее и сильнее отставать.

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

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

Микросервисная архитектура на бумаге выглядит идеально: каждый сервис автономен, команды независимы, масштабирование прозрачно. Но на практике все часто превращается в болото синхронных вызовов, где каждый сервис делает запросы в пять других.

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

Если тормозит хотя бы один, сыплется всё. Получается эффект домино и каскадные отказы, где неполадка в одном звене рвёт всю цепочку.

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

Кэш традиционно считается палочкой-выручалочкой для производительности. «Добавим кэш — и всё полетит», — думают команды, особенно под нагрузкой. Но в реальности кэш может не только не ускорить, но и наоборот — замедлить или даже уронить систему, если использовать его без понимания.

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

Если кэш живёт слишком долго — пользователи получают устаревшие данные. Если обновляется слишком часто — создаются лишняя нагрузка на базу и почти постоянные «промахи».

А если кэш сбрасывается при каждом изменении, он вообще не успевает выполнять свою роль. В итоге: нестабильное поведение, непредсказуемая производительность и раздражённые пользователи.

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

• работают на одной машине без шардинга;
• содержат тяжёлые объекты;
• используются как универсальный ответ на все проблемы.

В таких случаях кэш из «ускорителя» может падать под нагрузкой быстрее, чем база данных.

Кэш-миссы и лавины запросов

Классическая проблема: TTL у популярных ключей истекает одновременно, и тысячи запросов идут мимо кэша в базу. Это может случиться после деплоя, сброса кэша или при пиковой нагрузке.

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

Почему мощные сервера с десятками ядер и гигабайтами памяти тормозят? Потому что производительность упирается не в «железо», а в то, как именно это железо используется. От плохого управления памятью до блокирующих операций — в системе может быть множество узких мест, которые незаметно душат throughput.

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

Когда система тормозит, возникает соблазн сразу «что-то сделать» — добавить кэш, увеличить ресурсы, ускорить базу. Но без системного подхода можно попасть в замкнутый круг, где проблема будет возвращаться снова и снова. Чтобы избежать этого, лучше использовать пошаговую стратегию: зафиксировать симптомы, локализовать проблему, подтвердить и только потом оптимизировать.

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

Так можно увидеть, что, например, сторонний сервис отвечает 3 секунды, или Redis стал отдавать ответ за 300 мс вместо обычных 3 мс.

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

После изменений обязательно перепроверьте метрики, чтобы убедиться, что оптимизация действительно дала эффект — и не добавила новых узких мест.

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

Главная проблема в том, что узкие места проявляются не сразу, а под нагрузкой. В разработке и тестах всё летает, потому что ресурсов хватает. А вот в проде — особенно при росте аудитории — на поверхность всплывает всё, что не выдерживает реального объёма данных или конкуренции за ресурсы.

Чтобы избежать таких проблем, важно не просто писать чистый код, а мыслить системно: проектировать архитектуру так, чтобы она могла жить под давлением. Вот несколько принципов, которые помогут.

Думайте об объёмах и росте

Архитектура должна выдерживать не только текущую нагрузку, но и разумный рост. Строить систему на «миллиард пользователей» с первого дня — избыточно. Но если вы рассчитываете, что пользователей станет в 5 раз больше через год — закладывайте это сейчас. Узкие места не любят сюрпризов.

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

Любая система может начать тормозить — вопрос в том, как она себя при этом поведёт. Важно предусмотреть мягкую деградацию: таймауты, очереди, резервные сценарии, ограничение входящего трафика.

Не усложняйте архитектуру без повода

Микросервисы, шины, очереди, event-driven — всё это мощные инструменты. Но сложность должна быть оправданной. Простая, понятная архитектура с мониторингом и масштабируемыми точками зачастую выигрывает у перегруженной модульной схемы, которую никто не может отладить.

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

Что такое pet-проект и зачем его защищать

Pet-проект (от английского pet — «домашний питомец») — тренировочный проект, который разработчик создаёт в свободное время по собственному желанию. Обычно их делают, чтобы освоить новую технологию, пополнить портфолио или поучаствовать в хакатонах.

Такие проекты часто воспринимают как что-то «несерьёзное», но пренебрежение информационной безопасностью может привести к неприятным последствиям. Злоумышленники используют уязвимости pet-проектов для получения доступа к ресурсам разработчика, кражи данных и будущих атак на более крупные цели.

Кроме того, защита pet-проекта — важный навык, который высоко ценится работодателями.

Рассмотрим основные правила кибербезопасности, которые нужно учитывать при работе над pet-проектом.

Безопасное управление секретами

Секреты — это чувствительные данные, такие как пароли, токены доступа, ключи API, SSH-ключи, сертификаты и другие данные, которые обеспечивают аутентификацию и шифрование. Если добавить секреты в код, злоумышленники могут получить полный контроль над вашей инфраструктурой.

Какие правила нужно соблюдать

• Не храните секреты в коде. Храните секреты в отдельных файлах env. и добавьте эти файлы в .gitignore, чтобы они не попадали в репозиторий.
• Придерживайтесь принципа минимальных привилегий. Каждый сервис должен иметь только те права, которые необходимы для выполнения своих задач.
• Регулярно обновляйте секреты. Меняйте токены и пароли периодически, особенно после обнаружения утечек или изменений в проекте.
• Используйте менеджеры секретов. Популярные сервисы: Doppler, HashiCorp Vault, AWS Secrets Manager, 1Password Developer Tools.
• Мониторьте утечки. Можно использовать такие инструменты, как GitGuardian, TruffleHog, Gitleaks.
• Шифруйте секреты. Используйте библиотеки типа cryptography в Python и подключайте шифрование на уровне операционной системы.

Безопасность CI/CD

Пайплайн CI/CD (Continuous Integration / Continuous Delivery) — автоматизированный процесс сборки, тестирования и развёртывания приложений. Он помогает автоматически интегрировать код и деплоить его на различные среды.

Если злоумышленник получит доступ к пайплайну, он может внедрить вредоносный код в ваше приложение, остановить весь процесс разработки или развёртывания, украсть данные пользователей и т.д.

Способы защиты пайплайна

• Моделируйте угрозы. Оцените, какие угрозы наиболее вероятны на каждом этапе пайплайна: от коммита кода до деплоя на сервер.
• Проверяйте зафиксированный код. Используйте статический анализ кода для автоматического поиска уязвимостей.
• Защитите Git-репозитории. Настройте двухфакторную аутентификацию (2FA), ограничьте доступ к репозиториям, используйте обязательную проверку пул-реквестов двумя разработчиками.
• Изолируйте пайплайн. Не запускайте его на том же сервере, где крутится ваше продакшн-приложение.

Дополнительно стоит шифровать секреты в пайплайне и минимизировать их передачу между этапами сборки.

Сервисы мониторинга и логирования

Логирование — запись событий, ошибок и других данных о работе приложения в специальные файлы или базы данных. По сути, это дневник.

Мониторинг — наблюдение за состоянием приложения, инфраструктуры или сервисов в реальном времени для своевременного выявления падения сервера, роста ошибок и других проблем.

Анализ логов помогает выявлять баги, попытки несанкционированного доступа, долгие запросы, ошибки базы данных. Мониторинг позволяет мгновенно реагировать на сбои, а также с его помощью вы узнаете, хватает ли приложению серверных мощностей.

Примеры популярных сервисов

Logtail — простой инструмент для сбора и анализа логов, есть бесплатный тариф.

Papertrail — удобный сервис для быстрого поиска по логам, бесплатный план для небольших проектов (10 Мб в день).

Sentry — хорош для отслеживания ошибок в приложениях на клиентской стороне и сервере.

BetterStack — мониторинг доступности сайтов и серверов с бесплатными уведомлениями об инцидентах по почте, через SMS и Slack.

Grafana Cloud Free — мониторинг с красивыми дашбордами, бесплатный лимит ресурсов до 10 тыс. серий данных, 50 ГБ трафика.

Prometheus и Grafana — Prometheus собирает метрики, Grafana их визуализирует.

UptimeRobot — проверка доступности вашего проекта каждые 5 минут, бесплатный тариф на 50 мониторингов.

Бэкап и восстановление данных

Бэкап — это создание резервной копии данных, которую можно использовать для восстановления в случае утраты или повреждения оригиналов. Может показаться, что для pet-проекта это излишне, однако от случайных удалений данных, взломов серверов, утечек данных никто не застрахован. А ещё можно откатиться к рабочей версии, если будут ошибки в коде и деплойменте.

Как сделать бэкап пошагово

1. Определите данные, которые необходимо бэкапить: какие данные критически важны, какие можно восстановить вручную.
2. Выберите место хранения: облачные сервисы, собственные серверы, внешние носители, Git-репозиторий.
3. Выберите тип бэкапа: при полном копируются все данные целиком, при инкрементном — изменения с момента последнего копирования, при дифференциальном — изменения с момента последнего полного бэкапа.
4. Настройте автоматизацию, чтобы не забывать делать бэкапы вручную. Можно использовать скрипты, планировщики задач или бэкап-сервисы.
5. Проверьте бэкап. Проведите тестовое восстановление.
6. Определите частоту бэкапа. Например, можно проводить полный бэкап раз в неделю и инкрементные бэкапы каждый день.
7. Защитите чувствительные данные.

Локальные туннели

При разработке pet-проекта может возникнуть необходимость показать результат внешнему миру. Кроме того, многие внешние сервисы, такие как платёжные системы и мессенджеры, тоже требуют «боевые» URL для отправки запросов. Однако открывать порты на своём устройстве напрямую небезопасно. Локальные туннели создают временный внешний URL-адрес без развертывания на реальном сервере.

Когда вы запускаете туннель через специальный инструмент, он:

• устанавливает зашифрованное соединение между вашим компьютером и своим публичным сервером;
• создаёт внешний адрес;
• пересылает все запросы, которые приходят на этот адрес, вашему локальному приложению.

Трафик при этом шифруется и проходит через защищённый канал.

Примеры инструментов

Ngrok — самый известный инструмент для быстрого создания туннелей. Есть бесплатный тариф.

Порты от VSCode — отличное решение для пользователей Visual Studio Code, удобно для быстрой демонстрации.

VK Tunnel — российская альтернатива, подходит для работы через VK Cloud.

Tuna и xTunnel — простые в использовании решения, есть бесплатные тарифы.

Чек-лист по инфобезу для тех, кто делает pet-проект

1. Регулярно обновляйте зависимости. Используйте автоматические инструменты, например, Dependabot или npm audit.
2. Настройте базовые HTTP-заголовки безопасности. Добавьте заголовки Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, чтобы минимизировать риск XSS, Clickjacking и других атак.
3. Используйте бесплатные SSL-сертификаты. Подключите HTTPS через бесплатные сервисы, например, Let's Encrypt.
4. Очищайте и валидируйте ввод данных. Фильтрация и валидация данных защитит от SQL-инъекций и XSS.
5. Создайте отдельные учётные записи для разных сервисов. Не используйте одну и ту же учётную запись везде.
6. Минимизируйте доступы к базе данных. Если сервису нужно только читать, не давайте права на запись или удаление.
7. Используйте бесплатные инструменты для сканирования уязвимостей. Проверьте код через такие сканеры, как SonarQube Community Edition, Snyk, OWASP ZAP.
8. Делайте резервные копии. Настройте автоматические бэкапы базы данных и важных файлов.
9. Не храните секреты в коде. Используйте .env файлы и убедитесь, что они добавлены в .gitignore.
10. Включите двухфакторную аутентификацию (2FA). На всех сервисах, где это возможно, включите 2FA для дополнительной защиты.
    

А больше про разработку и все, что с ней связано, в нашем тг-канале!

На самом деле подобная постановка вопроса некорректна. Практически любое решение никогда не бывает финальным, тем более сразу. Об этом пишут многие заслуженные авторы, но самой яркая цитата, пожалуй, закон Голла.

Любая работающая сложная система неизменно оказывается производной простой работающей системы.

Позволю себе внести важные уточнения.

• Простота системы означает не примитивизм, а наличие ограниченного числа взаимодействующих между собой элементов с понятными и прослеживаемыми связями между ними.
• Сложность системы означает не трудность организации самой системы, а её зрелость, точность модели предметной области.

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

Во-первых, поскольку на начальных стадиях слишком много неопределенности, нужно как можно дольше сохранять свободу выбора направления развития. Во-вторых, принимаемые решения должны уточнять вектор движения для развития в желаемом направлении. Именно в этом контексте речь идет о гибкости архитектуры.

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

Такие размышления — не откровение, об этом давно и много говорят. Я лишь хочу подчеркнуть: задача архитектора — не просто принять логичное решение, но и просчитать его развитие. Важно думать на несколько шагов вперёд, сохраняя при этом простоту и гибкость архитектуры как можно дольше. Это, пожалуй, и есть лучший ориентир в выборе времени и уместности тех или иных решений. Каждый шаг должен вести к цели, закладывать основу для следующего и помогать точнее видеть направление движения. Если всё это соблюдается — значит, пора действовать.

Именно с такой перспективы стоит подходить к обоснованию архитектурных решений. Поэтому некоторые «аргументы», о которых пойдёт речь ниже, стоит отбрасывать сразу — несмотря на их комичность, в практике они встречаются до сих пор.

• Выбор технологии на основе только её популярности. («Так принято в лучших домах!», «Kafka справится с любой задачей» и т.п.)
• Ориентация на скорость, обоснованная амбициями или ощущениями. («Некогда думать — надо действовать!», «Мир сам себя не захватит!»)
• Неоправданное и/или преждевременное усложнение. («У меня нет задач, нужно придумать что-то интересненькое», «У меня скучные задачи, нужно добавить драйва», «Я предусмотрел обработчик на случай вторжения инопланетян!» и т.п.)
• Неоправданное расширение технологического стека. («CV-Driving Development», «Решил попробовать», «Мне так удобней» и т.п.)

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

Согласен, что иногда это и есть преждевременное усложнение. Однако, если архитектор или разработчик достаточно опытный, он может позволить себе «срезать углы», действуя на опережение. В данном случае он должен осознавать и указывать на все риски подобных действий, в том числе понимать, кто будет поддерживать и сопровождать такой продукт. Тут можно вернуться к метафоре с «космическим кораблём»: нужен ли он на старте, есть ли у вас подходящая команда, инфраструктура, ресурсы?

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

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. 😉

В этой подборке — 7 курсов, после которых реально получить первую работу в IT за 3–6 месяцев.

Почему в 2025 попасть в IT и легче, и сложнее одновременно

Войти в IT в 2025 реально, но рынок сильно изменился. С одной стороны, спрос на junior-специалистов вернулся: компании снова набирают новичков, открывают стажировки и гибридные программы. Но конкуренция стала выше, а фильтры — жёстче.

Что легче

• После карьерного спада 2022–2023 спрос на junior-специалистов начал восстанавливаться. Появилось больше стажировок и вакансий для начинающих. Согласно отчёту Robert Half, начать успешную карьеру могут инженеры по данным, DevOps-инженеры и разработчики ПО. Однако конкуренция остаётся высокой, и работодатели ожидают от кандидатов не только базовых знаний, но и быстрой адаптации к новым инструментам.
• Образование и работа в IT всё чаще переходят в гибридный формат: можно совмещать онлайн- и офлайн-обучение, работать удалённо и периодически встречаться в офисе.

Что сложнее

• Конкуренция выше, чем раньше. Даже на стартовые позиции часто подаётся по сотне кандидатов.
• Работодатели ждут не просто знаний или диплома, а быстрой адаптации.

Что изменилось в 2025 по сравнению с 2020–2024

Во-первых, образование стало прагматичнее. С 2020 по 2022 год рынок был наводнен короткими курсами «на джуна». В 2025-м большинство таких школ либо закрылись, либо переформатировались: люди устали платить за теорию без практики. Сейчас ценятся программы, в которых есть командные проекты, ревью от наставников, работа с Git и проектный пайплайн, близкий к реальному.

Во-вторых, работодатели всё чаще оценивают кандидатов по их реальным навыкам и опыту, а не по формальному образованию. Согласно прогнозам, 39% текущих навыков работников устареют к 2030 году, что подчеркивает необходимость постоянного обновления и адаптации.

Так, расширяются границы образования. А вместе с ними – появляются онлайн-курсы.

7 курсов, с которых начинают карьеру в IT

1. Kata Academy — GO-разработчик

Ссылка на курс

Go (Golang) — это билет в backend-разработку, где в 2025 году крутятся большие деньги и хардовые задачи. Язык, созданный Google, ценят за скорость и простоту, а компании от стартапов до гигантов вроде Яндекса выстраиваются в очередь за Go-разработчиками. Курс от Kata Academy учит писать серверный код, работать с SQL, Git, Linux и Docker, чтобы выпускники могли строить масштабируемые приложения.

📚Что получают выпускники

На курсе студент осваивает Go и смежные технологии, создает портфолио из практических проектов, готовится к собеседованиям с поддержкой школы и приходит к главной цели — устраивается на работу по новой специальности. Кроме этого:

• Есть карьерная поддержка: резюме, собеседования, вакансии;
• В договоре — гарантированная зарплата от 120 000 ₽ (может быть выше).

🎓Длительность и формат

Курс проводится полностью онлайн. Длительность обучения — 9 месяцев, включая подготовку к собеседованиям. Нагрузка: от 25 часов обучения в неделю (3-4 часа в день), есть дедлайны. Выпускник устраивается на работу после курса, в течение 1-2 месяцев (в среднем).

👥Кому подойдет

• Новичкам без опыта в программировании;
• Студентам и начинающим разработчикам, которые хотят освоить Go;
• Может быть интересен тем, кто работает во фронтенде или техподдержке и хочет сменить направление.

Не требует знаний математики и программирования — рассчитан на обучение с нуля.

🏆Возможности после курса

На сайте указано, что выпускники устраиваются в компании, такие как Яндекс, Альфа-Банк и Kaspersky, часто в течение первого месяца после завершения основной программы курса. Если выпускник не найдет работу с зарплатой от 120.000 рублей, то оплачивать обучение не придется.

💸 Стоимость и условия участия

Есть два варианта обучения:

• Интенсивное (стоимость — 110 000 рублей во время учебы плюс 20% от зарплаты в первый год работы). Для тех, кто живет в Москве или Санкт-Петербурге, или готов туда переехать.
• Асинхронное (стоимость — 262 000 рублей). Обучение в своем темпе, нет дедлайнов. Можно искать работу в любом городе-миллионнике, если не получится устроиться — есть гарантия возврата денег.

2. CyberEd — Пентестер

Ссылка на курс

Пентест (тестирование на проникновение) — это процесс поиска уязвимостей в IT-системах путем имитации атак хакеров.

Курс обучает анализу защищенности веб-приложений, сетей и инфраструктуры, а также использованию инструментов вроде Nessus и Nmap.

В программе будут техники атак, методы их обнаружения и составление отчетов. Курс готовит специалистов к реальным задачам в области кибербезопасности для работы в топовых компаниях.

📚Что получают выпускники

• Выпускники получают диплом о профессиональной переподготовке или удостоверение о повышении квалификации (зависит от формата).
• Студенты формируют цифровое резюме и портфолио на основе практических заданий.
• Все студенты проходят карьерную подготовку — от тренировки прохождения собеседований до подбора стажировок и вакансий.

🎓Длительность и формат

Обучение длится 24 недели (365 академических часов) и проходит полностью онлайн. Есть два формата:

• Синхронный формат — с расписанием и онлайн-занятиями в группе. Включает 24 онлайн-семинара по 4 часа, регулярную обратную связь от наставников и карьерные консультации.
• Асинхронный формат — без привязки ко времени: обучение проходит в удобном для студента темпе. Доступ ко всем материалам курса, заданиям и модулям открыт сразу.

Оба формата включают более 100 практических заданий, поддержку менторов и итоговый проект.

👥Кому подойдет

• Айтишникам, которые хотят научиться пентесту или прокачаться в кибербезопасности.
• Системным администраторам, веб-разработчикам, специалистам по ИБ, а также джунам и миддлам из пентеста, Blue Team или AppSec.

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

🏆Возможности стажировки и трудоустройства

Выпускники устраиваются на позиции инженеров по безопасности или пентестеров, в том числе в крупные IT-компании. По отзывам студентов, некоторые находят стажировку уже на 4 месяц обучения, а часть получает постоянные позиции в течение 1 года после финала курса.

💸 Стоимость и условия участия

138 000 рублей за синхронный формат, 74 000 рублей за асинхронный. Доступна рассрочка на 2 года — 6 900 рублей в месяц.

Для поступления необходимо подать заявку через сайт. Точные требования к участникам не указаны, но курс предполагает наличие базовых знаний IT.

3. Яндекс Практикум — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) проверяет качество программных продуктов: ищет ошибки в веб-приложениях, мобильных приложениях и API.

В программе курса Яндекс Практикума будут основы ручного тестирования, работа с тестовой документацией и инструментами, базовые навыки автоматизации, а также отдельные модули по информационной безопасности, Figma, Python и SQL.

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

📚Что получают выпускники

• В финале курса Практикум выдаёт диплом о профессиональной переподготовке.
• Также у выпускников остаётся портфолио из 7 учебных проектов (в расширенной версии курса — из 9). Среди них, например, — итоговая работа над сервисом Яндекса (тестирование Яндекс.Маршрутов и т.д.).
• Дополнительно открывается доступ к модулю по YandexGPT и YandexART.
• В течение семи месяцев после окончания обучения доступна карьерная поддержка. При желании можно набираться опыта в Мастерской Практикума — это агентство внутри Практикума, где выпускники работают над задачами реальных заказчиков.

🎓Длительность и формат

• Курс рассчитан на пять месяцев — это 318 академических часов, в среднем около 20 часов в неделю. Обучение проходит онлайн.
• Теоретическая часть будет в виде интерактивного учебника, а практические задачи выполняются по спринтам: каждые три недели — новый проект.
• Воркшопы и консультации с наставниками проходят по расписанию. У студентов есть дедлайны по проектным заданиям.

👥Кому подойдет

• Новичкам без опыта в IT — студентам, тем, кто хочет сменить профессию, и специалистам из смежных областей.
• Техническое образование и навыки программирования не требуются, но базовый английский будет плюсом, особенно если планируете развиваться в сторону автоматизации.

🏆Возможности стажировки и трудоустройства

После завершения программы карьерный центр помогает в трудоустройстве (доступны карьерная поддержка в течение 6+ месяцев после обучения, фриланс-трек для тех, кто хочет работать на себя, вакансии и стажировки от партнёров и мастерская проектов). В среднем, стажёры зарабатывают около 52 000 рублей, джуниоры — 76 000, мидлы — 142 000 рублей.

💸 Стоимость и условия участия

• Junior-трек. Подходит для старта в тестировании. 77 000 ₽ — при полной оплате; 16 500 ₽/мес. × 5 месяцев — при рассрочке.
• Расширенный трек. Тут больше практики и навыков, чтобы быстрее вырасти до мидла. 148 000 ₽ — при полной оплате; 18 500 ₽/мес. × 9 месяцев — при рассрочке.
• От новичка до автоматизатора. Сразу две профессии: ручное и автоматизированное тестирование. 156 000 ₽ — при полной оплате. 20 000 ₽/мес. × 9 месяцев — при рассрочке.

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

4. Rebrain — Мини-практикум Golang с нуля

Ссылка на курс

Мини-практикум от Rebrain знакомит с основами Go, включая синтаксис, работу с каналами, контекстами и микросервисами. Программа ориентирована на практическое освоение языка через выполнение задач, моделирующих реальные сценарии backend-разработки.

📚Что получают выпускники

Выпускники получают сертификат Rebrain, подтверждающий освоение основ Go. В программу входят более 10 практических задач, демонстрирующих навыки работы с языком и современными подходами к разработке.

Доступ к комьюнити и онлайн-мероприятиям Rebrain позволяет продолжать обучение и налаживать профессиональные связи. Теоретические материалы остаются доступными навсегда.

🎓Длительность и формат

• Курс длится около 2 недель, но продолжительность зависит от темпа студента.
• Программа полностью онлайн и асинхронная, что позволяет учиться в удобное время без привязки к расписанию.
• Формат текстовый, без видеолекций, с акцентом на практику (90% времени).

Студенты выполняют более 10 задач, а менторы на связи для обратной связь и поддержки.

👥Кому подойдет

• Студентам с потенциалом для Go;
• Начинающим разработчикам без практического опыта;
• Специалистам из смежных IT-направлений.

Здесь нужны минимальные навыки работы с системами контроля версий (GitHub/GitLab), но глубокие знания программирования не требуются.

🏆Возможности стажировки и трудоустройства

HR-центр Rebrain помогает выпускникам с поиском работы, предоставляя консультации по резюме и подготовке к собеседованиям. Участники комьюнити Rebrain могут попробовать себя в хакатонах и профессиональных событиях, где легче найти работу.

💸 Стоимость и условия участия

Стоимость курса — 14 990 рублей при полной оплате или 1 249 рублей в месяц при рассрочке на 12 месяцев. Для поступления достаточно подать заявку через сайт; специальных требований, кроме базового понимания IT, нет. Курс подходит для самостоятельного обучения, но требует дисциплины из-за асинхронного формата.

5. Systems.Education — Системный аналитик / Проектировщик корпоративных информационных систем

Ссылка на курс

Цель программы — получить профессию системного аналитика, которая соответствует актуальным требованиям вакансий на рынке.

На курсе от Systems.Education вы за 3 месяца пройдёте реальный кейс за счёт работы с:

• Формальным моделированием бизнеса и бизнес-проблемы: Event Storming, BPMN, Opportunity canvas.
• Разработкой пользовательских требований: Impact map, User story map, Use case diagram, Use case scenario.
• Концептуальным проектированием ИТ-решений: моделирование предметной области, UML диаграмма состояний, Контекстная диаграмма, Концептуальная модель данных, Макеты приложений.
• Спецификацией требований к системе: Функциональные требования к системе, Нефункциональные требования к системе, Требования к информационной безопасности, Системные алгоритмы.
• Техническим проектированием ИТ-решений: Диаграмма взаимосвязи объектов, диаграммы в нотации С4, Требования к интеграции, UML диаграмма последовательности, Data flow diagram.

📚Что получают выпускники

• Сертификат на основании лицензии об образовательной деятельности, подтверждающий квалификацию системного аналитика уровней 4 и 5 по российскому профстандарту.
• Портфолио, включающее результаты их учебного проекта.
• Демонстрацию финальных результатов кейса перед приглашенными HR и техническими специалистами из компаний-потенциальных работодателей.

🎓Длительность и формат

Курс длится 3 месяца (200+ академических часов) и проводится полностью онлайн: 8 часов в неделю — занятия с преподавателем в Zoom, дополнительно — командные и индивидуальные созвоны с ментором. Процесс обучения осуществляется в командах, в которых участники работают над реальным кейсом.

Каждую неделю студенты взаимодействуют с заказчиком, роль которого выполняет ведущий специалист школы SE: команды проводят с ним интервью, собирают требования, выявляют проблемы бизнеса, формируют цель разработки, определяют границы проекта и утверждают концепцию решения. Под руководством ментора переходят от системного анализа к проектированию информационной системы: выбирают подходящий архитектурный паттерн и тип базы данных, проектируют поток информации через интеграции API и брокеров. Каждую неделю студенты получают обратную связь от менторов.

👥Кому подойдет

• Не системным аналитикам, которые хотят освоить практики проектирования информационных систем и/или стать системными аналитиками.
• Системным аналитикам, которые хотят получить поддержку старших коллег при отработке практик проектирования, а также систематизировать знания в области проектирования ИС.

🏆Возможности стажировки и трудоустройства

• Защитите итоговый проект прямо перед HR и техспецами из компаний.
• Получите портфолио из настоящих проектных документов (артефактов) — всё, что требуют работодатели на позиции младшего системного аналитика.
• В течение всего обучения вас будут сопровождать менторы-практики: помогут с проектом, дадут фидбек, подготовят к собеседованиям.

По статистике школы, выпускники за год могут дорасти до уровня Middle-аналитика.

💸 Стоимость и условия участия

• 205 000 рублей для физических лиц
• 255 000 рублей для юридических лиц.

Действует скидка на раннее бронирование. Потоки стартуют раз в три месяца. Для поступления требуется подать заявку через сайт. Базовые знания IT-процессов желательны, но специальных тестов нет. Гарантируется 100% возврат средств при отказе до начала обучения.

6. Karpov.Courses — Аналитик данных

Ссылка на курс

Курс от karpov.courses учит работать с Python, SQL, Power BI и другими нужными инструментами для анализа, визуализации и автоматизации. В программе много практики: решаете реальные задачи — A/B-тесты, расчёт метрик, анализ больших данных, работа с хранилищами.

📚Что получают выпускники

• Сертификат, подтверждающий освоение программы, и портфолио из более чем 10 учебных проектов, включая работу с реальными бизнес-кейсами.
• Доступ к рабочей инфраструктуре и более 490 заданиям, моделирующим задачи аналитиков.
• Карьерную поддержку.

Материалы курса остаются доступны бессрочно.

🎓Длительность и формат

Курс длится 5 месяцев и проводится полностью онлайн на LMS-платформе. Студенты проходят уроки и выполняют домашние задания в удобном темпе, с ежедневной поддержкой кураторов и экспертов.

👥Кому подойдет

• Новичкам без опыта в IT, студентам, чтобы освоить аналитику данных.
• Маркетологам и менеджерам, чтобы рассчитывать метрики бизнеса и их эффективность.
• Специалистам с релевантным опытом (джуниорам и выше).

Базовые навыки работы с данными (например, Excel или SQL) полезны, но не обязательны.

По итогу — будете уметь вытаскивать инсайты из данных, делать понятные дашборды и находить ответы для решения бизнес-задач.

🏆Возможности стажировки и трудоустройства

Karpov.Courses предлагает карьерную поддержку по поиску работы, чат с консультантами и доступ к вакансиям от партнеров.

Выпускники могут стать младшими аналитиками данных или Data Scientist с медианной зарплатой на старте 100–120 000 рублей, а если уровень мидл — от 180 000 рублей. По данным школы, 3 месяца — средний срок успешного трудоустройства.

💸 Стоимость и условия участия

Стоимость базового тарифа — 80 000 рублей при единовременной оплате. Доступна беспроцентная рассрочка на 24 месяца (платёж примерно 4 408 рублей в месяц).

Для поступления достаточно подать заявку через сайт, специальных требований или вступительных тестов нет.

7. Нетология — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) отвечает за проверку качества программного обеспечения, выявляя ошибки в веб-приложениях, мобильных сервисах и API. Курс от Нетологии обучает ручному и автоматизированному тестированию, включая работу с инструментами и языками программирования (Python, Java, JavaScript).

Программа предлагает три трека:

• «Ручное тестирование» для новичков;
• «QA-инженер уровня Junior» с основами автоматизации;
• «QA-инженер уровня Middle» с углубленным изучением JavaScript, мобильного и нагрузочного тестирования.

Студенты работают над реальными кейсами от партнеров — Dragons, OneTwoTrip и GOD.

📚Что получают выпускники

• Диплом о профессиональной переподготовке и портфолио из 5 крупных проектов, включая тестирование сайтов, веб-сервисов, приложений и командный дипломный проект.
• Программа включает до 74 практических заданий, моделирующих реальные задачи тестировщиков.
• Карьерная поддержка предусматривает тестовые собеседования, помощь в составлении резюме и возможность стажировки у партнеров.
• Дополнительно студенты проходят воркшоп по применению нейросетей для автоматизации задач.

Материалы курса доступны в личном кабинете навсегда.

🎓Длительность и формат

• Курс проводится полностью онлайн, длительность зависит от трека: в среднем, 4–6 месяцев.

• Занятия включают вебинары по расписанию (не чаще 2 раз в неделю после 19:00 МСК), видеолекции, тесты и практические задания.

• На обучение требуется 8–10 часов в неделю. Формат сочетает синхронные вебинары с асинхронной работой через личный кабинет.

👥Кому подойдет

• Новичкам без опыта, студентам и специалистам из смежных сфер.

• Трек Junior подходит для начинающих, интересующихся автоматизацией, а трек Middle — для тех, кто хочет углубить навыки и претендовать на более высокие позиции. Базовый английский полезен, но программирование не обязательно для старта.

🏆Возможности стажировки и трудоустройства

Программа позволяет начать карьеру в ручном тестировании уже через 2 месяца обучения, на фрилансе или в найме.

Выпускники трека Junior могут начать карьеру младших QA-инженеров (медианная зарплата около 76 000 рублей), а трека Middle — на более сложные роли с зарплатой от 142 000 рублей.

💸 Стоимость и условия участия

Стоимость зависит от трека (цены указаны с учетом скидки 40%):

• Ручное тестирование: 56 700 рублей (или 2 487 рублей/мес. на 24 месяца)
• QA-инженер уровня Junior: 105 000 рублей (или 3 070 рублей/мес. на 36 месяцев).
• QA-инженер уровня Middle: 130 500 рублей (или 3 816 рублей/мес. на 36 месяцев).

Для поступления нужно подать заявку через сайт, вступительных тестов нет. Возможен возврат средств в течение 7 дней, если курс не подошел.

Как выбрать правильный курс под себя?

Выбор IT-курса в 2025 году зависит от ваших интересов, доступного времени и бюджета. Собрали таблицу, чтобы помочь сориентироваться среди представленных программ.

FAQ: частые вопросы от новичков

Можно ли войти в IT без высшего образования?

Да, можно. Но в некоторых крупных компаниях или госструктурах формальное образование может быть требованием. Если нет профильного образования, стоит выбирать курсы с сильной практической базой и поддержкой трудоустройства.

Реально ли устроиться после курсов?

Да, но результат зависит от трёх факторов: качества курса, вашей активности и текущего спроса на рынке труда.

Что выбрать: универсальный курс или узкую специализацию?

Зависит от вашей подготовки:

• Универсальный курс: подходит новичкам. Дает обзор направлений, помогая выбрать специализацию. Минус — знания менее глубокие.
• Узкая специализация: для тех, кто знает, чего хочет. Дает глубокие навыки для конкретной роли, но требует начальной базы или четкой цели.

Так НЕ надо:

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

Новичкам лучше начать с универсального курса, чтобы понять рынок, а затем углубиться в нишу.

В мире, где большинство успешных атак происходит из-за банальных ошибок вроде слабых паролей или непропатченного софта, находятся «особые» экземпляры. Те, кто взламывает дорожные знаки, чтобы предупредить о зомби-апокалипсисе, крадет данные клиентов, работая в отделе кибербезопасности, оставляет цифровые отпечатки там, где даже новичок догадался бы их удалить.

Эти семь историй — не просто сборник курьезов. Они наглядно показывают: главная уязвимость любой системы (не обязательно цифровой) — человеческая глупость. И хорошо, что хотя бы некоторые злоумышленники тоже подчиняются этому правилу.

Семерка самых нелепых хакерских атак

Хакерские атаки обычно ассоциируются с высокотехнологичными схемами и тонкими методами взлома, но иногда злоумышленники совершают настолько абсурдные вещи, что остается только разводить руками. Одни попадаются из-за детских ошибок, другие — из-за нелепой самоуверенности, третьи умудряются навредить сами себе.

Перед вами семь самых нелепых и странных кибератак в истории — от «Годзиллы» на дорожных знаках до злоумышленников, загрузивших собственную биометрию в систему безопасности.

Взлом казино через аквариум

В 2017 году один из западных игорных домов (название до сих пор не раскрыто) стал жертвой атаки, которая больше похожа на сценарий абсурдного кибертриллера. Злоумышленники пробрались в сеть казино… через аквариум. Обычный, с рыбками.

IoT-термометр как дыра в безопасности

В холле заведения стоял «умный» аквариум с подключенными датчиками — они следили за температурой воды, уровнем чистоты и даже автоматически сбрасывали корм. Казалось бы, безобидная техника для ухода за рыбками. Но проблема в том, что эти сенсоры были частью внутренней сети казино.

Хакеры нашли уязвимость в IoT-устройстве (скорее всего, использовали стандартный пароль или эксплойт для устаревшей прошивки) и через него проникли в систему. Как позже рассказали эксперты, взломщики не просто получили доступ к аквариуму — они провели разведку, нашли другие слабые места и добрались до базы данных высокодоходных клиентов — так называемых «китов» (тоже улов своего рода).

10 ГБ данных и финский сервер

Зараженный термометр стал точкой входа, но дальше атака развивалась уже по классическому сценарию:

• сканирование сети — хакеры искали узлы с уязвимостями;
• перемещение по системе — получив привилегии, они добрались до ценных данных;
• эксфильтрация — украденная информация (около 10 ГБ) ушла на сервер в Финляндии.

Самое забавное — после этого следы обрываются. Данные не всплыли в даркнете, их не пытались продать. Возможно, это была разведка перед более масштабной атакой, но сами злоумышленники так и не объявились. Спрашивается: зачем?

Почему это вообще сработало:

• Безопасность IoT в 2017 году была мифом. Умные устройства были в новинку, их редко обновляли, защищали слабыми паролями или просто забывали изолировать от корпоративной сети.
• Человеческий фактор. Кто-то в казино решил, что датчик для рыб не нуждается в серьезной защите. Ошибка.
• Отсутствие сегментации сети. Аквариум оказался в той же сети, что и база с данными клиентов.

Что изменилось с тех пор

Случай с казино стал хрестоматийным примером рисков IoT. Сейчас компании чаще изолируют умные устройства в отдельных сегментах сети, запрещают дефолтные пароли и мониторят аномальную активность.

Но проблема не исчезла. В 2021 году, например, хакеры взломали систему очистки бассейна в отеле через уязвимый контроллер — и снова получили доступ к внутренним серверам.

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

Соискатель с креативным подходом

В 2010 году венгерский программист Аттила Немет совершил, пожалуй, самый нелепый карьерный маневр в истории киберпреступлений. Вместо того чтобы отправить резюме в отдел кадров, он взломал систему безопасности сети отелей Marriott — чтобы потом предложить свои услуги по ее защите. Получилось не совсем так, как он планировал.

Вирус вместо сопроводительного письма

25-летний Немет, судя по всему, искренне считал себя «белым хакером». Его план выглядел так:

1. Взломать Marriott, показав уязвимости.
2. Предложить компании свои услуги по устранению этих дыр.
3. Получить работу в отделе кибербезопасности.

Для первого пункта он выбрал классическую схему: фишинговые письма с вредоносными вложениями. Кто-то из сотрудников отеля открыл файл — и Немет получил доступ к внутренним системам. Он скопировал конфиденциальные данные, включая информацию о клиентах, но не стал их продавать или публиковать. Вместо этого хакер связался с Marriott и… предложил себя в качестве спасителя.

«Ваша защита слабая — возьмите меня на работу»

По версии следствия, Немет напрямую заявил представителям компании: он готов раскрыть все уязвимости, если его возьмут в штат. В Marriott идею не оценили. Вместо HR-менеджера с ним начал переписку сотрудник Секретной службы США, представившись «заинтересованным руководителем».

Хакер, не заметив подвоха, подробно описал методы взлома и даже согласился прилететь в США для личной встречи. В аэропорту его ждали не потенциальные коллеги, а полиция.

Почему это провалилось:

• Криминал ≠ пентест. Настоящие «этичные хакеры» не крадут данные перед тем, как предложить услуги.
• Наивность. Немет всерьез верил, что компания простит взлом ради его навыков.
• Юридическая безграмотность. Венгр не учел, что в США за такое сажают, даже если «хотел как лучше».

Немета приговорили к 2,5 годам тюрьмы — относительно мягко, учитывая потенциальный срок за кражу данных. Marriott потратил около $1 млн на расследование и усиление защиты. Сам хакер, выйдя на свободу, исчез из публичного поля. По некоторым данным, он все же устроился в IT — но уже без креативных «испытательных заданий».

Что было не так с его планом?

Эксперты отмечают несколько фатальных просчетов:

• Нелегальный вход. Даже если цель благая, несанкционированный доступ остается преступлением.
• Доказательства кражи. Скопировав данные, Немет автоматически стал нарушителем закона — никакие благие намерения это не отменяли.
• Доверие к анонимам. Переписка с Marriott велась через анонимные сервисы, но хакер почему-то поверил, что это официальные представители.

Как надо было поступить? Если бы Немет действительно хотел помочь и устроиться на работу, ему стоило:

1. Найти уязвимости, не получая доступа к данным.
2. Связаться через официальный канал с ответственными за безопасность.
3. Предложить исправления, приложив резюме.

Так делают настоящие исследователи — и их не арестовывают в аэропортах.

Мораль для соискателей

Эта история — отличный пример того, как не стоит искать работу в кибербезопасности. Хотите показать навыки? Участвуйте в баг-баунти программах, где взлом разрешен правилами. Мечтаете о карьере «белого хакера»? Получайте сертификаты, а не судимости.

Немету повезло: отделался небольшим сроком. Со следующим «креативщиком» могут поступить гораздо жестче.

Тупейший взлом в истории: просчитались, но где?

В 2018 году группа «киберпреступников» (если их можно так назвать) совершила то, что эксперты единогласно признали самым идиотским взломом десятилетия. Их план выглядел как сценарий для пародийного фильма: чтобы украсть товары со склада, они… загрузили свои отпечатки пальцев в охраняемую базу данных.

Хакеры против сканеров: кто кого?

Все началось с того, что преступники нацелились на склады компании, производящей предметы роскоши. Система безопасности использовала биометрические сканеры — без правильного отпечатка пальца внутрь не попасть.

Первая идея была в духе голливудских блокбастеров: отключить сканеры удаленно. Но тут злоумышленников ждало разочарование. Оказалось, что сканеры контролируются ИИ, который заметит любые манипуляции, а физическое отключение сразу вызовет тревогу. Тогда группа перешла к «плану Б» — и вот здесь началось самое интересное.

«Давайте добавим свои отпечатки в базу!»

Вместо того чтобы искать обходные пути, хакеры решили действовать напролом:

1. Взломали базу данных с отпечатками сотрудников.
2. Удалили несколько «лишних» слепков.
3. Загрузили туда свои собственные пальцы.

Логика была проста: сканер запрашивает базу, видит «своих» и открывает дверь. Что могло пойти не так?

Почему это был худший план в истории:

1. Отпечатки — это улика. В отличие от анонимных логинов, пальцы нельзя сменить или стереть.
2. База синхронизировалась с архивами. Удаленные отпечатки не исчезли навсегда — их восстановили за минуты.
3. Сотрудники заметили пропажу. Когда люди перестали проходить сканеры, охрана забеспокоилась раньше, чем воры добрались до склада.

Система безопасности компании не просто хранила отпечатки — она вела журнал всех изменений. Как только хакеры загрузили свои данные, ИИ отметил неавторизованный доступ к базе, подозрительные правки и самое главное — новые отпечатки, которых нет в кадровых документах. Полиция сравнила свежие «слепки» с криминальной базой и нашла полное совпадение. Всех участников группы задержали в течение суток.

Что не так с их логикой?

Эксперты до сих пор удивляются, как вообще можно было придумать такой план:

• Биометрия = паспорт. Даже начинающие хакеры знают: подделывать отпечатки — все равно что оставлять автограф на месте преступления.
• Резервные копии. Любая серьезная система делает бэкапы. Удалить данные навсегда практически невозможно.
• Слишком много шагов. Проще было взломать дверь кувалдой, чем лезть в базу.

Что стало с «гениями»:

• Главарь группы получил 4 года за взлом и кражу данных.
• Компания усилила защиту, добавив двухфакторную аутентификацию для доступа к биометрии.
• Этот случай теперь разбирают на курсах кибербезопасности как пример «как не надо делать».

Мораль для будущих хакеров: Если ваш план включает пункт «загружаем свои отпечатки», он точно провалится. Иногда старомодный взлом замка — куда более разумный выбор.

Рок против ядерки: как хакеры заставили ядерный объект играть AC/DC

Если бы кто-то в 2012 году предложил иранским инженерам послушать хард-рок вместо ночной смены, они бы наверняка отказались. Но хакеры не спрашивали разрешения.

Летом того года на двух ядерных объектах Ирана внезапно заиграла «Thunderstruck» — культовая песня легендарной группы AC/DC. Громкость была выставлена на максимум, динамики орали «THUN-DAH!» в ночной тишине, а персонал никак не мог это остановить. Так, вирус Stuxnet, уже хорошо известный в мире кибербезопасности, добавил к своей репутации еще и музыкальный троллинг.

Взлом с саундтреком

Stuxnet — один из самых сложных червей в истории. Его создавали для физического разрушения оборудования: он менял скорость вращения центрифуг, на которых иранцы обогащают уран, выводя их из строя, и маскировал атаку, подделывая данные мониторинга. Но в какой-то момент кто-то решил, что просто ломать машины — скучно.

Анонимный сотрудник иранской АЭС написал исследователю Микко Хиппонену: система управления периодически отключалась, а из динамиков гремел AC/DC. Тегеран официально отрицал инцидент, но детали всплыли в переписке техников. Вирус явно модифицировали — помимо основной нагрузки, он включал медиаплеер и запускал трек в случайное время.

Почему именно «Thunderstruck»? Возможно, из-за названия: «Пораженный громом» звучало как намек на ядерный удар. Или потому, что гитарный рифф идеально подходил для психологического давления.

Кто стоял за атакой?

Stuxnet приписывают совместной разработке США и Израиля (операция «Олимпийские игры»). Но музыкальный «апгрейд» — дело рук других исполнителей.

Эксперты предполагают, что это могли сделать:

• гражданские хакеры — в знак протеста против ядерной программы;
• внутренние саботажники — чтобы деморализовать персонал;
• сами разработчики Stuxnet — в качестве «пасхального яйца».

Интересно, что атака совпала с ужесточением санкций против Ирана. Громкий рок стал своеобразным медийным сигналом: «Мы контролируем ваши системы».

Обычно хакеры стараются оставаться незамеченными. Здесь же они:

• использовали уязвимость Windows (CVE-2010-2568) для распространения;
• внедрили двойную нагрузку: саботаж плюс звуковое воздействие;
• не стали скрывать факт взлома — будто хотели, чтобы об этом говорили.

Для воспроизведения музыки вирус либо содержал MP-файл внутри кода, либо скачивал его с зараженного сервера. Версия с AC/DC так и не была найдена в открытых образцах Stuxnet — возможно, ее «дорабатывали» уже на месте.

Последствия: смех или паранойя?

Иранские власти заявили, что атака не нанесла ущерба. Но психологический эффект переоценить сложно:

• персонал не мог отключить музыку — только глушил динамики физически;
• трек включался ночью, нарушая режим работы;
• слухи о взломе подрывали доверие к системе безопасности.

Этот случай вошел в историю не только из-за технической стороны, но и из-за абсурдности. Хакеры доказали: даже в кибервойне есть место черному юмору.

Stuxnet стал первым вирусом, который физически разрушал инфраструктуру. А его музыкальная версия показала, что хакеры умеют добывать не только данные, но и портить нервы. Говорят, после этого случая иранские ядерные объекты перешли на компьютеры без звуковых карт. Но это уже другая история.

«Годзилла нападает!»: цифровой хаос на дорогах США

В 2014 году водители в Сан-Франциско получили необычное предупреждение: электронное табло на трассе внезапно замигало сообщением «GODZILLA ATTACK – TURN BACK!». Никакой паники не случилось — большинство решило, что это чья-то шутка. Но за этим стояла реальная хакерская атака, которая вскрыла уязвимости критической инфраструктуры.

Как взламывали дорожные знаки

Электронные дорожные табло в США управлялись (а возможно, управляются до сих пор) через примитивные системы, часто с заводскими паролями вроде «admin» или «1234». Хакеры, обнаружившие эту лазейку, подключались к знакам через открытые порты или уязвимости в протоколах. Иногда даже не требовалось сложных инструментов — достаточно было мобильного модема и стандартного ПО для управления сетевыми устройствами.

После взлома злоумышленники меняли сообщения на абсурдные: предупреждали о зомби-апокалипсисе, просили «спасти заложников на фабрике знаков» или просто выводили бессмысленный набор символов. В Техасе, например, однажды появилось сообщение: «СЛЕДИТЕ ЗА ДОРОГОЙ, А НЕ ЗА ТЕЛЕФОНОМ» — ироничный намек на проблему невнимательности, которая как раз и позволила хакерам провести атаку.

Почему это стало возможным?

Основная причина — беспечность муниципальных служб. Многие дорожные системы десятилетиями работали на устаревшем ПО, а пароли к ним никогда не менялись. Как позже выяснилось, часть оборудования даже не была защищена брандмауэрами.

Федеральное управление автомобильных дорог США (FHWA) после инцидента выпустило рекомендации по усилению безопасности, но исправлять ситуацию пришлось годами. В 2016 году исследователи из Университета Мичигана провели аудит дорожной инфраструктуры и обнаружили, что 40% систем по-прежнему уязвимы к простейшим атакам.

Последствия и уроки

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

Сейчас подобные взломы стали редкостью, но не исчезли полностью. В 2020 году в Огайо хакеры вывели на табло фразу «COVID-19 — это обман», а в 2022-м в Калифорнии знаки призывали «готовиться к вторжению пришельцев».

Главный вывод прост: даже самые невинные устройства, подключенные к сети, могут стать оружием в руках злоумышленников. И если дорожные знаки взламывают ради шутки, то что мешает кому-то устроить настоящий хаос?

«Этичный хакер» с двойной жизнью: как специалист по безопасности стал киберпреступником

Пепейн Ван дер Стап выглядел идеальным кандидатом для работы в сфере кибербезопасности — молодой, талантливый, увлеченный технологиями. Днем он помогал компаниям защищать данные, а ночью взламывал их, сливая конфиденциальную информацию на даркнет-форумы. Его арест в 2023 году стал одним из самых громких случаев двойной игры в IT-индустрии.

Как его поймали

Все началось с жалобы амстердамской компании, которая обнаружила утечку данных. Расследование привело к Ван дер Стапу — сотруднику Hadrian Security, фирмы, специализирующейся на пентестах (тестировании систем безопасности) и защите от кибератак. Злая ирония в том, что он сам годами использовал те же инструменты, которые по задумке должны были защищать системы от взлома.

Следствие выяснило, что с 2020 по 2023 год оборотень с ноутбуком и его сообщники взломали десятки компаний, вымогали деньги под угрозой утечки данных и заработали на этом более 2,6 млн евро. При обыске у Ван дер Стапа нашли базы с персональными данными миллионов людей, готовые для продажи на RaidForums и BreachForums — двух крупнейших хакерских площадках, ныне закрытых.

Почему он это делал?

В интервью DataBreaches.net Ван дер Стап утверждал, что начал заниматься взломами до работы в кибербезопасности, а потом «хотел завязать». Но цифры говорят обратное: его активность совпадала с периодом трудоустройства в Hadrian Security. Возможно, доступ к внутренним данным клиентов сделал атаки проще.

Его мотивы банальны — деньги и азарт. Он продавал украденные данные, торговал доступом к корпоративным сетям и даже консультировал других хакеров. При этом успел поработать волонтером в Голландском институте раскрытия уязвимостей (DIVD), что добавляет ситуации еще немного абсурда.

Что не сработало в его схеме

Главная ошибка Ван дер Стапа — уверенность в анонимности. Он использовал ники вроде «Espeon» и «Rekt», но криптовалютные транзакции и логи подключений его выдали. В 2023 году правоохранители синхронизировали данные с закрытых форумов и вышли на него.

Еще один провал — масштаб. Он не ограничился мелкими взломами, а атаковал крупные компании, привлекая внимание регуляторов. Когда ущерб исчисляется миллионами, следствие действует жестче.

Последствия и уроки

Суд дал ему 4 года тюрьмы. Но важнее другое: случай показал, как легко «белые» хакеры могут скатиться в преступность. Компании до сих пор плохо проверяют сотрудников, работающих с критической инфраструктурой.

После этого скандала в Нидерландах ужесточили контроль за специалистами по кибербезопасности. Например, Hadrian Security ввела аудит действий сотрудников, а DIVD теперь требует раскрытия прошлой активности волонтеров.

Как хакеры качали топливо с АЗС обычным пультом

В 2019 году во Франции раскрыли аферу, больше похожую на сценарий криминальной комедии, чем на реальное преступление. Группа из пяти человек за год украла более 120 тысяч литров бензина, используя… обычный пульт управления заправочной колонкой.

Пароль «0000» — мечта хакера

Все началось с того, что злоумышленники обнаружили: на некоторых АЗС Total топливные колонки защищены стандартным PIN-кодом «0000». Персонал заправок не удосужился его изменить, а производитель оборудования не требовал обязательной смены пароля при вводе в эксплуатацию.

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

Группа работала слаженно. Первый автомобиль подъезжал к АЗС – водитель с помощью пульта «взламывал» колонку. Затем подъезжал фургон с цистерной и закачивал до 3000 литров за раз.

Украденное топливо сбывали через соцсети по заниженным ценам. За год схема принесла им около $170 000, пока полиция не вышла на след. В этом случае тупыми оказались не столько хакеры, которые не особенно даже скрывались, а сотрудники безопасности, допустившие подобный беспредел. Тупым был способ, но не результат.

Почему это сработало:

• Халатность — Total подтвердила, что на оборудовании использовались заводские настройки.
• Отсутствие контроля — на небольших АЗС пропажу замечали только через недели.
• Уязвимость ПО — колонки считали «просто железом», но их софт оказался уязвим.

Всех пятерых задержали за кражу и взлом. Total экстренно обновила прошивки и обязала менять пароли.

Как оказалось, это был не единичный подобный случай. В 2021 году в США хакеры через уязвимость в ПО вызвали дефицит бензина на Восточном побережье. А в 2023-м исследования показали, что 20% европейских АЗС до сих пор используют устаревшее ПО.

Технические детали

Преступники использовали пульт Gilbarco Passport — стандартное устройство для обслуживания колонок. Его можно было купить на eBay за $300-500. Подключившись через ИК-порт, система запрашивала PIN-код, который часто оставался заводским.

Новые модели уже имели принудительную смену пароля при первом запуске, ограничение попыток ввода кода, систему оповещений о подозрительной активности.

Как защититься?

Владельцам АЗС эксперты рекомендуют обязательно менять стандартные пароли, регулярно обновлять ПО, устанавливать камеры с аналитикой и сегментировать сеть, изолируя колонки.

Этот случай — идеальный пример, как халатность открывает двери для примитивных, но прибыльных атак. Если ваш бизнес использует IoT-устройства, проверьте — возможно, они до сих пор на пароле «0000»?

Итоги

Эти истории доказывают: даже в мире высоких технологий человеческий фактор остается главной уязвимостью. Хакеры, о которых мы рассказали, обладали навыками, но им не хватило элементарной логики. Одни забывали скрыть следы, другие выбирали абсурдные цели, третьи — сами себя подставляли.

Главный урок? Безопасность — это не только сложные алгоритмы, но и здравый смысл. И если даже злоумышленники порой действуют настолько нелепо, то компаниям точно не стоит расслабляться. В конце концов, следующий «гений» может оказаться чуть удачливее — или чуть менее смешным.

Когда код уже не компилится, остаётся только смеяться. Самые айтишные мемы тут.

ЦЕЛЕНАПРАВЛЕННЫЕ АТАКИ (APT-ГРУППЫ)

APT-атака (Advanced Persistent Threat — продолжительная атака повышенной сложности) — это длительная, целенаправленная и скрытая кибератака, при которой злоумышленники получают доступ к информационным системам и остаются незамеченными, чтобы собрать конфиденциальные данные или нанести другой ущерб.

APT-атаки используются против ключевых секторов: промышленность, финансы, энергетика и госсектор. В 2024–2025 особенно активными стали китайские, северокорейские и неизвестные группировки. Целенаправленные атаки — особая категория угроз, исключительно против конкретной организации или государственного учреждения.

Цель злоумышленников — получить разные конфиденциальные сведения: коммерческую тайну, персональные данные пользователей, материалы под грифом «секретно», данные о стеке ИТ-решений или оборудовании, стратегические документы. Нередко объектом атаки становятся системы жизнеобеспечения компаний, веб-сайты организаций или отдельные элементы ИТ-инфраструктуры.

Как это работает

Проникнув внутрь защищенного периметра предприятия, преступники активно исследуют само устройство, через которое удалось организовать доступ, и определяют степень уязвимости используемых в компании технологий и сервисов. Важнейшую роль играет сбор внутренних данных, находящихся на компьютерах сотрудников: файлы конфигурации, личные профили, базы данных, хранящиеся локально. Подобная информация позволяет злоумышленникам глубже понимать структуру организации и планировать дальнейшие шаги атаки.

Как распознать и защититься

Фишинговые электронные письма

Чтобы получить несанкционированный доступ к корпоративным сетям, киберпреступники часто прибегают к использованию целевого фишинга. Они проводят небольшое «расследование» и получают все нужные данные, чтобы придумать привлекательные для сотрудников заголовки писем. В таких посланиях могут быть вредоносные вложения или ссылки с программами-шпионами, которые позволяют злоумышленникам контролировать систему. Лучшая защита от них — повысить осведомленность сотрудников и регулярно обучать их кибербезопасности, так как подходы атак постоянно меняются.

Скомпрометированные учетные записи

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

Чтобы не допустить целенаправленные атаки, нужно сегментировать сеть (разделять инфраструктуру на изолированные зоны с различными уровнями доверия, доступ между которыми строго контролируется, чтобы ограничить движение трафика) и контролировать привилегии доступа, а также внедрять Zero Trust политику.

Перемещение данных

Цель злоумышленников — похитить критически важную для бизнеса или госсектора информацию. Поэтому любые массовые передачи значительных объемов данных, перемещение документов между серверами или изменение места хранения файла заслуживают пристального внимания. Необходимо следить за внутренними потоками данных, а также подключением внешних устройств и активностью отправки данных за пределы защищенного корпоративного периметра. Регулярно отслеживайте соединения с внешними ресурсами, обращайте особое внимание на нестандартные подключения.

ШИФРОВАЛЬЩИКИ / ВЫМОГАТЕЛИ (RANSOMWARE)

Подобные программы продолжают вызывать сбои работы предприятий, особенно в секторах ритейла и промышленности. В прошлом году число атак с помощью шифровальщиков увеличилось на 44%.

Примечательно, что в каждом десятом таком инциденте злоумышленников интересовала не кража данных с целью получения выкупа, а намеренное нанесение максимального вреда выбранному для атаки объекту.

Цели — шантаж и нарушение работы сервисов. С помощью вирусов-вымогателей киберпреступники ежегодно зарабатывают порядка 2 миллиардов долларов. В большинстве случаев злоумышленники, используя вирусы-шифровальщики, блокируют доступ к важным данным на устройстве, вынуждая платить за восстановление. Обычно такие программы запрещают владельцам пользоваться собственными файлами и информацией до момента уплаты требуемого выкупа. Однако обещанный возврат доступа не гарантируется — зачастую злоумышленники нарушают данное слово.

Наряду с прямыми денежными убытками, жертвы сталкиваются с серьезными последствиями в виде сбоев в работе ИТ-инфраструктуры, падения продуктивности и сильного психологического напряжения. Дополнительно киберпреступники нередко шантажируют потерпевших раскрытием приватных данных или продажей ценной информации третьим лицам.

Как это работает

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

Как распознать и защититься:

• Один из первых признаков заражения вирусом-вымогателем — потеря доступа к файлам, базам и документам. Пользователь замечает, что некоторые из них неожиданно перестали открываться или требуют ввода пароля несмотря на отсутствие настроек парольной защиты.
• Другой яркий признак — появление незнакомых расширений у инфицированных файлов, например, “.locked” или “.encrypted”. При этом обычные программы перестают распознавать и открывать такие объекты.
• Кроме того, в затронутых папках начинают появляться специальные инструкции, подробно объясняющие процедуру восстановления данных и требования к выплате компенсации за разблокировку.
• Рабочий стол компьютера также может подвергнуться изменениям: стандартная картинка заменяется сообщением с предупреждением о шифровании данных и требованиями о предоставлении выкупа.
• Наконец, антивирусные решения и прочие инструменты информационной безопасности могут подавать тревожные сигналы о наличии подозрительных процессов и действий в операционной системе.

Во всех перечисленных случаях не рекомендую идти на поводу у злоумышленников и спешить уплачивать требуемую сумму. Сначала проверьте в открытом доступе, нет ли декриптора, который помог бы вам расшифровать файлы. Есть как платные, так и бесплатные программы, однако не все они могут расшифровать изощренные пароли вредителей. Лучше вложить средства в превентивные меры защиты от действий RANSOMWARE. Например:

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

АТАКИ НА ЦЕПОЧКУ ПОСТАВОК (SUPPLY CHAIN ATTACKS)

Прогнозируется, что к 2031 году убытки компаний от атак на цепочки поставок программного обеспечения увеличатся до колоссальных 138 миллиардов долларов ежегодно, превысив показатели предыдущих лет: 60 миллиардов долларов в 2025-м и 46 миллиардов долларов в 2023 году, учитывая постоянный годовой прирост на 15%.

Supply chain attack — относительно новый тип угроз, который нацелен на разработчиков ПО и поставщиков услуг или технологий. Они вошли в перечень наиболее распространенных угроз только в прошлом году из-за увеличившегося в три раза числа инцидентов по сравнению с 2023 годом.

Злоумышленники используют эти атаки, чтобы получить доступ к исходному коду, процессам разработки или механизмам обновления и распространить вредоносное ПО, заразив установленные программы.

Цели:

• Дестабилизация деятельности компании — утечка конфиденциальных данных способна нанести удар по репутации и финансам, создать юридические риски.
• Общественная реакция — распространение фейков или компромата через соцсети формирует негативный фон вокруг компании и подрывает доверие клиентов.
• Информационное давление на сотрудников — персонал компании подвергается угрозам раскрытия личной информации или шантажу, вынуждая руководство идти на уступки ради сохранения репутации.
• Шифрование данных и вымогательство — установка вредоносных программ-шифровальщиков приводит к блокировке критичных информационных активов, лишая предприятие возможности полноценно функционировать вплоть до выплаты крупного выкупа.

Как это работает

При осуществлении атаки на поставщиков ПО злоумышленники выбирают путь наименьшего сопротивления, проникая в защищенную сеть через слабое звено — небольшую фирму-подрядчика или разработчика программного обеспечения. Подобные нападения осуществляются двумя основными способами:

1. Компрометация службы или продукта: нападение на мелких поставщиков или партнеров, обладающих низким уровнем киберзащиты, позволяющим злоумышленнику незаметно внедряться в инфраструктуру основной фирмы. Типичный пример — компрометация ПО компании на аутсорсе, работающей с более крупным бизнесом (который и становится конечной целью атаки).
2. Внедрение вредоносного кода непосредственно в само ПО, распространяемое среди множества конечных потребителей. Пользователи, устанавливающие обновление, сами открывают дверь в свою ИТ-инфраструктуру для дальнейших проблем.

Как распознать и защититься

Опознать supply chain-атаку можно, если внимательно следить за сетевой активностью — она может показать необычные подключения или передачу больших объёмов данных. Также важно постоянно мониторить действия пользователей и систем — подозрительное поведение, редкие попытки доступа или запуск необычных процессов могут быть сигналом. Ещё один способ — отслеживать изменения в файлах, чтобы заметить несанкционированные вмешательства.

Вот несколько превентивных мер, чтобы защититься от supply chain attack:

• Регулярно проверяйте и контролируйте контрагентов, проводите обязательную верификацию.
• Используйте SBOM (Software Bill of Materials — перечень всех модулей и библиотек, необходимых для сборки программного продукта, а также указания их связи друг с другом). Он помогает команде видеть, где могут скрываться уязвимости — и заранее обновлять или заменять слабые места до того, как они станут проблемой.
• Реализовывайте политику обновлений с инспекцией. Например, отключите автоматическое обновление системы и программного обеспечения, с осторожностью устанавливайте апдейты вручную и тщательно тестируйте их работу перед использованием.
• Сегментируйте бизнес-процессы: так вы минимизируете возможные последствия кибератак: если одна зона подвергнется воздействию, остальные останутся надежно изолированными и сохранят свою безопасность. Сегментация помогает навести порядок в доступах: каждый видит только то, что нужно для работы — это снижает риск утечек и ошибок.

Сегодня компании и организации в РФ сталкиваются не с одной, а со множеством киберугроз, которые становятся только изощреннее. Но просто реагировать на инциденты недостаточно: нужно мониторить, работать на опережение и минимизировать риски. Поэтому подход к кибербезопасности должен быть стратегическим, техническим и операционным одновременно. Кольцевая защита, Zero Trust, повышение осведомленности персонала и контроль подрядчиков — то, без чего не обойтись.