Настало время понемногу рассказывать о том, с чем мы столкнулись в разработке — и что, как мне кажется, будет вам интересно.
(Иронично, конечно, что пост выходит в момент, когда я снова дико занят, потому что кое-кто опять занят юридическими делами. Но ладно, не будем о грустном.)
Помните, в одном из прошлых постов я говорил, что хочу попробовать поработать с ещё более жёстким хайлоадом?
Ну… накаркал.
Как вы знаете, в Стражнике мы модерируем стикеры (и морально готовимся к фото и гифкам). И вот, буквально на днях, нас накрыл такой вал нагрузки, что за короткое время мы обработали 30+ миллионов записей и 8 миллионов файлов.
И где-то между «всё хорошо» и «This is fine» всплыла очень любопытная проблема.
Как у нас устроен флоу обработки:
запись задачи → процессор обрабатывает задачу → сохраняет результаты как файлы → нейронка обрабатывает эти файлы.
Красиво? Да.
Работает? Обычно — да.
Но в тот день нейронка… простаивала. Почти полностью пустая.
А очередь задач — Токио ещё далеко до такого количества записей.
Мы начали разбираться, и выяснилось: у нас дико тормозит удаление строк из таблицы. Самый обычный, самый банальный запрос:
DELETE FROM jobs WHERE id = $1;
То есть не нейронка, не процессинг файлов, не очереди — а DELETE.
И в этот момент у меня в голове всплыло то самое вечное высказывание, которое я слышу когда Telegram в очередной раз показывает удалённое сообщение:
«Мессенджеры не удаляют сообщения — они помечают их как удалённые».
И я подумал: окей, если у нас DELETE начинает душить пайплайн, давайте разберёмся почему так происходит и как жить.
Поэтому встречайте: новый мини-цикл постов!
Мы поговорим о:
- soft delete и hard delete
- о том, почему PostgreSQL на самом деле не удаляет строки сразу
- как устроена под капотом MVCC
- почему UPDATE с флагом бывает дешевле DELETE
- как мессенджеры управляют массивами данных
- что вам лично с этим делать, если у вас миллионы строк и нагрузка растёт
Готовьте свои СУБД, миллионы записей и немного кофе.
Мы начинаем уже завтра.
#devblogHowToDeleteInDatabase #tech