SlideShare a Scribd company logo

История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)

•
•
Ontico
Ontico

Я расскажу о нашем опыте перевоза 300+ ТБ метаданных и 250k RPS нагрузки с одной коммерческой СУБД на букву "O" в PostgreSQL.

1 of 40
Download to read offline
История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)
История успеха Яндекс.Почты с PostgreSQL Владимир Бородин
О Яндекс.Почте Запущена в 2000 10+ миллионов пользователей в сутки 200.000 RPS в бэкенды web/mobile/imap 150+ миллионов писем покладки в сутки 20+ ПБ данных 3
Об этом рассказе Миграция из Oracle в PostgreSQL 300+ ТБ метаданных без избыточности 250k запросов в секунду OLTP: 80% чтений, 20% записи Предыдущие попытки MySQL Самописное решение 4
История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)
История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)
Назад в 2012
Метаданные Яндекс.Почты Всё хранилось в Oracle Очень много PL/SQL-логики Эффективная утилизация аппаратного обеспечения 10+ ТБ данных на шард Рабочий LA 100 Много ручных операций Тёплые (SSD) и холодные (SATA) базы для разных пользователей 75% SSD, 25% SATA 8
Шардирование и отказоустойчивость 9
Внутри приложения 10
Реальность 11
Наиболее популярные проблемы PL/SQL deploy Library cache Множество ручных операций Переключение мастера, наливка новой базы, переносы данных Только синхронный интерфейс в OCCI Проблемы с разработческими окружениями Не очень отзывчивая поддержка 12
Главная причина shop.oracle.com
Хронология
Эксперименты Октябрь 2012 — политическое решение Избавиться от Oracle за 3 года Апрель 2013 — первые эксперименты с разными СУБД PostgreSQL Множество NoSQL-решений Самописное решение на основе поискового бэкенда Июль 2013 - июнь 2014 — эксперимент со сборщиками https://simply.name/ru/video-pg-meetup-yandex.html 15
Прототип всей почты Август 2014 - декабрь 2014 Асинхронная покладка всего потока писем в PostgreSQL Первоначальные решения со схемой данных Важно для слоя абстракции Нагрузочное тестирование под живой нагрузкой Выбор аппаратного обеспечения Множество другого опыта работы с PostgreSQL https://simply.name/ru/postgresql-and-systemtap.html 16
Основная работа Январь 2015 - январь 2016 — разработка Июнь 2015 — dog fooding Ускорение разработки Сентябрь 2015 — начало миграции неактивных пользователей Исправление ошибок в коде переноса Обратный перенос (план Б) Январь 2016 - апрель 2016 — миграция 17
Переписывание всего кода для работы с Oracle и PostgreSQL 10 человеко-лет
История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)
Завершение 20
Основные изменения
macs 22
Шардирование и отказоустойчивость 23
Аппаратное обеспечение 24
Аппаратное обеспечение Тёплые базы (SSD) для большинства активных пользователей Холодные базы (SATA) для всех неактивных пользователей Горячие базы для очень активных пользователей 2% пользователей создают 50% нагрузки Автоматизация переноса пользователей между типами шардов TBD: перемещение старых писем активных пользователей с SSD на SATA 25
Идентификаторы В Oracle все идентификаторы (mid, fid, lid, tid) глобально уникальны Диапазоны для sequence’ов каждого шарда в отдельной БД NUMBER(20, 0) — 20 байт В PostgreSQL идентификаторы уникальны в пределах одного логина Вместо уникального mid уникальная пара (uid, mid) Bigint + bigint — 16 байт 26
Изменения схемы Меньше конкуренция за одну страницу индекса Обычный B-Tree вместо реверсивных индексов Ревизии для всех объектов Возможность читать с реплик только актуальные данные Инкрементальные обновления для IMAP и мобильных Денормализация части данных Массивы и GIN Композитные типы 27
Пример xdb01g/maildb M # dS mail.box Table "mail.box" Column | Type | Modifiers ---------------+--------------------------+------------------------ uid | bigint | not null mid | bigint | not null lids | integer[] | not null <...> Indexes: "pk_box" PRIMARY KEY, btree (uid, mid) "i_box_uid_lids" gin (mail.ulids(uid, lids)) WITH (fastupdate=off) 28
Хранимая логика PL/pgSQL прекрасен Сильно сократили количество логики Только для гарантии логической целостности данных Сильно увеличили покрытие тестами Цена ошибки очень высока https://events.yandex.ru/lib/talks/4057 Простой deploy 29
Подход к обслуживанию SaltStack Детальный diff между текущим и ожидаемым состоянием Все изменения схемы и кода через миграции https://events.yandex.ru/lib/talks/4055 Все частые операции автоматизированы Репрезентативные тестовые окружения 30
Проблемы
До начала основного переноса Problem with ExclusiveLock on inserts Checkpoint distribution ExclusiveLock on extension of relation with huge shared_buffers Hanging startup process on the replica after vacuuming on master Replication slots and isolation levels Segfault in BackendIdGetTransactionIds Значительно больше решено без помощи сообщества 32
Oracle DBA В любой непонятной ситуации виноват autovacuum
Диагностика https://simply.name/ru/pg-stat-wait.html Wait_event in pg_stat_activity (9.6) https://simply.name/ru/slides-pgday2015.html 34
Резервные копии В Oracle бэкапы (inc0 + 6 * inc1) и archive логи ≈ размер БД В PostgreSQL с barman’ом ≈ N * размер БД, где N > 5 WAL’ы сжимаются, а бэкапы нет File-level increment’ы толком не работают Все операции однопоточные и очень медленные Для 300 ТБ данных понадобилось бы ≈ 2 ПБ под бэкапы https://github.com/2ndquadrant-it/barman/issues/21 http://pgday.ru/ru/2016/papers/80 35
Во время основного переноса Проблемы не с PostgreSQL Проблемы с данными Очень много legacy за 10+ лет Ошибки в коде переноса 36
Завершение
Нам не хватает в PostgreSQL Declarative partitioning Хороший recovery manager Параллелизм/сжатие/page-level increment’ы Частичное восстановление (например, одной таблицы) в online Дальнейшее развитие интерфейса ожиданий Большой разделяемый кэш, O_DIRECT и асинхронное I/O Quorum commit 38
Итоги 1 PB с отказоустойчивостью (100+ миллиардов строк) 250k TPS Три календарных года / 10+ человеко-лет Быстрее deploy / эффективнее использование времени DBA Рефакторинг кода всего бэкенда В 3 раза больше аппаратного обеспечения Ни одной крупной аварии пока :) Linux, nginx, postfix, PostgreSQL 39
40 Владимир Бородин Системный администратор Вопросы? @man_brain http://simply.name +7 (495) 739 70 00, доб. 7255 d0uble@yandex-team.ru

