Интервью: Percona (Петр Зайцев и др.) про MySQL и другие СУБД 0

Компания Percona была основана в 2006 году выходцами из России, выпускает комплекс решений для СУБД MySQL и не только. Её сотрудники, включая генерального директора Петра Зайцева (Peter Zaitsev), ответили на вопросы nixp.ru в этом эксклюзивном интервью…

Почему из NoSQL-решений в Percona выбрали (в 2015 году) MongoDB?

Пётр Зайцев: Мы считаем, что MongoDB стала «новой MySQL» во многих аспектах. Эта база данных изначально делала акцент на простоте использования для разработчиков и часто выводила этот показатель на принципиально новый уровень. Во многих средах используется как MySQL, так и MongoDB, и вопрос совместимости достаточно важен. В таком случае работать по модели «one stop shop» и предоставлять услуги для обеих баз может быть выгодно.

Стоит ли ожидать какого-то взаимного обмена внутренними наработками между MySQL и MongoDB? В каких областях вообще есть такая необходимость?

Пётр Зайцев: Со своей стороны мы определённо собираемся этим заниматься. Разумнее не пытаться превратить одну базу в другую, а предоставить удобные инструменты, за которые нас ценят в сообществе, тем более что они 100% открытые и бесплатные. Если вы сейчас скачаете наш набор утилит Percona Toolkit, то там есть pt-mongodb-summary, pt-mongodb-query-digest — у нас были аналогичные утилиты для MySQL, теперь они есть и для MongoDB. Наш новый продукт Percona Monitoring and Management (PMM) изначально был ориентирован не только на MySQL, Percona Server для MySQL и MariaDB, но и на MongoDB и Percona Server для MongoDB. Мы смотрим на области, в которых MySQL более развита — вероятно, мы перенесём ещё какие-то из этих возможностей в мир MongoDB.

JSON в MySQL: можно ли считать сегодняшнюю реализацию полноценной и в каких случаях разумно использовать?

Пётр Зайцев: Поддержка JSON в MySQL 5.7 достаточно качественная, и её должны оценить многие пользователи реляционных баз данных, заинтересованные в возможностях документоориентированных СУБД. Однако, наличие такой поддержки не делает MySQL аналогом MongoDB, т.к. для доступа к данным по-прежнему нужно использовать язык SQL, который принципиально отличается от языка, который использует MongoDB и который новое поколение разработчиков считает более простым для понимания. В MySQL также есть что улучшать, чтобы индексы лучше работали для такого типа данных, как JSON.

Света Смирнова: В версии 5.7.12 появились Document Store и похожий на MongoDB NoSQL-интерфейс к данным, хранящимся в формате JSON. Теперь вы можете выбирать язык запросов. Об особенностях работы с NoSQL и видимых аспектах его реализации хорошо написал Александр Рубин в этом посте (здесь и далее посты из Percona Database Performance Blog на английском языке).

Отказоустойчивый кластер с автоматическим failover в MySQL: какие решения оптимальны? Интересуют два пути: «родными» механизмами MySQL и сторонними инструментами.

Пётр Зайцев: Это, скорее, тема для отдельной книги, чем для интервью. Нет, в самом деле. В этой области доступно несколько решений, и все они имеют свои достоинства и недостатки — например, PRM, MHA, PXC.

Какими основными средствами пользуются в Percona для мониторинга производительности MySQL?

Пётр Зайцев: Мониторинг — достаточно многогранная тема. Для проверки состояния базы данных в режиме реального времени у нас есть Percona Toolkit — набор утилит, вызываемых из командной строки. Мы также создали свой инструмент мониторинга на основе Grafana и Prometheus — Percona Monitoring and Management с расширенными возможностями визуализации, что достаточно важно для мира бизнеса, не только для тех технических специалистов, кто непосредственно работает с базой. Помимо этого, мы установили партнёрские отношения с рядом компаний (это VividCortex, SeveralNines, MonYog, SolarWinds) для предоставления дополнительных возможностей мониторинга нашим клиентам. Честно говоря, мы часто пользуемся и тем, что уже установлено у клиентов нашей компании, поскольку на момент возникновения проблем бывает уже поздно устанавливать какие-либо новые решения для мониторинга.

