Главная героиня нашего сегодняшнего интервью редко нуждается в представлении. Света Смирнова, инженер технической поддержки Percona, является экспертом по диагностике неполадок и оптимизации производительности MySQL, активным членом российского и международного Open Source сообщества, регулярным спикером на крупных профильных мероприятиях, автором одной из наиболее актуальных книг по MySQL — «MySQL Troubleshooting». На предстоящем летнем PG Day'17 Russia Света проведет интенсивный учебный курс по отладке производительности MySQL и прочитает лекцию, посвященную отладке репликации.
Накануне PG Day, мы побеседовали со Светой о тонкостях процесса репортинга и устранения багов в MySQL, последних тенденциях и трендах в мире популярных форков, истории внедрения функциональности поддержки JSON и подготовили подборку материалов, блогов и книг, полезных для всех специалистов, работающих с MySQL.
Эксклюзивно для PG Day, специальный раздел учебного курса будет посвящён Performance Schema. С её помощью можно отлаживать хранимые процедуры, отслеживать, где используется оперативная память сервера MySQL, просматривать текущие переменные отдельно для каждого соединения, отлаживать запросы, диагностировать блокировки и многое другое. Света расскажет, как настраивать Performance Schema и правильно выбирать входящие в нее инструменты для ваших задач.
PG Day: Расскажи немного о себе. Кто ты, чем занимаешься. Как давно работаешь в профессии, какими квалификациями обладаешь?
Света: Я работаю инженером технической поддержки MySQL уже более десяти лет. Начинала в компании MySQL AB, которую потом купил Sun, затем — Oracle. Теперь занимаюсь тем же самым в компании Percona. До того как стать инженером технической поддержки MySQL, я работала веб-разработчиком. В последние годы у меня были проекты, связанные с разработкой CRM-систем для закрытых клиентов. Это были частные, невидимые со стороны вещи на PHP и MySQL. Будучи веб-разработчиком, я использовала разные базы данных. Когда была возможность, выбирала MySQL.
Часто думают, что техническая поддержка — это когда человек сидит на телефоне и отвечает на дурацкие вопросы. На самом деле, в случае с MySQL это работает немного по-другому. Если измерять в уровнях (level), то мы — это L3 (не знаю, есть ли уровни выше — я не забочусь о номерах). Мы занимаемся совершенно разными вещами: часто смотрим в код, иногда даже пишем исправления. Отслеживаем всевозможные ситуации — от неправильного поведения до проблем с производительностью и сбоев MySQL. Еще конкретно я тружусь над приоритетами багов. В Oracle я плотно работала с MySQL Enterprise Backup Team. Продолжаю интересоваться такими вещами, как решения для бэкапа (по старой привычке).
PG Day: Раз уж мы заговорили про баги, задам провокационный вопрос. Очень часто люди жалуются, что баги в MySQL не правятся годами. Насколько это правда? Как правильно составить отчет об ошибке, чтобы в Oracle баг поправили быстрее?
Света: Я сейчас не в Oracle. Делала специальный пятиминутный доклад на тему того, как сообщать о проблемах, чтобы их, в конце концов, фиксили. В мире MySQL (в Percona, Oracle) багами на первой стадии занимается группа поддержки. Почему поддержка, а не разработчик? Потому что, когда вы постите баг, необходимо удостовериться в том, что он воспроизводимый, что это действительно ошибка, а не некое ожидаемое поведение, просто не задокументированное. Что этот баг актуален в последней версии, и вы предоставили достаточно информации для того, чтобы его воспроизвести. На это тратится достаточно много времени. Чем лучше у вас получается с самого начала предоставить воспроизводимый test case, чем быстрее вы будете отвечать на эти вопросы, тем скорее ваш баг окажется либо в статусе Verified в MySQL Bugs Database, либо станет Confirmed в Percona Bugs Database — и пойдет на следующий этап.
На следующем этапе есть два пути. Все баги проходят так называемый процесс Triage: каждому багу присваивается приоритет в соответствии с планами разработчиков. Критические ошибки фиксят быстро. Если разработчик понял, что ошибка может создать проблемы большому количеству пользователей, ее исправят в короткие сроки. Но не все баги такие. У меня в практике были случаи, когда, даже несмотря на большое количество жалоб клиентов, для разработчика баг выглядел фигней, — мол, есть же workaround. Никто не подумал о том, что у клиента тысяча серверов, и чтобы на каждом из них этот workaround применить, нужно потратить много времени и усилий. Не всегда это понятно.
Для таких случаев и в Percona, и в Oracle есть комитеты по вопросам эскалации багов для клиентов поддержки. Если у вас есть контракт на поддержку, вы можете написать: «Этот баг меня затрагивает, я хочу, чтобы его исправили». В Percona таких багов меньше. Но и команда разработки меньше. Это может оказаться в чем-то решающим фактором, в чем-то — нет. Например, есть баг 989. Его фиксили лет десять. Чтобы его исправить, пришлось имплементировать три worklog’a, полностью переписать часть runtime-движка. Его нельзя назвать feature request, но сделали новые фичи, имплементировали metadata locks, чтобы его исправить. Так тоже бывает.
Общее правило: если вы хотите, чтобы ваши баги исправили, пишите как можно более аккуратные тест-кейсы. В этом случае с момента, когда вы зарепортили баг, до момента, когда он стал confirmed/verified и попал в девелопмент, прошел процесс приоритезации, время будет минимальным.
PG Day: Вопрос про различные варианты MySQL. Каковы текущие тенденции развития, что и в какую сторону движется? Можешь ли ты дать комментарий относительно этого?
Света: Я — консервативный человек. Есть три основных варианта MySQL. Первый — это upstream, который делает Oracle: Oracle MySQL Server. Второй — это Percona Server, который имеет стопроцентную совместимость с предыдущим. Вы можете взять данные из data dir Percona Server и использовать их в Oracle MySQL Server, и наоборот. Еще есть несколько дополнительных фич и оптимизаций, когда он работает быстрее, чем Oracle MySQL Server. Есть такие фичи, как verbose slow log, или audit log, который существует только в enterprise-версии Oracle MySQL Server. Есть XtraBackup — он, кстати, работает и с Oracle, и с Percona, и с MariaDB. MariaDB — третий вариант. Я даже не знаю, можно ли его назвать форком сейчас, потому что они пошли по своему пути. Например, оптимизатором у них занимается отдельная команда. Вы можете писать те же самые запросы, что и в Oracle MySQL, но оптимизатор будет составлять планы по-другому, и они могут отличаться.
Что касается репликации, то у них, например, GTID решены совершенно не так, как в Oracle MySQL Server. Они не смогут прочитать GTID с Oracle MySQL Server или с Percona Server. Нельзя взять data dir MariaDB и использовать их GTID в Percona или MySQL серверах. Строго говоря, MariaDB не выдаст ошибку, если увидит GTID в чужом формате: просто проигнорирует. Обратное неверно. Они идут немного в сторону, но до сих пор мигрировать на них, в принципе, просто. А вот мигрировать обратно уже сложнее, потому что у них есть фичи, которых нет в других серверах, или те же фичи реализованы по-разному.
Были проекты, как Drizzle — такой минималистичный MySQL Server, от которого осталось только ядро. Но он сейчас не развивается. Есть форки компаний, например, форк Facebook или форк Alibaba. Они используются этими компаниями. У Alibaba, например, есть физическая репликация. Я до сих пор не знаю, открыли они исходный код или нет, или всё ещё обещают. Но какие-то вещи, которых нет в других серверах, вы можете попробовать. Однако они больше ориентированы на эти компании.
Существует подсистема хранения MyRocks, разработка Facebook. Она уже есть и в Percona Server, и в MariaDB. В Percona Server есть пробный билд, доступен в testing area, техническая поддержка MyRocks будет осуществляться компаниями Percona и MariaDB. Есть еще такие форки, как Amazon — у них собственная Aurora. Но их исходники закрыты. Исходники MySQL лицензированы под GPL, и пока вы не хотите продукт распространять — можете его использовать. Они пользуются этим моментом в лицензии GPL. Но в Amazon Aurora нельзя посмотреть исходный код, достаточно сложно узнать извне какие-то вещи.
PG Day: Проприетарные движки идеологически являются развитием каких-то устоявшихся движков типа InnoDB, или же это кардинально новые разработки (MyRocks, например)?
Света: MyRocks не проприетарный движок, его исходный код открыт, недавно стал GPL. Как он начался? В InnoDB индексы хранятся в B-tree. Это прекрасно для чтения. Но приходится «дерево» каждый раз перезаписывать. Чтобы улучшить это, в RocksDB придумали LSM-tree. В нем данные сначала пишутся в memtable, потом — в write-ahead log. Вообще, есть две имплементации RocksDB: для MongoDB и для MySQL. MyRocks — это подсистема для MySQL, она доступна в open-source достаточно давно, на GitHub компании Facebook. Ее можно было использовать с фейсбуковским «деревом». Сейчас она доступна в репозиториях MariaDB, Percona. Фичи делаются на стороне Facebook, но поддерживать его будет или MariaDB, или Percona. Кстати, фичи мы тоже будем делать.
PG Day: Сейчас стандартным движком MySQL Server по-прежнему является InnoDB?
Света: Да.
PG Day: Достиг ли он стабильности, или есть что совершенствовать?
Света: Моменты для улучшения, безусловно, есть. Но он из этих движков наиболее стабилен. Мне как support-инженеру проще всего работать с InnoDB. Возможно, из-за того, что я дольше всего работала с ним, а не с новыми движками. Возможно, просто потому, что пользовательская база больше. Допустим, известно, что компрессия в InnoDB хуже, чем в альтернативных движках TokuDB и MyRocks. В версии 8.0 они обещали исправить ситуацию, когда под определенной нагрузкой read committed начинает давать худшую производительность, чем repeatable read, и заметно худшую. Обещали исправить в 8.0, но пока это недоступно. Показывали бенчмарки, но код еще не доступен. Безусловно, есть еще какие-то вещи, которые в InnoDB можно улучшать.
PG Day: Ты упомянула, что ты как инженер поддержки часто работаешь на InnoDB. Есть ли какие-то фичи новых версий, которые ты регулярно используешь?
Света: Mоя любимая фича, о которой я люблю говорить — это Performance Schema. К сожалению, есть такая вещь: когда ты сам разработчик, то можешь поставить любую версию и сказать: «Нам надо обновиться». А когда ты – инженер поддержки, случаются разные истории со старыми версиями. Недавно был клиент с версией 5.1, которая не поддерживается уже десять лет, и у которой давно наступил end of life.
Я очень хочу, чтобы все обновились до 5.7, потому что в 5.7 появился новый инструментарий Performance Schema. В более ранних версиях было непонятно, куда расходуется память – то ли в replication storage threads, то ли в InnoDB или еще где-то. Теперь эта информация доступна. Появилась возможность получать больше информации о блокировках. Абсолютно новое, что раньше не было доступно — это блокировки метаданных. Появились инструменты для просмотра статусных переменных в сессии. Когда сервер делает какую-то работу, можно посмотреть, сколько строк данных записывает движок, или сколько создано временных таблиц. Но если у вас тысяча соединений, то вы знаете, что вся тысяча — это просто сумма такая. Если интересно посмотреть одно наиболее активное соединение, то до 5.7 это было невозможно, а в 5.7 – возможно. В 5.7 есть много инструментов Performance Schema. Сейчас это мой любимый инструмент. Очень хочу, чтобы все перешли на новую версию.
PG Day: К слову о переходе. До сих пор есть люди, у которых старые версии. Это банальная лень и безответственность, или есть какие-то объективные сложности с переходом со старых версий на более новые?
Света: Сложности с переходом, в основном, такие. Если у вас предприятие, которое должно работать 24 часа, 7 дней в неделю, то возникает вопрос: как минимизировать время простоя? Второй момент. При обновлении с мажорной ветки на мажорную есть несовместимости. Несовместимости бывают двух видов: формата хранения данных и те, которые связаны с построением планов выполнения запроса оптимизатором.
Несовместимости первого типа не относятся к совсем тяжелым случаям. При переходе с версии 5.1 на что-то более новое приходится делать dump/reload. Это очень медленно. В то время как простой апгрейд с ветки на ветку прост: берем старый data dir, запускаем новую версию и запускаем mysql_upgrade. В последних версиях Oracle делает так, чтобы этот процесс происходил с наименьшими усилиями. Но иногда всё равно возникают проблемы. Либо приходится перестраивать таблицу, писать ALTER TABLE, ENGINE=InnoDB, что тоже, в общем-то, не быстро.
Еще момент. Запросы, выполняемые приложением, оптимизированы под версию, для которой они изначально писались. Что интересно, баги исправляются, оптимизатор работает лучше, а некоторые запросы работают медленнее после обновления. У меня был классический случай. Один клиент пишет: «Мы обновились, и у нас запрос стал работать медленно». Я говорю: «Пришлите свой лог». Он присылает — а у них все запросы написаны с помощью FORCE INDEX. Я говорю: «Попробуйте убрать FORCE INDEX». Он убрал и говорит: «Да, теперь они работают быстрее, чем на старой версии». Всё это придется делать.
PG Day: Ты являешься автором книги “MySQL Troubleshooting?, посвященной вопросу отладки и решения проблем MySQL. Кому она может быть полезна?
Света: Я работала в поддержке MySQL, работала с багами. Люди задавали одни и те же вопросы. Я подумала, что нужно собрать в одном месте информацию о том, что делать, если есть проблемы с MySQL. Хотелось решать более сложные задачи, а не отвечать на одни и те же вопросы. Идея книги в следующем. Вы знаете, как пользоваться MySQL, писать запросы, стартовать. Но у вас возникли трудности: возвращаются неправильные данные, работает медленно. Что делать? Я хотела, чтобы книга отвечала на этот вопрос.
PG Day: Эта книга для широкого круга лиц. Любой человек, который имеет дело с MySQL, должен ее прочитать, чтобы перестать задавать глупые вопросы?
Света: В принципе, да. Не обязательно глупые, но просто иметь возможность понять, что делать. К сожалению, книга выпущена в 2012 году, и в ней нет последних фич. Но принцип до сих пор актуален — книгу нужно открывать, чтобы понять что делать, если у вас какая-то проблема с MySQL.
PG Day: Планируется ли переиздание книги, второе издание — про проблемы с новыми фичами?
Света: Прямо сейчас этим не занимаюсь, но планирую.
PG Day: К слову, о новых фичах. Насколько мне известно, ты способствовала вопросу реализации поддержки JSON в MySQL. Расскажи про этот опыт. Сейчас это очень модный тренд в мире баз данных.
Света: На самом деле, всё это очень интересно. Поддержка JSON — worklog, который появился еще до того, как я стала инженером технической поддержки MySQL (это было до 2006 года). В нем было описано, какие функции должна поддерживать MySQL. Но кто-то должен был это двигать, и сделали проект внутри поддержки. Я подумала, почему бы не заняться этим вопросом? MySQL не хотелось повторять опыт с XML-функциями. Функции были имплементированы, но работали не совсем так, как хотелось сообществу. Решили, что я сделаю design prototype в виде UDF-функций. Этот design prototype был доступен в виде проекта MySQL Labs. Люди пользовались, присылали баги. В последствии Optimizer Team должны были на основании design prototype реализовать функции на уровне сервера так, чтобы они были оптимизированы и работали быстро.
В 2012 году я сделала первую версию, она пошла на внутреннее review. Тогда мне сказали, что всё надо переделать. Я переделала и в 2013 году, наконец, показала публике. В это время пришли запросы на новые фичи: появились функции json_depth и json_length (по просьбе сообщества). Это не было каким-то моим изобретением или изобретением компании. Я занималась исправлением багов, наполнением новой функциональности. Дизайн был «отполирован». Наконец, появился design prototype стандарта SQL для JSON. Не знаю, утвержден он сейчас или нет – перестала за этим следить. Был имплементирован синтаксис.
У функций UDF сначала был несколько странный синтаксис. Но я не работала специально над синтаксисом, потому что тогда не было понятно, что будет со стандартом. Если MySQL собирался это внедрять в серверный код, то хотелось, чтобы он получился не сильно специфичным для MySQL — чтобы синтаксис было достаточно просто использовать. Когда всё протестировали, команда оптимизаторов сделала тип данных. Это не pluggable. Я не могла сделать это без их помощи.
PG Day: Разработка JSON продолжается, фичи добавляются?
Света: Да. В версии 8.0.2, которая еще не вышла, они хотят сделать так, чтобы для функции JSON_SET и JSON_REPLACE был in-place update. Что сейчас вообще происходит с JSON? Как правило, JSON — это большой, длинный документ (допустим, 1 килобайт). Допустим, вы хотите поменять какой-то элемент — например, название книги. Сейчас приходится полностью перезаписывать этот 1 килобайт. Это не очень эффективно. Переписать 1 килобайт — не страшно. Но если приходится перезаписывать много таких строк, это становится неэффективно. Они в 8.0.2 анонсировали, что сделали in-place update — что будет обновляться только небольшая часть документа JSON. Это говорит о том, что JSON развивается, и дальше будет что-то интересное.
PG Day: Большое спасибо за такой подробный и обстоятельный рассказ. Хочу попросить тебя дать небольшой анонс мастер-класса, который ты дашь летом на PG Day. Он будет посвящен отладке производительности MySQL. Мастер-класс запланирован большой и объемный: целых восемь часов. Каким вопросам ты собираешься уделить внимание, специалистам какого профиля он будет полезен?
Света: Он будет полезен тем, у кого есть проблема с производительностью MySQL, и кто хочет что-то сделать, чтобы ускорить работу MySQL. На мастер-классе я, начиная с азов, расскажу, что надо знать, перед тем как приступать к отладке, как разобраться, что именно работает медленно. Что такое тестовый сервер, каким образом его использовать для отладки проблем с производительностью. Будет четыре основных части: медленные запросы и их оптимизация; блокировки. Расскажу, как оборудование и конфигурация влияют на работу MySQL.
Мастер-класс, в первую очередь, для DBA и разработчиков. Разработчики не всегда могут что-то сделать на оборудовании. Но, с другой стороны, разработчик приложений может что-то сделать с медленными запросами и блокировками. Я затрону все инструменты – начиная с тех, которые доступны уже очень много лет, и заканчивая современными. Постараюсь рассказать про инструменты, которые доступны либо непосредственно из MySQL Command-Line клиента, либо из командной строки Linux. Немного затрону и графические инструменты, покажу, как они выглядят.
Почему я придерживаюсь такого подхода? Любой графический инструмент всё равно берет откуда-то данные: либо из SQL-команд, либо из командной строки. Задания будут по всем этим вопросам. Вам придется отладить пару запросов и решить проблему с блокировками.
PG Day: В заключение хочу попросить тебя дать напутственное слово или совет для начинающих специалистов по базам данных. Что изучать, какие технологии посмотреть, какие статьи, блоги, книги почитать. Что будет полезно, чтобы эффективно развиваться в этой профессии?
Света: Что касается блогов, в MySQL существуют два места. Первое — это «Планета MySQL», которая поддерживается Oracle и представляет собой агрегатор всех интересных англоязычных блогов по MySQL. Все основные люди там есть. Второе — это Percona Database Performance Blog. Это блог инженеров Percona. Возможно, Percona стала такой успешной компанией благодаря блогу. Когда я работала в Oracle, то очень часто цитировала Percona Blog, потому что там очень хороший технический контент.
Что касается книг, то могу посоветовать свою книжку “MySQL Troubleshooting”. “High Performance MySQL” Петра Зайцева, Вадима Ткаченко и Бэрона Шварца. Для тех, кто делает сложные вещи с репликацией — книгу “MySQL High Availability?. Авторы — бывшие сотрудники MySQL replication team: Чарльз Белл, Mats Kindahl, Lars Thalmann. Mats сейчас ушел из команды MySQL. Чарльз занимается MySQL utilities. Ларс — менеджер уже большей команды, чем Replication Team. Тем не менее, они про это писали: как делаются разные репликации, какие есть «грабли», и как их обойти. Полкниги этому посвящено. Полкниги посвящено решению, которое стало MySQL Fabric.
Есть еще книга “SQL Antipatterns?, автор — Bill Karwin, подходит для всех баз данных, в том числе для MySQL. Есть еще книги. Но, наверное, на этом остановлюсь.
Накануне PG Day, мы побеседовали со Светой о тонкостях процесса репортинга и устранения багов в MySQL, последних тенденциях и трендах в мире популярных форков, истории внедрения функциональности поддержки JSON и подготовили подборку материалов, блогов и книг, полезных для всех специалистов, работающих с MySQL.
Эксклюзивно для PG Day, специальный раздел учебного курса будет посвящён Performance Schema. С её помощью можно отлаживать хранимые процедуры, отслеживать, где используется оперативная память сервера MySQL, просматривать текущие переменные отдельно для каждого соединения, отлаживать запросы, диагностировать блокировки и многое другое. Света расскажет, как настраивать Performance Schema и правильно выбирать входящие в нее инструменты для ваших задач.
PG Day: Расскажи немного о себе. Кто ты, чем занимаешься. Как давно работаешь в профессии, какими квалификациями обладаешь?
Света: Я работаю инженером технической поддержки MySQL уже более десяти лет. Начинала в компании MySQL AB, которую потом купил Sun, затем — Oracle. Теперь занимаюсь тем же самым в компании Percona. До того как стать инженером технической поддержки MySQL, я работала веб-разработчиком. В последние годы у меня были проекты, связанные с разработкой CRM-систем для закрытых клиентов. Это были частные, невидимые со стороны вещи на PHP и MySQL. Будучи веб-разработчиком, я использовала разные базы данных. Когда была возможность, выбирала MySQL.
Часто думают, что техническая поддержка — это когда человек сидит на телефоне и отвечает на дурацкие вопросы. На самом деле, в случае с MySQL это работает немного по-другому. Если измерять в уровнях (level), то мы — это L3 (не знаю, есть ли уровни выше — я не забочусь о номерах). Мы занимаемся совершенно разными вещами: часто смотрим в код, иногда даже пишем исправления. Отслеживаем всевозможные ситуации — от неправильного поведения до проблем с производительностью и сбоев MySQL. Еще конкретно я тружусь над приоритетами багов. В Oracle я плотно работала с MySQL Enterprise Backup Team. Продолжаю интересоваться такими вещами, как решения для бэкапа (по старой привычке).
PG Day: Раз уж мы заговорили про баги, задам провокационный вопрос. Очень часто люди жалуются, что баги в MySQL не правятся годами. Насколько это правда? Как правильно составить отчет об ошибке, чтобы в Oracle баг поправили быстрее?
Света: Я сейчас не в Oracle. Делала специальный пятиминутный доклад на тему того, как сообщать о проблемах, чтобы их, в конце концов, фиксили. В мире MySQL (в Percona, Oracle) багами на первой стадии занимается группа поддержки. Почему поддержка, а не разработчик? Потому что, когда вы постите баг, необходимо удостовериться в том, что он воспроизводимый, что это действительно ошибка, а не некое ожидаемое поведение, просто не задокументированное. Что этот баг актуален в последней версии, и вы предоставили достаточно информации для того, чтобы его воспроизвести. На это тратится достаточно много времени. Чем лучше у вас получается с самого начала предоставить воспроизводимый test case, чем быстрее вы будете отвечать на эти вопросы, тем скорее ваш баг окажется либо в статусе Verified в MySQL Bugs Database, либо станет Confirmed в Percona Bugs Database — и пойдет на следующий этап.
На следующем этапе есть два пути. Все баги проходят так называемый процесс Triage: каждому багу присваивается приоритет в соответствии с планами разработчиков. Критические ошибки фиксят быстро. Если разработчик понял, что ошибка может создать проблемы большому количеству пользователей, ее исправят в короткие сроки. Но не все баги такие. У меня в практике были случаи, когда, даже несмотря на большое количество жалоб клиентов, для разработчика баг выглядел фигней, — мол, есть же workaround. Никто не подумал о том, что у клиента тысяча серверов, и чтобы на каждом из них этот workaround применить, нужно потратить много времени и усилий. Не всегда это понятно.
Для таких случаев и в Percona, и в Oracle есть комитеты по вопросам эскалации багов для клиентов поддержки. Если у вас есть контракт на поддержку, вы можете написать: «Этот баг меня затрагивает, я хочу, чтобы его исправили». В Percona таких багов меньше. Но и команда разработки меньше. Это может оказаться в чем-то решающим фактором, в чем-то — нет. Например, есть баг 989. Его фиксили лет десять. Чтобы его исправить, пришлось имплементировать три worklog’a, полностью переписать часть runtime-движка. Его нельзя назвать feature request, но сделали новые фичи, имплементировали metadata locks, чтобы его исправить. Так тоже бывает.
Общее правило: если вы хотите, чтобы ваши баги исправили, пишите как можно более аккуратные тест-кейсы. В этом случае с момента, когда вы зарепортили баг, до момента, когда он стал confirmed/verified и попал в девелопмент, прошел процесс приоритезации, время будет минимальным.
PG Day: Вопрос про различные варианты MySQL. Каковы текущие тенденции развития, что и в какую сторону движется? Можешь ли ты дать комментарий относительно этого?
Света: Я — консервативный человек. Есть три основных варианта MySQL. Первый — это upstream, который делает Oracle: Oracle MySQL Server. Второй — это Percona Server, который имеет стопроцентную совместимость с предыдущим. Вы можете взять данные из data dir Percona Server и использовать их в Oracle MySQL Server, и наоборот. Еще есть несколько дополнительных фич и оптимизаций, когда он работает быстрее, чем Oracle MySQL Server. Есть такие фичи, как verbose slow log, или audit log, который существует только в enterprise-версии Oracle MySQL Server. Есть XtraBackup — он, кстати, работает и с Oracle, и с Percona, и с MariaDB. MariaDB — третий вариант. Я даже не знаю, можно ли его назвать форком сейчас, потому что они пошли по своему пути. Например, оптимизатором у них занимается отдельная команда. Вы можете писать те же самые запросы, что и в Oracle MySQL, но оптимизатор будет составлять планы по-другому, и они могут отличаться.
Что касается репликации, то у них, например, GTID решены совершенно не так, как в Oracle MySQL Server. Они не смогут прочитать GTID с Oracle MySQL Server или с Percona Server. Нельзя взять data dir MariaDB и использовать их GTID в Percona или MySQL серверах. Строго говоря, MariaDB не выдаст ошибку, если увидит GTID в чужом формате: просто проигнорирует. Обратное неверно. Они идут немного в сторону, но до сих пор мигрировать на них, в принципе, просто. А вот мигрировать обратно уже сложнее, потому что у них есть фичи, которых нет в других серверах, или те же фичи реализованы по-разному.
Были проекты, как Drizzle — такой минималистичный MySQL Server, от которого осталось только ядро. Но он сейчас не развивается. Есть форки компаний, например, форк Facebook или форк Alibaba. Они используются этими компаниями. У Alibaba, например, есть физическая репликация. Я до сих пор не знаю, открыли они исходный код или нет, или всё ещё обещают. Но какие-то вещи, которых нет в других серверах, вы можете попробовать. Однако они больше ориентированы на эти компании.
Существует подсистема хранения MyRocks, разработка Facebook. Она уже есть и в Percona Server, и в MariaDB. В Percona Server есть пробный билд, доступен в testing area, техническая поддержка MyRocks будет осуществляться компаниями Percona и MariaDB. Есть еще такие форки, как Amazon — у них собственная Aurora. Но их исходники закрыты. Исходники MySQL лицензированы под GPL, и пока вы не хотите продукт распространять — можете его использовать. Они пользуются этим моментом в лицензии GPL. Но в Amazon Aurora нельзя посмотреть исходный код, достаточно сложно узнать извне какие-то вещи.
PG Day: Проприетарные движки идеологически являются развитием каких-то устоявшихся движков типа InnoDB, или же это кардинально новые разработки (MyRocks, например)?
Света: MyRocks не проприетарный движок, его исходный код открыт, недавно стал GPL. Как он начался? В InnoDB индексы хранятся в B-tree. Это прекрасно для чтения. Но приходится «дерево» каждый раз перезаписывать. Чтобы улучшить это, в RocksDB придумали LSM-tree. В нем данные сначала пишутся в memtable, потом — в write-ahead log. Вообще, есть две имплементации RocksDB: для MongoDB и для MySQL. MyRocks — это подсистема для MySQL, она доступна в open-source достаточно давно, на GitHub компании Facebook. Ее можно было использовать с фейсбуковским «деревом». Сейчас она доступна в репозиториях MariaDB, Percona. Фичи делаются на стороне Facebook, но поддерживать его будет или MariaDB, или Percona. Кстати, фичи мы тоже будем делать.
PG Day: Сейчас стандартным движком MySQL Server по-прежнему является InnoDB?
Света: Да.
PG Day: Достиг ли он стабильности, или есть что совершенствовать?
Света: Моменты для улучшения, безусловно, есть. Но он из этих движков наиболее стабилен. Мне как support-инженеру проще всего работать с InnoDB. Возможно, из-за того, что я дольше всего работала с ним, а не с новыми движками. Возможно, просто потому, что пользовательская база больше. Допустим, известно, что компрессия в InnoDB хуже, чем в альтернативных движках TokuDB и MyRocks. В версии 8.0 они обещали исправить ситуацию, когда под определенной нагрузкой read committed начинает давать худшую производительность, чем repeatable read, и заметно худшую. Обещали исправить в 8.0, но пока это недоступно. Показывали бенчмарки, но код еще не доступен. Безусловно, есть еще какие-то вещи, которые в InnoDB можно улучшать.
PG Day: Ты упомянула, что ты как инженер поддержки часто работаешь на InnoDB. Есть ли какие-то фичи новых версий, которые ты регулярно используешь?
Света: Mоя любимая фича, о которой я люблю говорить — это Performance Schema. К сожалению, есть такая вещь: когда ты сам разработчик, то можешь поставить любую версию и сказать: «Нам надо обновиться». А когда ты – инженер поддержки, случаются разные истории со старыми версиями. Недавно был клиент с версией 5.1, которая не поддерживается уже десять лет, и у которой давно наступил end of life.
Я очень хочу, чтобы все обновились до 5.7, потому что в 5.7 появился новый инструментарий Performance Schema. В более ранних версиях было непонятно, куда расходуется память – то ли в replication storage threads, то ли в InnoDB или еще где-то. Теперь эта информация доступна. Появилась возможность получать больше информации о блокировках. Абсолютно новое, что раньше не было доступно — это блокировки метаданных. Появились инструменты для просмотра статусных переменных в сессии. Когда сервер делает какую-то работу, можно посмотреть, сколько строк данных записывает движок, или сколько создано временных таблиц. Но если у вас тысяча соединений, то вы знаете, что вся тысяча — это просто сумма такая. Если интересно посмотреть одно наиболее активное соединение, то до 5.7 это было невозможно, а в 5.7 – возможно. В 5.7 есть много инструментов Performance Schema. Сейчас это мой любимый инструмент. Очень хочу, чтобы все перешли на новую версию.
PG Day: К слову о переходе. До сих пор есть люди, у которых старые версии. Это банальная лень и безответственность, или есть какие-то объективные сложности с переходом со старых версий на более новые?
Света: Сложности с переходом, в основном, такие. Если у вас предприятие, которое должно работать 24 часа, 7 дней в неделю, то возникает вопрос: как минимизировать время простоя? Второй момент. При обновлении с мажорной ветки на мажорную есть несовместимости. Несовместимости бывают двух видов: формата хранения данных и те, которые связаны с построением планов выполнения запроса оптимизатором.
Несовместимости первого типа не относятся к совсем тяжелым случаям. При переходе с версии 5.1 на что-то более новое приходится делать dump/reload. Это очень медленно. В то время как простой апгрейд с ветки на ветку прост: берем старый data dir, запускаем новую версию и запускаем mysql_upgrade. В последних версиях Oracle делает так, чтобы этот процесс происходил с наименьшими усилиями. Но иногда всё равно возникают проблемы. Либо приходится перестраивать таблицу, писать ALTER TABLE, ENGINE=InnoDB, что тоже, в общем-то, не быстро.
Еще момент. Запросы, выполняемые приложением, оптимизированы под версию, для которой они изначально писались. Что интересно, баги исправляются, оптимизатор работает лучше, а некоторые запросы работают медленнее после обновления. У меня был классический случай. Один клиент пишет: «Мы обновились, и у нас запрос стал работать медленно». Я говорю: «Пришлите свой лог». Он присылает — а у них все запросы написаны с помощью FORCE INDEX. Я говорю: «Попробуйте убрать FORCE INDEX». Он убрал и говорит: «Да, теперь они работают быстрее, чем на старой версии». Всё это придется делать.
PG Day: Ты являешься автором книги “MySQL Troubleshooting?, посвященной вопросу отладки и решения проблем MySQL. Кому она может быть полезна?
Света: Я работала в поддержке MySQL, работала с багами. Люди задавали одни и те же вопросы. Я подумала, что нужно собрать в одном месте информацию о том, что делать, если есть проблемы с MySQL. Хотелось решать более сложные задачи, а не отвечать на одни и те же вопросы. Идея книги в следующем. Вы знаете, как пользоваться MySQL, писать запросы, стартовать. Но у вас возникли трудности: возвращаются неправильные данные, работает медленно. Что делать? Я хотела, чтобы книга отвечала на этот вопрос.
PG Day: Эта книга для широкого круга лиц. Любой человек, который имеет дело с MySQL, должен ее прочитать, чтобы перестать задавать глупые вопросы?
Света: В принципе, да. Не обязательно глупые, но просто иметь возможность понять, что делать. К сожалению, книга выпущена в 2012 году, и в ней нет последних фич. Но принцип до сих пор актуален — книгу нужно открывать, чтобы понять что делать, если у вас какая-то проблема с MySQL.
PG Day: Планируется ли переиздание книги, второе издание — про проблемы с новыми фичами?
Света: Прямо сейчас этим не занимаюсь, но планирую.
PG Day: К слову, о новых фичах. Насколько мне известно, ты способствовала вопросу реализации поддержки JSON в MySQL. Расскажи про этот опыт. Сейчас это очень модный тренд в мире баз данных.
Света: На самом деле, всё это очень интересно. Поддержка JSON — worklog, который появился еще до того, как я стала инженером технической поддержки MySQL (это было до 2006 года). В нем было описано, какие функции должна поддерживать MySQL. Но кто-то должен был это двигать, и сделали проект внутри поддержки. Я подумала, почему бы не заняться этим вопросом? MySQL не хотелось повторять опыт с XML-функциями. Функции были имплементированы, но работали не совсем так, как хотелось сообществу. Решили, что я сделаю design prototype в виде UDF-функций. Этот design prototype был доступен в виде проекта MySQL Labs. Люди пользовались, присылали баги. В последствии Optimizer Team должны были на основании design prototype реализовать функции на уровне сервера так, чтобы они были оптимизированы и работали быстро.
В 2012 году я сделала первую версию, она пошла на внутреннее review. Тогда мне сказали, что всё надо переделать. Я переделала и в 2013 году, наконец, показала публике. В это время пришли запросы на новые фичи: появились функции json_depth и json_length (по просьбе сообщества). Это не было каким-то моим изобретением или изобретением компании. Я занималась исправлением багов, наполнением новой функциональности. Дизайн был «отполирован». Наконец, появился design prototype стандарта SQL для JSON. Не знаю, утвержден он сейчас или нет – перестала за этим следить. Был имплементирован синтаксис.
У функций UDF сначала был несколько странный синтаксис. Но я не работала специально над синтаксисом, потому что тогда не было понятно, что будет со стандартом. Если MySQL собирался это внедрять в серверный код, то хотелось, чтобы он получился не сильно специфичным для MySQL — чтобы синтаксис было достаточно просто использовать. Когда всё протестировали, команда оптимизаторов сделала тип данных. Это не pluggable. Я не могла сделать это без их помощи.
PG Day: Разработка JSON продолжается, фичи добавляются?
Света: Да. В версии 8.0.2, которая еще не вышла, они хотят сделать так, чтобы для функции JSON_SET и JSON_REPLACE был in-place update. Что сейчас вообще происходит с JSON? Как правило, JSON — это большой, длинный документ (допустим, 1 килобайт). Допустим, вы хотите поменять какой-то элемент — например, название книги. Сейчас приходится полностью перезаписывать этот 1 килобайт. Это не очень эффективно. Переписать 1 килобайт — не страшно. Но если приходится перезаписывать много таких строк, это становится неэффективно. Они в 8.0.2 анонсировали, что сделали in-place update — что будет обновляться только небольшая часть документа JSON. Это говорит о том, что JSON развивается, и дальше будет что-то интересное.
PG Day: Большое спасибо за такой подробный и обстоятельный рассказ. Хочу попросить тебя дать небольшой анонс мастер-класса, который ты дашь летом на PG Day. Он будет посвящен отладке производительности MySQL. Мастер-класс запланирован большой и объемный: целых восемь часов. Каким вопросам ты собираешься уделить внимание, специалистам какого профиля он будет полезен?
Света: Он будет полезен тем, у кого есть проблема с производительностью MySQL, и кто хочет что-то сделать, чтобы ускорить работу MySQL. На мастер-классе я, начиная с азов, расскажу, что надо знать, перед тем как приступать к отладке, как разобраться, что именно работает медленно. Что такое тестовый сервер, каким образом его использовать для отладки проблем с производительностью. Будет четыре основных части: медленные запросы и их оптимизация; блокировки. Расскажу, как оборудование и конфигурация влияют на работу MySQL.
Мастер-класс, в первую очередь, для DBA и разработчиков. Разработчики не всегда могут что-то сделать на оборудовании. Но, с другой стороны, разработчик приложений может что-то сделать с медленными запросами и блокировками. Я затрону все инструменты – начиная с тех, которые доступны уже очень много лет, и заканчивая современными. Постараюсь рассказать про инструменты, которые доступны либо непосредственно из MySQL Command-Line клиента, либо из командной строки Linux. Немного затрону и графические инструменты, покажу, как они выглядят.
Почему я придерживаюсь такого подхода? Любой графический инструмент всё равно берет откуда-то данные: либо из SQL-команд, либо из командной строки. Задания будут по всем этим вопросам. Вам придется отладить пару запросов и решить проблему с блокировками.
PG Day: В заключение хочу попросить тебя дать напутственное слово или совет для начинающих специалистов по базам данных. Что изучать, какие технологии посмотреть, какие статьи, блоги, книги почитать. Что будет полезно, чтобы эффективно развиваться в этой профессии?
Света: Что касается блогов, в MySQL существуют два места. Первое — это «Планета MySQL», которая поддерживается Oracle и представляет собой агрегатор всех интересных англоязычных блогов по MySQL. Все основные люди там есть. Второе — это Percona Database Performance Blog. Это блог инженеров Percona. Возможно, Percona стала такой успешной компанией благодаря блогу. Когда я работала в Oracle, то очень часто цитировала Percona Blog, потому что там очень хороший технический контент.
Что касается книг, то могу посоветовать свою книжку “MySQL Troubleshooting”. “High Performance MySQL” Петра Зайцева, Вадима Ткаченко и Бэрона Шварца. Для тех, кто делает сложные вещи с репликацией — книгу “MySQL High Availability?. Авторы — бывшие сотрудники MySQL replication team: Чарльз Белл, Mats Kindahl, Lars Thalmann. Mats сейчас ушел из команды MySQL. Чарльз занимается MySQL utilities. Ларс — менеджер уже большей команды, чем Replication Team. Тем не менее, они про это писали: как делаются разные репликации, какие есть «грабли», и как их обойти. Полкниги этому посвящено. Полкниги посвящено решению, которое стало MySQL Fabric.
Есть еще книга “SQL Antipatterns?, автор — Bill Karwin, подходит для всех баз данных, в том числе для MySQL. Есть еще книги. Но, наверное, на этом остановлюсь.
Поделиться с друзьями