Олег Мифле | System Design, AI, архитектура

Миграция PostgreSQL под нагрузкой: какой вопрос вы зададите первым? Приветик. Я вам задачку принёс) Ниже — сокращённый production-кейс, собранный из нескольких похожих ситуаций, в которых я успел побывать. Цифры и отдельные детали изменены, но ограничения вполне реальные. Есть сервис, который работает круглосуточно и хранит основное состояние в PostgreSQL. База занимает около 1,7 ТБ. В пике приложение обрабатывает примерно 3 500 запросов в секунду, а на стороне PostgreSQL это превращается в 15–20 тысяч запросов. Значительная часть нагрузки связана с записью. Сейчас база работает на одном мастере и двух репликах. Команде нужно перенести её в другой инфраструктурный контур и одновременно перейти на новую мажорную версию PostgreSQL. Полностью остановить трафик нельзя. Ночью нагрузка снижается примерно на треть, но не исчезает. На пиках у реплик иногда растёт лаг, а основной узел периодически упирается в дисковую подсистему. Команда приложения может выкатывать изменения поэтапно. После переключения должен оставаться понятный способ отката. На этом вводные всё. 😀 Предлагать схему миграции пока не нужно. Не требуется писать RFC, выбирать конкретные инструменты или подробно расписывать последовательность переключения. Представьте, что вас подключили к обсуждению и попросили оценить возможные планы. Какой информации вам не хватает до выбора плана? Выберите одну вводную, которую запросили бы первой. Когда несколько вариантов кажутся одинаково важными, выбирайте тот, который способен сразу исключить часть стратегий. В комментариях можно использовать простой формат:

Мне не хватает информации о ________, потому что от неё зависит ________.

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

Привет! Как вы помните, я иногда пишу про конференции и вот опять хочу поделиться мнением про обновление концепции Joker. Ранее это была конференция только для java-разработчиков. Сейчас идея обновилась и думаю, что теперь она будет интересна и актуальна для всего IT-сообщества. Мне прям сильно откликается то, что произошло. На сайте так и написано: «LLM может подсказать чужие кейсы и варианты решений, но нужное решение выбрать всё равно придётся самому». Это то, о чём я пишу и рассказываю всё время, как только кодинг-агенты появились. И вот мне, впервые за долгое время, захотелось даже посетить конфу. Хотя, никогда на этой не был. Мне интересно послушать доклады на темы: - Какие из навыков разработчиков завтра обесценятся, а какие подорожают? Тут я ответ знаю, скорее всего, но взгляд со стороны интересен. - Чем занят тимлид, если планирование и раздачу задач берёт на себя система? - Как перестроить компанию под агентов, а не прикрутить агентов к старой компании? Будто бы уже понятно, что агенты и ллм это больше не "хайп" и что-то новенькое, а уже вполне вошедший в использование инструмент. Местами не зрелый, надо тюнить, править. Но отрицать это уже нельзя. Надеюсь от конфы получить ответы на свои вопросы или подтверждения моим размышлениями.

Привет! Давайте продолжим тему explain в PostgreSQL. Куда смотреть в этом дереве вывода? Как проследить проблему от её начала до самого конца? На самом деле всё несложно, главное знать куда куда смотреть 😳 На гитхаб выложил код примера 💻 https://github.com/olegmifle/yt-explain-example А на Ютубе уже лежит видео 📺 https://youtu.be/dLMHBPLAykA

Привет! Неделя была очень плотной и продуктивной: стартовал мой интенсив + продолжаю вести лекции для студентов Иннополиса, параллельно готовлю ещё много всего. А ещё, на этой неделе, записал видео на тему почему для PostgreSql (да и для любой подобной субд) нормально не применять индекс и откуда планировщик знает о селективности и объеме результата. 📺 Переходи смотреть. 📺 Лайки и комментарии приветствуются 😘

Всем привет. Выкладываю запись стрима про распределенные транзакции на YouTube 📺. Рассказал про сагу и как можно применить темпорал в этом всё. Смотретите, оставляйте комменатрии, лайки. Важно услышать ваше мнение 💋 А так же, со следующей недели стартует мой интенсив по System Design где я буду рассказывать как создавать сложные, отказоустойчивые архитектры. Если для тебя актуальная подготовка к интервью или хочешь прокачать свои архитектурные навыки, то я жду тебя на интенсиве! Сейчас действие скидки закончилось, но ты можешь написать мне в ЛС и мы договоримся 🎩

