Хвост инженера

Автор: Listen IT · YouTube · статья Highload Today

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

Ролик Listen IT даёт короткое введение в оба подхода. Реплики можно использовать для резервирования и переноса части чтений с основного узла. Шардинг нужен, когда объём данных или нагрузка перестают помещаться на одном сервере: система выбирает shard key и по нему определяет, где должна находиться каждая запись.

Разница становится особенно важной при отказе. Реплика может заменить основной узел только при наличии механизма failover. У шарда замены вообще может не быть, если его не реплицировать отдельно. Поэтому production-система часто сочетает оба подхода: данные разделены на шарды, а внутри каждого шарда есть несколько копий.

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

Из этого можно взять в работу: перед добавлением новых узлов точно определить ограничение системы — не хватает производительности чтения, доступности, диска или пропускной способности записи.

Автор: Сергей Петренко · HighLoad++ 2022

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

В докладе Сергея Петренко команда Tarantool пробует сочетать оба режима: использовать Raft и синхронную репликацию, но сохранять возможность вручную ослабить ограничения во время аварии. CAP-теорему такая настройка не отменяет. Она лишь переносит последствия решения на тот момент, когда связь восстановится и две части кластера попытаются снова работать вместе.

Кому смотреть: инженерам, которые проектируют failover, настраивают кворумы или составляют инструкции на случай потери связи между ЦОДами.

Из этого можно взять в работу: дополнить процедуру аварийного снижения кворума планом последующего восстановления — как обнаружить расхождение, сохранить обе ветви и выбрать правильную историю.

Автор: Ильяс Салихов · PHP Russia 2022

ORM умеет сгенерировать миграцию, но не знает, выдержит ли её production. На таблице в сто миллионов строк обычный UPDATE, добавление ограничения или перестройка связей могут надолго занять базу блокировками. Формально схема обновляется правильно — а приложение в это время отвечает ошибками.

Ильяс Салихов показывает, как RetailCRM работает с PostgreSQL при постоянной нагрузке около 100 тысяч транзакций в секунду. Самая полезная часть доклада — не отдельные настройки PostgreSQL, а отношение к изменению схемы как к серии совместимых релизов. Новая структура сначала появляется рядом со старой, приложение некоторое время пишет в обе, данные переносятся порциями, чтение переключается отдельно — и только после проверки удаляется прежняя модель.

Кому смотреть: backend-разработчикам, которые применяют миграции во время обычной работы приложения и не могут выделить для них отдельное окно обслуживания.

Из этого можно взять в работу: на review следующей большой миграции отдельно проверить, совместим ли каждый её этап и можно ли остановиться или откатиться между этапами.

Автор: Дмитрий Емельянов (Altenar) · Видео с мероприятий {speach!}

В 39-минутном докладе Дмитрий Емельянов, тимлид группы разработки в Altenar, рассказывает об аварии, которая началась почти как анекдот: команда настраивала новый бэкап Kafka — и именно в этот момент потеряла Kafka. Но самое интересное случилось не во время аварии, а после, когда кластер уже удалось восстановить.

В системе Altenar некоторые топики были не просто транспортом между микросервисами, а единственным источником истины. При запуске сервисы перечитывали их, собирали состояние в памяти и затем продолжали работать с ним. Kafka реплицировалась между брокерами, а раз в сутки её файлы дополнительно копировали с одного диска на другой. Восстановление этих копий не проверяли: для этого пришлось бы останавливать stage, мешать работе QA и откладывать бизнес-фичи.

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

Кому смотреть: разработчикам и архитекторам, у которых Kafka хранит состояние системы, а рядом существуют базы, кэши или другие независимо восстанавливаемые хранилища.

Из этого можно взять в работу: проверять не только то, поднимается ли Kafka из копии, но и то, сможет ли после отката продолжить работу вся система. Особенно важно заранее понимать, как устранять рассинхронизацию между хранилищами, восстановленными на разные моменты времени.

Автор: Валентин Удальцов (Happy Inc. / Typhoon) · PHP Russia 2021

Валентин Удальцов в Happy Inc. прошёл полный путь от ORM до нативного SQL — и рассказывает об этом не как об отказе от абстракций ради принципа, а как об архитектурном решении, которое «во всех смыслах выгодно». Отправная точка: ORM, QueryBuilder и прочие абстракции связывают руки при попытке использовать базу данных на полную.

Конкретный вопрос, который задаёт Удальцов: какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции? Если абстракция закрывает доступ к возможностям СУБД, которую вы выбрали — это уже не абстракция, это ограничение.

Кому смотреть: PHP-разработчикам, которые чувствуют что ORM начинает ограничивать — но не решаются отказаться от него, потому что «так принято».

Из этого можно взять в работу: найти в своём проекте одно место где вы написали сложный raw SQL внутри ORM-контекста (через DB::raw() или аналог). Если такое место есть — это сигнал, где абстракция уже не помогает.

Автор: Алексей Фирсов (мейнтейнер aiopg, SoftPro) · MoscowPython

⚠️ Выпуск записан в 2019 году. Детали реализации aiopg и экосистема async-драйверов для PostgreSQL с тех пор изменились (появились asyncpg, sqlalchemy async, psycopg3). Архитектурные решения и вопросы дизайна — актуальны.

