И снова привет! Продолжаем наши похождения по удалениям.
Мы уже обсудили две важные вещи:
- DELETE — тяжёлая операция;
- после DELETE в базе остаётся мусор.

Возникает логичный вопрос: а как тогда удалять?
И ответ на него одновременно простой и нет — soft delete.


Что такое soft delete
В этой методике мы не удаляем строку, а просто помечаем её как удалённую.

То есть вместо:

DELETE FROM messages WHERE id = 993;

мы делаем:

UPDATE messages
SET deleted_at = now()
WHERE id = 993;

Для приложения запись сразу считается удалённой,
но физически она остаётся в таблице.

Почему это дешевле
1. Мы почти не трогаем индексы
Поле deleted_at обычно не входит в основные индексы,
а значит — меньше модификаций страниц и меньше дисковых операций.

2. Меньше WAL
UPDATE одного поля пишет меньше данных в WAL,
что снижает нагрузку на диск и упрощает репликацию.

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

Почему deleted_at, а не is_deleted
Чаще всего используют именно deleted_at timestamptz, потому что:
- известно, когда запись была удалена
- можно откатить удаление по дате
- удобно строить TTL-чистку на основе времени удаления.

«Но ведь строки остаются в таблице»
Да. И в этом весь смысл.

Мы разделяем удаление на два этапа:
1. Быстро и дёшево убираем данные из пользовательского флоу в любой момент времени.
2. Медленно и аккуратно удаляем их физически позже —
например, ночью, когда система нагружена меньше.

И небольшой приятный бонус
Когда пользователь пишет: «Я СЛУЧАЙНО НАЖАЛ УДАЛИТЬ, ВЕРНИТЕ» — у вас уже есть TTL-окно, в которое это можно спокойно сделать 😉

Ребят, среда again

Мы пережили среду. Не сказать, что это было сложно, но — пережили.
А значит, идём дальше в нашем приключении по столбцам.

Мы уже научились дёшево “удалять” данные, используя методику soft delete. Но, как это обычно бывает, тут нас ждёт новый подводный камень.
Если просто начать добавлять deleted_at IS NULL в запросы, то на больших объёмах данных мы можем не ускориться, а вполне себе замедлиться.

Почему?
Потому что мы поменяли паттерн чтения, и внезапно перестали эффективно попадать в индекс.
Звучит не очень понятно — давайте разберёмся на примере.

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

SELECT *
FROM messages
WHERE chat_id = 42
ORDER BY created_at;

Под него идеально подходит индекс: (chat_id, created_at)
Быстро, красиво, эффективно.

А теперь добавляем soft delete
Как только появляется условие: AND deleted_at IS NULL всё начинает меняться. PostgreSQL сначала находит строки по индексу, а потом вынужден проверять deleted_at IS NULL отдельно
На больших таблицах это означает лишнюю работу, а иногда — почти последовательное сканирование.
И вот вы уже вроде как оптимизировали удаление, и сломали чтение.


Но и тут есть решение — partial index (частичный индекс)
Мы можем создать индекс только по живым строкам:

CREATE INDEX idx_messages_live
ON messages (chat_id, created_at)
WHERE deleted_at IS NULL;

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

Важный момент
Partial index — это не опциональная оптимизация, а обязательная часть архитектуры soft delete.

Очень частая ошибка выглядит так: «Мы внедрили soft delete, но база всё равно тормозит».

А потом выясняется, что:
- SELECT сканирует кучу удалённых строк;
- индекс есть, но он не помогает

Если коротко

Soft delete отвечает за дешёвую запись.
Partial index — за быструю выборку.

И только вместе они дают тот эффект, ради которого всё это и затевалось.

Итак, мы уже почти полностью прошли путь внедрения soft delete: от замены DELETE-операций до выстраивания индексов.
Но остаётся главный вопрос:

а как вообще выносят мусор?

Ведь строки остаются.
И если их не убирать — таблица рано или поздно превратится в свалку.

На первый взгляд всё кажется простым.
Ну правда, что может пойти не так?

DELETE FROM messages
WHERE deleted_at < now() - interval '30 days';

Но как бы мило и аккуратно ни выглядел этот запрос,
на больших объёмах он может сделать очень больно:
- огромный DELETE → всплеск WAL
- долгий и тяжёлый ближайший VACUUM
- просадки по latency
- неожиданные тормоза в живом трафике.

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

Постепенный вынос мусора

В этом случае мусор выносят маленькими порциями.
Типичный подход выглядит так:
- раз в 5 минут
- удаляем 1–5 тысяч строк
- без спешки
- без пиков нагрузки