More Related Content

История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)

  • 2. История успеха Яндекс.Почты с PostgreSQL Владимир Бородин
  • 3. О Яндекс.Почте Запущена в 2000 10+ миллионов пользователей в сутки 200.000 RPS в бэкенды web/mobile/imap 150+ миллионов писем покладки в сутки 20+ ПБ данных 3
  • 4. Об этом рассказе Миграция из Oracle в PostgreSQL 300+ ТБ метаданных без избыточности 250k запросов в секунду OLTP: 80% чтений, 20% записи Предыдущие попытки MySQL Самописное решение 4
  • 8. Метаданные Яндекс.Почты Всё хранилось в Oracle Очень много PL/SQL-логики Эффективная утилизация аппаратного обеспечения 10+ ТБ данных на шард Рабочий LA 100 Много ручных операций Тёплые (SSD) и холодные (SATA) базы для разных пользователей 75% SSD, 25% SATA 8
  • 12. Наиболее популярные проблемы PL/SQL deploy Library cache Множество ручных операций Переключение мастера, наливка новой базы, переносы данных Только синхронный интерфейс в OCCI Проблемы с разработческими окружениями Не очень отзывчивая поддержка 12
  • 15. Эксперименты Октябрь 2012 — политическое решение Избавиться от Oracle за 3 года Апрель 2013 — первые эксперименты с разными СУБД PostgreSQL Множество NoSQL-решений Самописное решение на основе поискового бэкенда Июль 2013 - июнь 2014 — эксперимент со сборщиками https://simply.name/ru/video-pg-meetup-yandex.html 15
  • 16. Прототип всей почты Август 2014 - декабрь 2014 Асинхронная покладка всего потока писем в PostgreSQL Первоначальные решения со схемой данных Важно для слоя абстракции Нагрузочное тестирование под живой нагрузкой Выбор аппаратного обеспечения Множество другого опыта работы с PostgreSQL https://simply.name/ru/postgresql-and-systemtap.html 16
  • 17. Основная работа Январь 2015 - январь 2016 — разработка Июнь 2015 — dog fooding Ускорение разработки Сентябрь 2015 — начало миграции неактивных пользователей Исправление ошибок в коде переноса Обратный перенос (план Б) Январь 2016 - апрель 2016 — миграция 17
  • 18. Переписывание всего кода для работы с Oracle и PostgreSQL 10 человеко-лет
  • 25. Аппаратное обеспечение Тёплые базы (SSD) для большинства активных пользователей Холодные базы (SATA) для всех неактивных пользователей Горячие базы для очень активных пользователей 2% пользователей создают 50% нагрузки Автоматизация переноса пользователей между типами шардов TBD: перемещение старых писем активных пользователей с SSD на SATA 25
  • 26. Идентификаторы В Oracle все идентификаторы (mid, fid, lid, tid) гл��бально уникальны Диапазоны для sequence’ов каждого шарда в отдельной БД NUMBER(20, 0) — 20 байт В PostgreSQL идентификаторы уникальны в пределах одного логина Вместо уникального mid уникальная пара (uid, mid) Bigint + bigint — 16 байт 26
  • 27. Изменения схемы Меньше конкуренция за одну страницу индекса Обычный B-Tree вместо реверсивных индексов Ревизии для всех объектов Возможность читать с реплик только актуальные данные Инкрементальные обновления для IMAP и мобильных Денормализация части данных Массивы и GIN Композитные типы 27
  • 28. Пример xdb01g/maildb M # dS mail.box Table "mail.box" Column | Type | Modifiers ---------------+--------------------------+------------------------ uid | bigint | not null mid | bigint | not null lids | integer[] | not null <...> Indexes: "pk_box" PRIMARY KEY, btree (uid, mid) "i_box_uid_lids" gin (mail.ulids(uid, lids)) WITH (fastupdate=off) 28
  • 29. Хранимая логика PL/pgSQL прекрасен Сильно сократили количество логики Только для гарантии логической целостности данных Сильно увеличили покрытие тестами Цена ошибки очень высока https://events.yandex.ru/lib/talks/4057 Простой deploy 29
  • 30. Подход к обслуживанию SaltStack Детальный diff между текущим и ожидаемым состоянием Все изменения схемы и кода через миграции https://events.yandex.ru/lib/talks/4055 Все частые операции автоматизированы Репрезентативные тестовые окружения 30
  • 32. До начала основного переноса Problem with ExclusiveLock on inserts Checkpoint distribution ExclusiveLock on extension of relation with huge shared_buffers Hanging startup process on the replica after vacuuming on master Replication slots and isolation levels Segfault in BackendIdGetTransactionIds Значительно больше решено без помощи сообщества 32
  • 33. Oracle DBA В любой непонятной ситуации виноват autovacuum
  • 35. Резервные копии В Oracle бэкапы (inc0 + 6 * inc1) и archive логи ≈ размер БД В PostgreSQL с barman’ом ≈ N * размер БД, где N > 5 WAL’ы сжимаются, а бэкапы нет File-level increment’ы толком не работают Все операции однопоточные и очень медленные Для 300 ТБ данных понадобилось бы ≈ 2 ПБ под бэкапы https://github.com/2ndquadrant-it/barman/issues/21 http://pgday.ru/ru/2016/papers/80 35
  • 36. Во время основного переноса Проблемы не с PostgreSQL Проблемы с данными Очень много legacy за 10+ лет Ошибки в коде переноса 36
  • 38. Нам не хватает в PostgreSQL Declarative partitioning Хороший recovery manager Параллелизм/сжатие/page-level increment’ы Частичное восстановление (например, одной таблицы) в online Дальнейшее развитие интерфейса ожиданий Большой разделяемый кэш, O_DIRECT и асинхронное I/O Quorum commit 38
  • 39. Итоги 1 PB с отказоустойчивостью (100+ миллиардов строк) 250k TPS Три календарных года / 10+ человеко-лет Быстрее deploy / эффективнее использование времени DBA Рефакторинг кода всего бэкенда В 3 раза больше аппаратного обеспечения Ни одной крупной аварии пока :) Linux, nginx, postfix, PostgreSQL 39