Первый выпуск Moscow Python Podcast (переименован из Python Junior Podcast) открылся «хардкором и сеньорностью». Гость: Алексей Фирсов, старший разработчик SoftPro и мейнтейнер библиотеки aiopg. Разговор ведут сооснователь MoscowPython Валентин Домбровский, тимлид NVIDIA Злата Обуховская и Григорий Петров. 44 минуты про то, как устроен асинхронный доступ к PostgreSQL из Python — и зачем вообще нужна отдельная библиотека для этого.

Центральный вопрос выпуска формулируется прямо: так ли уж нужна целая библиотека для взаимодействия асинхронного кода с PostgreSQL (05:32)? Ответ разворачивается через архитектурные детали: aiopg работает поверх psycopg2, который работает поверх написанной на C библиотеки libpq — и при этом сам написан на Python, а не на C. Почему — отдельный разговор (12:36).

Кому смотреть: Python-разработчикам, которые используют или планируют использовать async с PostgreSQL и хотят понять что происходит «под капотом», а не просто вызывать await conn.execute().

Из этого можно взять в работу: проверить в своём async-коде — есть ли места, где coroutine вызывается без await. Python это разрешает, и это источник трудноуловимых багов. Вопрос поднимается в выпуске явно (35:14) как вопрос дизайна языка.

Автор: Михаил Жилин · HighLoad++ Channel

Доклад с HighLoad++ 2024, 50 минут. PostgreSQL — база, которую хорошо знают и любят. Но поведение под нагрузкой — это другая тема: здесь включаются механизмы, которые в обычной работе не видны и в документации описаны скромно.

Жилин разбирает аномалии, которые проявляются именно под нагрузкой: как MVCC-механизм начинает накапливать мёртвые версии строк быстрее, чем autovacuum успевает их убирать; как это влияет на размер таблиц и производительность запросов; какие блокировки возникают там, где их не ждёшь; как connection pool ведёт себя при спайках и почему «просто увеличить max_connections» решает одну проблему и создаёт две новых. Доклад не обзорный — это конкретный производственный опыт с цифрами и конфигурациями.

Кому смотреть: разработчикам и DBA, которые эксплуатируют PostgreSQL под реальной нагрузкой и хотят понять, почему база «начала тормозить» — и особенно тем, кто ещё не сталкивался с bloat и autovacuum lag, пока они не случились в продакшне.

Из этого можно взять в работу: посмотрите на размер ваших самых активно обновляемых таблиц через pg_stat_user_tables — n_dead_tup / n_live_tup. Если соотношение высокое, у вас есть bloat, который под нагрузкой превратится в деградацию производительности.

Автор: Константин Осипов · Организованное программирование | Кирилл Мокевнин

Константин Осипов видел базы данных с нескольких сторон, которые большинству недоступны одновременно: core-разработчик MySQL, создатель Tarantool (в production у ВКонтакте и десятков других высоконагруженных систем), директор разработки в ScyllaDB, сооснователь PicoData.

Это не обзор технологий. Это взгляд изнутри на то, как устроен рынок СУБД — почему Postgres доминирует, что на самом деле произошло с NoSQL-хайпом и куда движется индустрия через десять лет. Версия Осипова отличается от того, что читаешь в статьях — потому что он строил эти системы, а не писал про них.

Особенно интересна часть про MySQL и Oracle: как выглядит сделка, если ты в ней не инвестор, а инженер, который писал этот код.

Кому смотреть: backend-разработчикам и архитекторам, которым интересно понять индустрию баз данных не через документацию, а через опыт людей, которые её создавали.

Из этого можно взять в работу: эволюция СУБД — это история о том, чьи интересы побеждали на каждом повороте. Понимание этого контекста меняет то, как выбираешь инструменты на следующие 10 лет.

Автор: Пётр Зайцев · Организованное программирование | Кирилл Мокевнин

Пётр Зайцев — сооснователь Percona. Это компания, которая появилась потому, что многим командам оказалось недостаточно корпоративной траектории MySQL — и кто-то должен был «сделать лучше». Зайцев видел MySQL изнутри и снаружи, в момент сделки с Oracle — и потом наблюдал, как это повлияло на весь рынок.

Разговор — о том, как технический выбор переплетается с бизнес-моделью. Почему MySQL оказался в ситуации конфликта интересов. Как из него выросла MariaDB. И почему на этом фоне Postgres — с его чистой open source-историей и отсутствием единого корпоративного владельца — стал выглядеть не только сильнее технически, но и надёжнее как стратегический выбор.

Зайцев не читает слайды. Он рассказывает историю — как человек, который жил внутри неё.

Кому смотреть: всем, кто выбирает хранилище данных и думает только в категориях «что быстрее» или «что популярнее». Особенно тем, кто строит продукт на 5+ лет и ни разу не задавался вопросом: а кто контролирует роадмап этой технологии через десять лет?

Из этого можно взять в работу: прежде чем выбрать базу данных, спроси: что произойдёт с ней, если её купит крупная корпорация? Зайцев прошёл через это с MySQL — и у него есть конкретные ответы.