- PVSM.RU - https://www.pvsm.ru -
Недавно я побывал на замечательной конференции Percona Live 2016 в Санта-Кларе. Хочется написать множество хвалебных слов организаторам и за отлично работающий Wi-Fi, и питание, и точное следование расписанию, и подготовку залов. Но все же статью я пишу не для туристического сайта, а для технического, потому просто расскажу о самых интересных докладах из тех, которые я посетил.
На удивление для столь узкоориентированной конференции, спектр докладов не ограничился одним только MySQL, как это могло бы показаться [1], но охватывал в целом инструменты работы с данными. Место нашлось и Hadoop с экосистемой и колоночными базам данных, и облакам (куда сейчас без них).
Начиная с версии MySQL 5.6, в MySQL появилась такая замечательная вещь, как GTID репликация [2]. В руководстве написано «много букв» о том, как эта репликация работает, но практически отсутствует информация, зачем она нужна.
Давайте представим себе, что кому-то потребовалось сделать каскадную репликацию данных. Это может потребоваться в случае, если часть каскада реплик находится в другом дата-центре. Чтобы сэкономить трафик между дата-центрами, только одна реплика тянет копию данных на себя, и уже с ее логов обновляются локальные слейвы. В общем-то, не самая плохая и вполне рабочая схема. Но она содержит в себе одну маленькую проблему.
Нельзя просто так взять и поменять мастер у слейва. Например, если отказывает один из узлов, то придется все узлы ветки инициализировать заново, т.е. разворачивать копию нового мастера и запускать с него репликацию. А это уже и дорого, и долго.
Чтобы этого не происходило, был предложен новый формат лога репликации, который и даёт возможность слейву продолжать репликацию с других слейвов. Т.е. лог репликации, записанный на слейве, будет полностью дублировать лог с мастера.
Более детально о работе этого механизма, а также о том, как включить его для крупного проекта (напоминаю, рассказывают Dropbox), можно узнать непосредственно из доклада.
Rolling out Global Transaction IDs at Dropbox [3]
В весьма сатирической и практической форме Charity Majors [4] рассказала о том, что на самом деле определяет пирамиду потребностей и выживания при выборе базы данных для проекта. Каждый из пунктов подкреплен отличной иллюстрацией, типа такой:
Maslow's Hierarchy of Needs for Databases [5]
Вот уже много много лет в MySQL есть возможность организации партицированных таблиц. Для чего это нужно, надеюсь, объяснять не надо. Однако, в силу некоторых особенностей реализации разработчики часто обходят этот механизм стороной. В общем-то, топора бояться — лес не рубить. Rick James предлагает разобраться, как же этот инструмент можно использовать по назначению и при каких ограничениях партицирование будет работать хорошо.
Вот примеры задач, где от партицирования можно выиграть:
PARTITIONing — How-To vs. Don't-Bother [6]
Daren Seagrave [7] из Facebook раскрыл некоторые особенности организации их системы пользовательских шардов и рассказал о том, как они переезжают между серверами и дата-центрами, какой путь они прошли, чтобы получить равномерное и эффективное использование пула серверов. Самым необычным решением, на мой взгляд, оказалось то, что они сначала определяют, куда переносить данные, и только потом — что именно нужно перенести. Несмотря на то, что технически сами шарды представляют собой MySQL-сервера, практически целиком доклад применим к любым БД.
Everyday We’re Shuffling — Online Shard Migration at Facebook [8]
Shlomo Priymak [9] и Dan Reif [10] из Facebook рассказали о том, как они организовали систему хранения бэкапов пользовательских шардов. В связи с тем, что все шарды маленького размера, процесс бэкапа отдельно взятого шарда происходит быстро. Как известно, бэкап не может считаться бэкапом, пока мы не убедились, что с него можно развернуться. Именно поэтому в Facebook организовали систему, постоянно проверяющую, что снятые бэкапы можно использовать для разворачивания БД.
Второй технической особенностью системы оказалась интересная идея по организации инкрементных бэкапов. Честно говоря, я даже никогда не слышал, чтобы кто-то снимал инкрементный бэкап базы данных. Идея для его реализации оказалась фантастически простой.
Также в докладе упомянули о том, как они это внедрили и организовали хранение в Hadoop. А также как они отказались от вычисления этого «дифа» в Hadoop. Вообще я считаю этот доклад самым полезным и интересным 8).
Massively Distributed Backup at Facebook Scale [11]
Brendan Gregg [12] из Netflix представил превосходный блиц о том, из каких подсистем состоит Linux. Какими утилитами можно получить информацию о каждой из подсистем, чтобы понять, не там ли «затуп».
Также он представил свой список команд для того, чтобы собрать необходимую информацию о состоянии сервера за 60 секунд. Я верю, что из этого доклада каждый «девопс» почерпнёт для себя что-нибудь новое и полезное.
Linux Systems Performance [13]
И конечно же, я не могу умолчать про доклад Badoo на Percona Live 2016. В докладе мы рассказали, как развивалась наша система бизнес-аналитики. С какими трудностями сталкивались, как их решали, какие технологии и при каких объемах данных работали, а также о том, как мы выбрали базу данных для аналитики.
В конце доклада мы рассказали о том, что самой актуальной задачей для нас является проблема сложности данных (сотни таблиц) и о том, как мы собираемся эту проблему решать.
BI at Badoo — historical retrospective [14]
Случилось невероятное! Через 14 лет мы наконец-то пофиксили баг номер 2 [15]. Прямо у нас на глазах MySQL сделал тост!
По большому счету, весь пост — это большое спасибо организаторам за программу проведенной конференции. Дополнительно хочу отметить разные мелочи, которые помогли не отрываться от самой конференции: питание почти без очередей, отлично работающий Wi-Fi, наличие воды в кулерах, свободные места и возможность зарядки гаджетов в аудиториях для докладов, забавный квест по сбору печатей в зоне выставки и, конечно, проведение Percona Game Night [16].
Алексей Еремихин (@alexxz ), руководитель группы разработки BI
Автор: Badoo
Источник [17]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/120768
Ссылки в тексте:
[1] как это могло бы показаться: https://habrahabr.ru/post/282337/
[2] GTID репликация: https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
[3] Rolling out Global Transaction IDs at Dropbox: https://www.percona.com/live/data-performance-conference-2016/content/rolling-out-global-transaction-ids-dropbox
[4] Charity Majors: https://www.percona.com/live/data-performance-conference-2016/users/charity-majors-0
[5] Maslow's Hierarchy of Needs for Databases: https://www.percona.com/live/data-performance-conference-2016/content/maslows-hierarchy-needs-databases
[6] PARTITIONing — How-To vs. Don't-Bother: https://www.percona.com/live/data-performance-conference-2016/content/partitioning-how-vs-dont-bother
[7] Daren Seagrave: https://www.percona.com/live/data-performance-conference-2016/users/daren-seagrave
[8] Everyday We’re Shuffling — Online Shard Migration at Facebook: https://www.percona.com/live/data-performance-conference-2016/content/everyday-we%E2%80%99re-shuffling-%E2%80%94-online-shard-migration-facebook
[9] Shlomo Priymak: https://www.percona.com/live/data-performance-conference-2016/users/shlomo-priymak
[10] Dan Reif: https://www.percona.com/live/data-performance-conference-2016/users/dan-reif-0
[11] Massively Distributed Backup at Facebook Scale: https://www.percona.com/live/data-performance-conference-2016/content/massively-distributed-backup-facebook-scale
[12] Brendan Gregg: https://www.percona.com/live/data-performance-conference-2016/users/brendan-gregg-0
[13] Linux Systems Performance: https://www.percona.com/live/data-performance-conference-2016/content/linux-systems-performance
[14] BI at Badoo — historical retrospective: https://www.percona.com/live/data-performance-conference-2016/content/bi-badoo-historical-retrospective
[15] баг номер 2: https://bugs.mysql.com/bug.php?id=2
[16] Percona Game Night: https://www.percona.com/blog/2016/04/21/percona-live-2016-percona-game-night/
[17] Источник: https://habrahabr.ru/post/300906/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.