Henrik Ingo, Senior Performance Engineer at MongoDB. Henrik предоставляет консультации по производительности MongoDB, является основным контрибьютором в Impress.js, также имеет несколько принятых пулл-реквестов в Linux

https://www.linkedin.com/in/heingo/
https://twitter.com/hingo

Ты успешно работаешь с производительностью уже около 15 лет.
Как выбрал для себя это направление?

Мне кажется, я всегда работал с производительностью. С базами данных и MySQL, в частности, работаю последние 10 лет. Чаще всего консультанты решают подобные проблемы, связанные с базами данных. Но сама производительность может подразумевать под собой много факторов. В половине случаев это даже касается кода, а не базы данных. В таких случаях решаю проблемы, например, с тем, что приложение делает неправильно, и что создает проблемы с производительностью. А иногда нужно действительно поменять сервер или другие решения. Потому, когда я говорю, что занимаюсь производительностью приложений, — это довольно обширная тема. Речь идет о, так называемых, нетехнических требованиях. Как правило, когда работают над продуктом, основной упор идет на его функциональность и UI. И только, когда время подходит к концу, начинают работать над нефункциональными требованиями. Эти требования относятся к доступности и производительности приложения, что на самом деле очень важно. Ведь, если у тебя нет или не работает база данных, приложение также не будет работать.

«Убедитесь, что вы протестировали то, что приложение действительно должно делать»

Какие первые шаги ты предпринимаешь в работе с производительностью приложений?
Я придерживаюсь одного важного принципа: прежде всего, необходимо протестировать, что делает приложение, другими словами, что делает пользователь приложения. Очень распространено, что запускают стандарты тестирования производительности базы данных (возможно, потому что они доступны в Open Source ресурсах), или делают какие-либо настройки-улучшения, но все это может никоим образом не коррелировать с тем, что делает приложение в продакшне. Подобная ситуация возникает при подборе решений для мониторинга системы. Допустим, у вас настроен мониторинг процесс, который относится к проверке наличия базы данных. Вот вы выполняете SELECT 1. И проверка проходит успешно, но много вещей все также могут не работать. Это же относится и к тестированию производительности. Первым делом, убедитесь, что вы протестировали то, что приложение действительно должно делать.