Пример запроса:

DELETE FROM messages
WHERE id IN (
  SELECT id
  FROM messages
  WHERE deleted_at < now() - interval '30 days'
  ORDER BY deleted_at
  LIMIT 5000
);

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

И главное, что стоит запомнить

Soft delete — это не “никогда не удалять”.
Это “удалять тогда, когда системе удобно”.
Он не является панацеей от всех проблем,
но его разумное использование может сократить их.

С понедельником братья, очередная неделя страданий объявляется открытой

Оба, и снова не пятница, it's wednesday my dudes.

Открыл Ютуб находясь в командировке в Польше...
ТАК ВОТ С ЧЕМ ЕДЯТ КОТЛИН.

Ух, наконец тот самый момент — конец года уже совсем близко. В честь такого можно взять заслуженный отпуск, хотя бы на пару часов и просто выдохнуть.
Год, если честно, был непростой. Очень непростой. АЛО, КТО ВКЛЮЧИЛ ХАРДКОР?
Но при всём этом — хорошего в нём тоже было немало.

Давайте начнём с моего большого личного проектика. Имперский Стражник, твой выход.

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

Что ещё? Я начал чуть активнее работать над каналом, особенно весной. Вы получили прям гору контента — и это далеко не всё. В работе ещё много интересных циклов и отдельных постов, и я правда верю, что смогу их довести до конца.

Давайте вспомним, что канал всё-таки немного авторский. А значит — и обо мне тоже.
Что там по мне? Я живой. Это уже достижение, D:

Во-первых, я закрыл огромную главу жизни и наконец выпустился. Два десятка лет обучения — всё, конец. Свобода)
Во-вторых… я очень долго бился, но всё-таки смог победить. Я ещё ни разу не говорил об этом здесь, но, пожалуй, время пришло.
Я человек с таким «позитивным» здоровьем, что меня уже знают в поликлиниках в лицо. А мои любимки из объединённого военкомата города Москвы решили закрыть глаза и на болячки, и на законы — и выдали мне повестку на отправку к месту службы.

Шесть месяцев шло разбирательство. И вот совсем недавно я наконец смог отстоять законное признание своего состояния и получил категорию «В».
Это было сложно. Долго. Нервно. Без взяток (но и не бесплатно — суды деньги жрут знатно).
Вот как-то так.

А что у нас по ST? Любимок, конечно, забывать нельзя. Но да — в этом году я с ними немного охладил интеракцию.
Когда твой год выглядит как цепочка
зимняя сессия → практика → дипломная → суд с государством,
времени становится катастрофически мало.

Это, думаю, было заметно: я просел и по количеству контента для вас, и по объёму вклада в ST.
Но даже так — сделал немало полезного и важного.

В целом этот год можно смело назвать годом внутрянки и удобства сотрудников. Из-за множества событий в стране пришлось многое менять и перестраивать — и эти процессы до сих пор продолжаются. Про это я, скорее всего, напишу отдельный пост, как только согласую формулировки с NDA.

Вот такой немного безумный год получился.
Через пару часов (или уже завтра) я выпущу отдельный пост о том, как этот год выглядел в цифрах.
А сейчас — хочу просто пожелать вам счастливого Нового года и удачи. Спасибо, что вы здесь.

Никто этого не ждал (5 сбоев Bot Api за 2 дня не считаются), но Telegram наконец выпустил обновление Bot Api которое ещё давно нам обещал!
Как говорится, праздник? Не, не слышали, идём под куранты обновлять ботов и либы.

Возможности для AI (топики и стриминг).
- Теперь в приватных чатах (лички) можно включить разделение на топики. Боты могут соответственно отправлять сообщения и медиа в конкретные топики.
- Добавлен стриминг сообщений по мере генерации текста (через sendMessageDraft)

Подарки и звёзды
- Добавлена возможность получать подарки пользователя и чата через Bot API
- Гибкая фильтрация лимитированных, апгрейд-подарков и подарков из TON.
- Добавлена полная информация о подарках в Bot API включая уникальные цвета, фоны и стили, влияющие на имя пользователя, ответы и превью ссылок.
- Максимальная цена платного медиа увеличена до 25 000 Stars.

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

Ну что ребята, время вернутся на работу/учёбу.

Как проводите первый рабочий день?

Ну что, хеппи бёздей ту ми.

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

Надеюсь, увидимся уже совсем скоро, ведь я очень хочу наконец полноценно ожить и радовать вас интересным и познавательным контентом)