У многих в сообществе исторически сложилось такое мнение, что PostgreSQL считают оптимальным свободным решением для крупных баз данных. Насколько это технически справедливо для современной MySQL?

Анастасия Распопина: Наверное, не ошибусь, если скажу, что во многих случаях для проекта выбирают ту СУБД, с которой члены его технической команды чаще имели дело. В России PostgreSQL-сообщество много инвестирует в обучение ИТ-специалистов, постоянно генерирует разного рода информацию для пользователей. По PostgreSQL проводится огромное количество мероприятий. Тут можно подискутировать — раз мероприятия проводятся, значит, есть спрос. Но обратное тоже верно: мероприятия проводятся, и увеличивается количество людей, знающих о технологии и заинтересованных в её использовании. Соответственно, при такой активности сообщества людей с PostgreSQL-экспертизой здесь больше, и логично, что они выбирают СУБД, с которой они работали и по которой есть огромное количество материалов на русском языке. В том числе такой выбор делается и для хранения больших объёмов данных. Про сильную репутацию PostgreSQL у нас в сообществе я рассказала: она частично обуславливает то мнение, о котором вы упомянули. Про техническую часть может рассказать Света, тем более что она активно взаимодействует с компанией Postgres Professional, у нас был даже общий доклад «Миллион запросов в секунду».

Света Смирнова: Если говорить про общий доклад, то по его мотивам была написана серия постов. Вот здесь первый, ещё есть по тегу «OpenSource Databases on big machines». Есть перевод на Хабре.

Но если не сравнивать MySQL и PostgreSQL, я тут далеко не первопроходец. MySQL используется такими компаниями, как Booking, Facebook, Nokia, Amazon, Twitter, PayPal, Google. Поверьте, данных у них много. Из своей практики я помню случай, когда у клиента максимальный размер InnoDB Redo Log (аналог WAL в PostgreSQL) был выставлен в 1 терабайт, и они не могли сделать резервное копирование, потому что лог перезаписывался, пока копировались данные!

Короткий ответ: критических ограничений нет уже много лет. Во всяком случае, с тех пор, как появился движок InnoDB. Длинный ответ: в реальности вы можете столкнуться с той или иной проблемой. Описывайте её, присылайте разработчикам (bugs.launchpad.net, bugs.mysql.com) и ждите улучшений. Из последних мне хочется особо отметить READ ONLY-транзакции, впервые появившиеся в версии 5.6 и улучшенные в 5.7 (dimitrik.free.fr №1, dimitrik.free.fr №2) и parallel doublewrite buffer.

Бурного развития каких технологий/компонентов в MySQL стоит ожидать в ближайшие годы?

Света Смирнова: сегодня основной фокус разработчиков на поддержке JSON и масштабирования. Появился InnoDB Cluster, который может составить конкуренцию Percona XtraDB Cluster и Galera Cluster. MariaDB разрабатывает MaxScale — продукт, объединяющий в себе прокси, роутер и фильтры. Доклады про ProxySQL были самыми популярными на последней конференции Percona Live: он включает в себя не только прокси, но и роутер, и возможность переписывать запросы. Пост о настройке шардинга при помощи ProxySQL есть здесь.

Нельзя не отметить новый Data Dictionary в версии 8.0. Для всех, кто пытался ускорить резервное копирование без потери надёжности или работал с такими проблемами изменения описания таблиц, как ускорение этой операции и восстановления в случае ошибки, это долгожданное известие. Многих современных проблем с производительностью просто не станет.

Многие ИТ-компании говорят об остром недостатке квалифицированных кадров в последние годы. Наблюдаете ли и вы такую проблему?

Анастасия Распопина: Если говорить об ИТ-рынке вообще, то найти в веб-студию программиста для стандартных интерфейсов — это одно, а найти для «Перконы» разработчика баз данных — это совсем другое. Вероятность найти толкового человека распространённой профессии, со знанием модного языка программирования и для стандартных задач всегда значительно выше. То есть проблема поиска квалифицированных кадров для разработки СУБД будет иметь место всегда, просто в силу сложности самой предметной области.

Как эта проблема решается у нас? Во-первых, мы поощряем сотрудников за рекомендации, а в прошлом году запустили программу выплаты бонуса за рекомендацию и для несотрудников. У нас очень высокий процент тех, кого в компанию привёл кто-то из знакомых. Толковые люди имеют свойство общаться, поэтому у нас постоянный приток рекомендаций.

