Дорогой DELETE. Типичные ошибки при выполнении массовых операций в высоконагруженных БД PostgreSQL Базы данных и системы хранения
Postgres.ai делает возможным работу с полноразмерными базами данных в CI, значительно улучшая качество разработки и тестирования.
Разрабатываемый компанией открытый инструмент, Database Lab Engine, позволяет создавать полноразмерные клоны баз данных любого размера за секунды. Используя такие клоны, вы можете тестировать изменения, оптимизировать SQL-запросы и быстро развёртывать независимые тестовые стенды.
Вебсайт компании – https://Postgres.ai/ – содержит также SaaS-версию Database Lab.
Кроме этого, эксперты 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