Когда MongoDB является лучшим выбором?
Как правило, отвечаю на этот вопрос, разбивая его на две части. Вот у вас есть уже хорошо зарекомендовавшие себя реляционные базы данных на основе SQL. Но они являются весьма затратными по времени для их планирования и дизайна. Однако есть некоторые преимущества наличия строгой модели данных со множеством проверок корректности. Также у вас есть новое направление NoSQL баз данных, включая MongoDB, которое было изобретено 10 лет назад. И MongoDB продолжает развиваться. Основные два отличия: MongoDB — масштабная модель, и что данные — не всегда таблицы, столбцы и строки. Таким образом, есть JSON документы и некоторые другие гибкие модели. Это ведет меня ко второй части ответа. Итак, у вас есть много разнообразных баз данных и что же такого особенного в MongoDB? В области баз данных у вас есть спектр, в котором некоторые продукты сосредоточены на простой высокой производительности и масштабировании базы данных. Как MemcacheDB (https://en.wikipedia.org/wiki/MemcacheDB) или что-то в этом роде, так что это просто базы данных «ключ-значение», но они могут очень хорошо масштабироваться. Однако у них не так много функций. А в MongoDB мы всегда стараемся сделать и то, и другое. Уже давно MongoDB поддерживает репликацию и работает гладко. И я очень впечатлен этой базой данных. Кроме того, у нас очень богатый Query-language (язык запросов). Несмотря на то, что язык запросов имеет другой синтаксис, но функционально он соответствует тому, что вы можете делать с реляционной базой данных. Это действительно уникально.

Существуют ли проекты, для которых MongoDB не будет лучшим решением?
Их все меньше и меньше. Раньше я говорил, что у нас нет транзакций, и если у вас есть приложение, которое является очень «транзакционным», это может быть проблемой. Но теперь вы можете сделать это с помощью MongoDB.

Какие инструменты ты используешь в своей работе?
Если вы используете наш облачный сервис Atlas, есть инструмент мониторинга, но я использую его очень редко. Одна из причин заключается в том, что когда работал консультантом и был у клиента, я не мог приступить к установке некоторых инструментов. Потому как, мог потратить пару дней только на установку. Я часто использую скрипты, написанные на Python. Иногда эти сценарии даже не имеют графического интерфейса, но они могут создавать гистограммы или что-то для получения наглядной картины. Таким образом, я использую простой инструмент, который могу настроить, не будучи root user (Прим. пользователем с расширенными правами и доступами). А мой коллега разработал Mtools (M — от MongoDB). Эти инструменты удобны и их автор — Томас Рюктис (Thomas Rückstieß). Mtools предназначены для разных вещей, а некоторые из них также используются для анализа, и я их тоже часто использую. В принципе, тип инструментов, которые хотел бы использовать в первую очередь, - графики. Даже если вы не знаете математику и статистику, попробуйте использовать Excel или что угодно для рисования диаграммы для ваших данных. Это может помочь вам найти причину и что является симптомом проблемы.

«Take one (thing) at a time»

Как ты решил проблему тестирования производительности AWS (Amazon Web Services)?
В течение нескольких лет я работал над нашим тестированием производительности, и мы использовали Amazon для проведения обширных тестов производительности. Мы могли обрабатывать вплоть до 16 серверов Amazon. И первые несколько лет сталкивались с проблемой большой вариабельности результатов. Проблема была не на стороне MongoDB — было слишком много случайностей. Мы потратили на этот проект около трех месяцев и много времени тестировали Amazon. Мы сравнили много вещей: версии Linux, множество опций масштабирования CPU и так далее. Процесс был действительно долгим. Я уже рассказывал вам об одном из моих любимых принципов, а другой, который хотел бы подчеркнуть здесь — take one (thing) at a time. Что значит выполнять только одно действие и не приступать к другому, пока не закончишь. Поэтому мы использовали такой подход для решения этой проблемы.

«Участвовал во многих конференциях и однажды устал от существующих инструментов для презентаций»

Твои проекты являются весомым вкладом в Open Source, расскажи историю об impress.js:
Impress.js на данный момент пока является фреймворком, а не приложением. С помощью данного фреймворка вы можете создавать презентации в браузерах, используя HTML и CSS. Участвовал во многих конференциях и однажды устал от существующих инструментов для презентаций. Это меня и побудило найти impress.js. Человек, создавший его, в тот момент прекратил активно его развивать. Я написал улучшения и отправил парочку pull-request'ов. В следующие пару лет дополнил фреймфорк дополнительной функциональностью. И на данный момент являюсь его основным мейнтенером. Когда был консультантом и почти не писал свой кода, этот проект придавал мне силы и вдохновение.

«Если бы у меня была скучная работа, говорить было бы не о чем»

Как ты выбираешь тему для конференции? Сколько времени требуется для подготовки?
Считаю, что темы основаны на нашем опыте, которым можно делиться на конференциях. Поэтому у меня должно быть что-то интересное в наличии. Если бы у меня была скучная работа, говорить было бы не о чем. Это первый момент. Более того, многие годы я мог говорить о продуктах из Open Source. Вы можете подавать несколько предложений организаторам конференции, и они выбирают. Когда меня приглашают, всегда спрашиваю, что они хотят услышать. Поэтому стараюсь всегда получать обратную связь для представления наилучшей темы для конкретной конференции.

«Возможно, однажды именно вы измените мир к лучшему»

Какой твой совет людям, которые бы хотели последовать твоему примеру?
Я бы порекомендовал максимальное погружение в Open Source. Вы можете там многому научиться. Также делать то, к чему у вас есть страсть и к чему лежит душа. Возможно, однажды именно вы измените мир к лучшему.