23 августа 2020

SQL 101. Missing parts, или о чем умалчивают в лекциях по базам данных

Всем привет!

В этой заметке пойдёт речь не о самом SQL и какие сложные запросы на нём можно писать, сколько о вопросах производительности и неочевидных моментах в проектировании схем БД.

Предлагаю вам обзор книг, которые я бы очень хотел прочитать ещё в университете до того, как пришлось уже на практике находить тонкий баланс между желаемыми фичами клиентов, масштабируемостью и производительностью MySQL.


БД - сложная вещь, и, как любая сложная вещь, она является "протекающей абстракцией", детали которой вообще неплохо бы знать. Чего стоит только понимание того что умеет делать оптимизатор конкретной БД: какие "очевидные для вас" паттерны эффективной работы с данными он умеет понимать и применять, а какие - нет. Все эти нюансы на практике накладывают существенные ограничения не только на использование индексов (такая же высокоуровневая неспецифицированная абстракция), но и на то, как мы храним данные и какие ограничения придётся наложить на способы поиска данных. В результате, это всё может вылиться в дополнительные согласования аж с непосредственными заказчиками бизнес фич приложения!
Но подождите бежать перетаскивать код внутрь БД или встраивать её в своё приложение. Как минимум стоит начать с того, чтобы пристально изучить ваш текущий инструментарий: профилировка - ваш главный друг в вопросах производительности. Будучи профессионалом, вы вы не можете себе позволять тратить время на оптимизацию того, что не можете измерить.

Конечно, сообщество уже создало источники знаний по типичным граблям, по которым проходят те, чей опыт работы с БД ограничивается только концептуальными знаниями и не больше. Мой, наверно, любимый пример такой "наивной академической простоты" в контексте SQL - использование OFFSET и LIMIT для операций просмотра данных по страницам. В теории оно будет работать, но на практике если вам важна производительность и вы не хотите иметь проблемы с пропусками или дубликатами при конкурентной модификации - так делать не стоит (полезное чтиво: раз, два, три).
Но иногда даже переходящие из методичики в методичку знания играют с будущими разработчиками злую шутку: чего только стоит известный срач о том, почему диаграммы Венна - не самый удачный способ объяснить всю полноту операции JOIN

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

И так, преступим наконец-то к мат части и пойдём от доступного к исчерпывающему.

SQL Antipatterns: Avoiding the Pitfalls of Database Programming. Bill Karwin

Эта книжка - прям готовый сборник достаточно горячих тем, связанных с проектированием схем данных. Она выполнена в следующем стиле: 
  1. Цель, которую хотели достичь.
  2. Как обычно её пытаются решить (антипаттерн).
  3. Какие проблемы создаёт это решение и когда использование антипаттерна может быть оправдано.
  4. Как это стоит делать в подавляющем числе случаев.
Больше всего мне понравились следующие темы:
  • Трюки с полиморфизмом.
  • Трюки с деревьями.
  • Недооценённая польза от использования Foreign Keys в некоторых ситуациях.
  • Хранение перечислений (Enums).
  • Работа с null значениями.
  • Выбор случайных данных из таблицы.

SQL Performance Explained: Everything Developers Need to Know about SQL Performance.  Markus Winand

Достаточно небольшая брошюрка о том как реально устроены индексы, из чего следуют инсайты насчёт того в каких запросах они помогают, а в каких - нет. Упоминаются нюансы работы разных баз данных.

Эта книга по сути печатная версия сайта Use Index, Luke. Честно признаюсь, я перечитывал этот сайт полностью несколько раз, чтобы до конца разобраться в некоторых тонких моментах, но оно того явно стоило.

High Performance MySQL: Optimization, Backups, Replication, and More

Также известная как "MySQL по максимуму".
  • Нюансы про MySQL, какие оптимизации он умеет и какие паттерны работы с выборками может использовать.
  • Инструменты профилирования.
  • Нюансы эксплуатации.

Design Data Intensive Applications. Martin Kleppmann

Упоминаю её тут из-за её глав о репликации и шардировании данных. Она очень помогла не бежать резать базу на куски (синдром "У нас же будет очень много данных!"). Эта книжка вообще может причинить очень много боли наивным читателям, которые думают, что есть простые способы решения казалось бы известных задач в условиях распределённых систем. Многие грезят, что в одну секунду они "просто отскейлятся и всё будет ок". Нет, не будет. И эта книга рассказывает почему и какова реальная цена этого самого "магического скейла".

RTFM!

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

На этом пока всё. Если у вас есть свои избранные книги по MySQL или другим базам - напишите о них в комментариях.

2 комментария:

  1. Основы стоимостной оптимизации - Дж.Льюис
    Вечная книга, не смотря на возраст.

    ОтветитьУдалить
  2. Книга по постгресу: https://postgresql.leopard.in.ua/
    Много устаревшей инфы по 9й версии, но в целом очень полезно для ознакомления с тем как всё устроено внутри

    ОтветитьУдалить