Дорогой DELETE. Типичные ошибки при выполнении массовых операций в высоконагруженных БД PostgreSQL Базы данных и системы хранения

Доклад принят в программу конференции
Николай Самохвалов
Postgres.ai

Основатель Postgres.ai — системы ускорения разработки быстрорастущих проектов на PostgreSQL.

ФУПМ МФТИ, ИСП РАН, специализация «Базы данных».
Более 17 лет работы с различными СУБД, более 13 — с PostgreSQL.

Сооснователь RuPostgres.org (российское PostgreSQL-сообщество, вторая крупнейшая в мире митап-группа о Postgres), Postila.ru, MirTesen.ru, MoiKrug.ru.
Twitter: @postgresmen (много всего о Postgres, БД и около).

nik@postgres.ai
Twitter: @postgresmen

https://Postgres.ai
Тезисы

Основано на реальных событиях.

Когда-нибудь в далёком будущем автоматическое удаление ненужных данных будет одной из важных задач СУБД [1]. Пока же нам самим нужно заботиться об удалении или перемещении ненужных данных на менее дорогие системы хранения.

Допустим, вы решили удалить несколько миллионов строк. Довольно простая задача, особенно если известно условие и есть подходящий индекс. "DELETE FROM table1 WHERE col1 = :value" - что может быть проще, да?

Но всё не так просто, если у вас высокие нагрузки, а каждая минута простоя обходится очень дорого. Очевидный, но необдуманный запуск массового DELETE – то, из-за чего компания внезапно теряет сотни тысяч, а то и миллионы долларов, а инженеры оказываются на грани увольнения...

Мы подробно разберём ситуацию из реальной жизни на примере PostgreSQL, баз среднего размера и нагрузок (несколько TiB данных, десяток тысяч QpS). Посмотрим внимательно, что пошло не так и проанализируем основные "грабли", на которые наступили в этом случае:
- не проверили запрос на полноразмерной таблице или же проверили некорректно,
- не разбили массовую операцию на достаточно короткие транзакции,
- не подумали о локах,
- не мониторили disk IO,
- не дали проверить изменение другим инженерам,
- не слушали DBA, не следили за здоровьем БД и не делали checkpoint tuning.

В процессе я коротко расскажу о платформе Postgres.ai [2] и её открытых компонентах и принципах, внедрение и использование которых как раз помогает устранить описанные выше проблемы при проведении любых операций над БД:
- postgres-checkup, инструмент для автоматического слежения за здоровьем Postgres [3] (представлен на РИТ-2019 [4]),
- artificial DBA Joe [5], позволяющий проверять любые идеи оптимизации запросов на многотерабайтной БД, обеспечивая независимую работу десяткам и даже сотням инженеров,
- artificial DBA Nancy [6], систематизирующая проведение экспериментов над БД (была представлена на Highload++ 2018 [7]).

Вовсе не обязательно использовать именно эти инструменты (хотя, конечно, это очень приветствуется!). Главная идея, усвоения которой я буду добиваться: обязательно, обязательно проверяйте все свои мысли и идеи, используйте правильные данные для принятия решений.

1. Tova Milo. Getting Rid of Data. Keynote at VLDB-2019, https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf
2. Postgres.ai, система поддержки принятия решений для разработчиков и DBA, работающих с PostgreSQL https://postgres.ai
3. postgres-checkup https://gitlab.com/postgres-ai/postgres-checkup
4. Как не «проспать» проблемы в базах данных Postgres: автоматизируем проверку здоровья, РИТ-2019 http://bit.ly/postgres-checkup-rit2018
5. Joe, Slack-бот для оптимизации SQL на полноразмерных БД https://gitlab.com/postgres-ai/joe
6. Nancy CLI, фреймворк для автоматизации экспериментов над БД https://gitlab.com/postgres-ai/nancy
7. Правильный staging для баз данных Postgres, Highload++ 2018 http://bit.ly/nancy-hl2018-2

Бэкенд / другое
,
PostgreSQL
,
Отказоустойчивость
,
Архитектура данных, потоки данных, версионирование
,
Непрерывное развертывание и деплой
,
Администрирование баз данных
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
QA / другое

Другие доклады секции Базы данных и системы хранения