Во-вторых, найм сотрудников «Перкона» осуществляет по всему миру. Да, иногда может быть критично присутствие человека в определённом часовом поясе или работа в определённые часы, тогда эта информация выносится в описание вакансии. Но есть позиции, для которых регион проживания может быть любым. Это расширяет возможности для поиска талантливых, сильных специалистов.

Ещё Пётр упоминал специфичную для России проблему стеснительности, и я с этим тоже часто встречалась при общении с нашими соискателями. У нас совестливый человек, если он на 80-90% подходит для вакансии, обязательно скажет, что он не годится. В большинстве других культур людям свойственно преувеличивать свои заслуги, они могут и на 30% не подходить, но уверяют HR-отдел и потенциального менеджера, что справятся с чем угодно. Иногда правильно честно сказать, что 80% требуемого ты уже знаешь, а 20% нужно «докачать» — и может оказаться, что ты лучший кандидат, пусть и не со 100% попаданием в описание вакансии.

В чём заключается нынешнее взаимодействие Percona с MariaDB Foundation? Есть ли какой-то контакт с Oracle?

Света Смирнова: В настоящий момент нас нет в списке спонсоров MariaDB Foundation, но это не значит, что мы не сотрудничаем. Мы ездим на мероприятия, проводимые Foundation, в том числе Developer Meetings, участвуем в обсуждениях. Инженеры MariaDB портировали некоторые нововведения Percona Server, такие как Backup Locks и TokuDB. Аналогично в Percona Server есть возможности, изначально разработанные командой MariaDB. Percona Support включает поддержку MariaDB.

Что касается Oracle, то у нас хорошие отношения: инженеры Oracle приезжают на нашу главную конференцию Percona Live, обсуждают планы на будущее. Например, поле THREAD_OS_ID в таблице performance_schema.threads было добавлено буквально через несколько дней после такого обсуждения. Percona постоянно присылает исправления для багов, повторяемых в Oracle MySQL Server. Многие из них принимаются.

Много ли компаний из России и стран СНГ обращаются за поддержкой в Percona?

Анастасия Распопина: На самом деле, Пётр уже отвечал на подобный вопрос в одном из интервью от 2015 года. Практически со всеми клиентами, настоящими или потенциальными, мне доводилось общаться, и это не огромное число компаний. В то же время среди наших клиентов за рубежом достаточно много людей, которые начали пользоваться ПО «Перконы» ещё в России, а потом уехали за границу и предпочли «Перкону» как поставщика услуг, уже знакомого им с хорошей стороны.

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

Есть ли заметные отличия в типе проблем, с которым обращаются за поддержкой компании разных регионов мира?

Света Смирнова: Я бы не сказала, что проблемы сильно отличаются. Скорее, разным бывает основной способ коммуникации. В США чаще любят обсуждать проблемы по телефону. Встречались ещё ситуации, когда сходились региональные особенности и нюансы непростого бизнеса. Я не могу вдаваться в детали, но для таких клиентов всегда применяется индивидуальный подход.

В России сейчас в моде импортозамещение (замена западных коммерческих решений «отечественными» альтернативами). К этому понятию часто относят свободное ПО — в виде пересборок софта российскими компаниями, которые потом сертифицируются. В области СУБД обсуждают преимущественно PostgreSQL. Что в Percona думают об этом?

Пётр Зайцев: Позиции PostgreSQL в России традиционно были сильнее, чем, скажем, в США. Думаю, на это повлияло несколько факторов. Во-первых, компанией-разработчиком (и владельцем) MySQL является Oracle — американская компания, — в связи с чем рекомендовать MySQL в качестве продукта для импортозамещения намного сложнее, хоть это и свободное ПО. Во-вторых, играет свою роль и то, что PostgreSQL не разрабатывается одной компанией — благодаря этому вендоры, специализирующиеся на оказании услуг для PostgreSQL, находятся в равных стартовых условиях, и возникает ситуация с несколькими поставщиками услуг на локальном рынке, что и произошло в России. Наконец, более «либеральные» условия лицензии PostgreSQL налагают меньше ограничений на то, как и где развёртывать PostgreSQL, поэтому больше компаний поставляют свои кастомные версии этой СУБД с дополнительными возможностями под коммерческими лицензиями.