⚠️Внимание, ШОК КОНТЕНТ про индексы: планировщик не должен использовать индексы для ускорения запроса. Я постоянно сталкиваюсь с заблуждением, что индекс обязан быть использован и обязан ускорять запрос. Но только это не так. Давайте разберёмся что к чему. Если говорить про PostgreSQL (да и про MySQL), то у планировщика есть 4 способа доступа к данным *️⃣Seq path — читает heap-страницы таблицы последовательно и проверяет строки на соответствие условию. Это не обязательно «строки по порядку» в логическом смысле, а именно физическое чтение страниц heap. В EXPLAIN это Seq Scan. *️⃣Index path — обходит индекс, получает TID подходящих строк и по этим TID читает heap-строки. Хорош для относительно малой селективности, когда random I/O по heap ещё окупается. *️⃣ Bitmap path — обычно состоит из двух узлов: Bitmap Index Scan строит bitmap потенциальных tuple locations, а Bitmap Heap Scan по этому bitmap читает heap-страницы и достаёт строки. Такой подход позволяет читать одну heap-страницу один раз, даже если на ней много подходящих строк. *️⃣ Index-only path — пытается ответить только по индексу без чтения heap, если все нужные колонки есть в индексе и visibility map позволяет не проверять heap. Т.е. индекс конкурирует, как минимум, с двумя альтернативными способами получить данные. Так почему планировщик должен предпочесть индекс? Например, если нужно прочитать бОльшую часть таблицы (при высокой селективности или фильтрации по широкому деапозону). Seq Scan читает таблицу большими последовательными блоками. Если всё равно придётся достать много строк, то дешевле пройти таблицу целиком, чем прыгать по индексу и для каждой найденной записи отдельно ходить в heap. Это дешевле с точки зрения затраченных ресурсов на чтения с диска. Ещё Seq Scan часто выбирается на маленьких таблицах. Даже если индекс есть, стоимость открыть индекс, пройти его, сходить в heap и собрать результат может быть выше, чем просто прочитать несколько страниц таблицы целиком. А вот если условие селективное, т.е. возвращает мало строк, тогда индекс будет предпочтительнее. Index Scan быстро находит подходящие записи в индексе, получает TID и идёт в heap за строками. Это хорошо, когда таких переходов в heap немного. Но если подходящих строк много, Index Scan становится дорогим: он может делать много random access по heap-страницам. А эти данные не факт что в одной странице же, это больше переходов по диску. А это риск для планировщика. Ещё, если запрос сортирует данные в определённом порядке, выгодно положить и индекс в этом порядке, это упростит планировщику получение данных и добавит очков индексу при оценке плана запроса. Bitmap Scan часто выбирается как промежуточный вариант: строк уже слишком много для обычного Index Scan, но ещё не настолько много, чтобы выгоднее был Seq Scan. Обычный Index Scan может прыгать в heap много раз

index → heap page 17
index → heap page 981
index → heap page 42
index → heap page 17
index → heap page 318
...

Bitmap Scan сначала собирает все найденные TID, группирует их по heap-страницам, а потом читает heap более компактно:

прочитать page 17
прочитать page 42
прочитать page 318
прочитать page 981
...

Полезен ещё при использовании нескольких индексов в запросе. PostgreSQL может построить bitmap по одному индексу, bitmap по другому индексу, а потом объединить их через BitmapAnd. Index Only Scan выбирается, когда запрос можно обслужить из индекса почти без обращения к heap. Если все нужные данные есть в индексе, PostgreSQL может не читать heap-строки. Только тут важный момент: из-за MVCC он должен понимать, видима ли строка текущей транзакции. Для этого используется visibility map. Если heap-страница помечена как all-visible, heap читать не нужно. Если нет — PostgreSQL всё равно сходит в heap. По этому, не удивляйтесь, если вы добавили всё из select'а в index, но он не применяется, потому что таблица постоянно обновляется. А откуда планировщик знает, сколько результатов вернётся, если он не выполнял запрос? Он же только план оценивает. Об этом мы поговорим чуть позже🔤

Привет! Когда у тебя одна локальная база, то бизнес инвариант можно обернуть транзакцией и база данных позаботится об атомарности. А что, если у тебя распределенная система с множеством разных баз? Через 15 минут, в 19-00, начинаю открытый урок про распределенные транзакции. Как обеспечить консистентность и атомарность в мире распределенных систем. ➡️Подключиться

Всем привет! Думаю, что большенство знают что такое ACID и как работают локальные транзакции. А вот что делать, если у вас не то что базы распределеннае, так они ещё на разных технологиях сделаны. Как тогда быть? Решений тут можно предложить сразу несколько: от наивных ручных попыток синхронизации, до устойчевых архитектурных решений. Я это к чему? Готовлю сейчас открытый урок по распределенным транзакциям и получается прям очень круто. Приходите завтра, 30.06 в 19-00, будет очень интересно ☄️ А записаться можно тут ➡️ ➡️ ЗАПИСАТЬСЯ

Привет! В микросервисах нельзя просто открыть транзакцию, вызвать пять сервисов и сделать COMMIT. Если бизнес-операция проходит через несколько сервисов — оплата, склад, доставка, уведомления, внешние провайдеры — она почти неизбежно становится долгоживущим процессом. И в этом процессе всё может пойти не так: — деньги списались, но следующий шаг упал; — событие пришло дважды; — внешний сервис ответил с задержкой; — retry повторил операцию, которую нельзя было повторять; — состояние в сервисах разъехалось; — компенсация тоже не выполнилась. На открытом уроке мы поговорим не про абстрактную теорию, а про практическую проблему: как проводить бизнес-операции между несколькими сервисами, если у нас нет общей транзакции и каждый шаг может упасть, повториться или зависнуть. На уроке разберём как с этим работать и реализуем на практике способ обработки распределённых транзакций. Приходи, будет познавательно! 🔥🔥🔥 🗓️ Дата: 30.06 ⏰Время: 19:00 💻Формат: онлайн 🆓Участие: бесплатно ➡️ ➡️ ЗАПИСАТЬСЯ