Сегодня мы поговорим с Николаем, «борцом» за продвижение новых технологий в мире БД, членом нашего программного коммитета и активным участником всевозможных конференций. Главные темы — самоуправляемые СУБД, DBA AI, облака, NoSQL, встроенные механизмы контроля БД, доклады на РИТ++ и HighLoad++ Siberia, а также масса дельных советов и примеров, которые могут пригодится в реальной работе как разработчику, так и DBA.
— Расскажи немного о себе. Что заканчивал, с чего начинал и чем занимаешься сейчас?
Физтех, ФУПМ выпуска 2004, кафедра ИСП РАН. В далеком 2005 месте с небольшой командой разработчиков из МФТИ и МГУ создал исторически первую соцсеть МойКруг, а потом ещё несколько социальных сетевых проектов.
В 2006-2007 годах поучаствовал в создании типа данных XML для Postgres, тогда же начал проводить постгресовые митапы (не было тогда еще такого слова) в Москве. Теперь это превратилось в русскоязычную группу #RuPostgres, представленную на площадках Meetup.com и YouTube. На Meetup.com мы, кстати, вторые по численности среди всех постгресовых сообществ в мире, более 1600 участников — опередили группу SF Bay Area, но уступаем Нью-Йорку.
Сейчас базируюсь в Долине, регулярно бываю в Москве. Помогаю компаниям получать максимум от Postgres, все чаще — в облаках Amazon и Google.
— На чем сейчас сфокусировано твое внимание в контексте работы с данными?
Одна из самых горячих тем в мире баз данных сегодня — самоуправляемые СУБД. Oracle с прошлого года активно «топит» за то, что их СУБД в облаках автономна и не нуждается в «водителе» (DBA), а митапы с изобретателем понятия self-driving databases и создателем СУБД Peloton профессором Carnegie Mellon University Andy Pavlo собирают по 200+ человек. Кстати, он недавно принял наше приглашение и приедет на Highload++ 2018.
Тем временем Постгрес, будучи, конечно же, лучшей СУБД с открытым исходным кодом и обладая безумно растущей популярностью, сейчас требует огромного количества знаний и ручных действий при эксплуатации.
Я уверен, что в ближайшие годы ситуация изменится к лучшему. Появятся более понятные и автоматизированные инструменты, помогающие и DBA, и разработчикам. Разовьются средства автоматизации тюнинга БД и оптимизации запросов.
— То есть DBA сейчас должен обладать обширными знаниями по различным направлениям? Реальная работа выходит за рамки знаний БД?
Деятельность DBA далеко не тривиальна. Внутри и вокруг БД всегда есть огромное количество служебных данных: внутренняя статистика, логи, показатели мониторинга. Чтобы найти самые узкие места производительности, надо уметь быстро разбираться в куче чисел, а это требует большого количество знаний и опыта. При оценке работы грамотного DBA я часто слышу фразы «чёрная магия», «отличная интуиция». Хотя на самом деле у такого DBA на вооружении прежде всего большой багаж знаний и многие годы опыта.
И в то же время работа DBA сейчас — это чисто ручные действия! Например: нашли самый «тормозной» запрос в pg_stat_statements. Но чтобы его оптимизировать, вам нужен конкретный запрос с конкретными параметрами — ведь от этого зависит и план выполнения, и скорость запроса, и EXPLAIN без них вы не прогоните (ситуация немного улучшится в Постгрес 12, если будет принят патч от ПостгресПро). И что же сейчас делает DBA? Одно из двух: или лезет в логи откапывать конкретные примеры запросов, или же «высасывает из пальца» какие-то значения, оптимизируя в итоге сферического коня в вакууме. Последний вариант хорошо сработает, только если за плечами годы опыта. Если есть «интуиция».
А дальше, когда подобрано конкретное решение, устраняющее проблему, — скажем, надо добавить какой-то индекс — происходит еще более забавная штука. Если DBA опытный и с доступом к «проду», то он, возможно, прямо «на проде» и отладится, и даже индекс создаст вручную. Минуя git, да. Если же «ну прям очень надо» проекту провести DDL через git, то индекс получит название типа i_tmp_killme, а разработчикам будет предложено добавить в систему миграции и отрелизить индекс с уже более вменяемым названием.
Если у DBA авторитет зашкаливает, покорные разработчики и вопросов не будут задавать. Но в компаниях с хорошей культурой git flow, code review, devops и любознательными разработчиками необходимо заранее, до каких-то реальных действий с «боевыми» БД объяснять, почему именно такой индекс выбран, как конкретно он ускоряет запрос. В Долине, кстати, разработчики довольно часто попадаются дотошные, им всё надо разжевать, обосновать. И тут очень выручают облака. Это очень удобно — в пару кликов создать реплику боевой БД в AWS RDS, на ней прогнать `explain (analyze, buffers)` в разных вариантах, найти наилучшее решение и представить его разработчикам с конкретными оценками улучшения производительности и детальной диагностикой. В RDS отлично автоматизировали процессы создания БД, но от массы ручных действий по оптимизации запросов и тюнингу БД RDS никак не избавляет — эксплейны за вас никто (пока!) не прогонит и объяснения разработчикам не представит.
В итоге работа Postgres DBA сейчас выглядит как управление прекрасным скоростным болидом с ручной коробкой передач. Вы любите ездить «на ручке»? Я — да, но только не каждый день.
— Фактически ты кратко описал начало алгоритма действий для поиска проблемных запросов. Данные знания могут служить основой создания новых полезных «надстроек»?
Верно. Именно поэтому область моих интересов сейчас — это DBA AI. Искусственный интеллект, помогающий «готовить» Postgres быстро и эффективно, без чисто ручных действий, в больших и растущих масштабах (как правило, в облаках). Такого в природе пока нет, но работы в этом направлении уже ведутся (одна из интересных, хотя и пока сугубо исследовательских разработок — уже упомянутая Peloton).
— На РИТ++ 2017, выступая с докладом Database First! О распространённых ошибках использования РСУБД, ты говорил, что СУБД — это сердце IT системы, неиспользование возможностей БД — это глупость. Какие примеры ты можешь привести в поддержку своих слов? Прежде всего интересуют факты, когда именно использование стандартных механизмов контроля БД помогло избежать ошибок или наоборот, когда не использование стандартных фич привело к плачевным результатам? Например, отсутствие FK и, возможно, другие, на первый взгляд, обычные механизмы.
В том же докладе я утверждал, что «плачевные результаты» наблюдаются в большинстве проектов, в которых поддержка целостности и «чистоты» данных вынесена из СУБД и реализована на стороне приложения — на PHP, Ruby, Python или на чём-то ещё. По мере того как такой проект накапливает данные, собираются и «грязные данные» — такие как «строки-сироты» (не стали использовать внешние ключи, удалили пользователей, а приписанные им данные удалить забыли), дубликаты (не реализована или некорректно реализована проверка на уникальность на стороне приложения), недопустимые или ошибочные значения. Другой вопрос — как вы относитесь к таким проблемам. Если это небольшой блог, то, может быть, большой беды и нет. Но если это система биллинга… Как только вы «уносите» проверку данных за пределы СУБД, вы допускаете возможность, что появится кто-то (человек или программа), кто эту проверку обойдет. Не говоря уже о том, что ваша реализация проверок может быть далека от идеала.
Так что полезно знать и применять доступные в СУБД возможности поддержки ограничений целостности данных. Их всего несколько: поддержка уникальных значений (на практике реализуется с помощью уникального индекса), внешние ключи, пользовательские ограничения (то, что достигается использованием ключевого слова CHECK), запрет значений NULL, а в Постгресе еще специальные exclusion constraints, с помощью которых удобно обеспечивать, например, непересекаемость интервалов.
Использование подходящих типов данных тоже является важным инструментом обеспечения чистоты данных. Простой пример. Очевидная и очень частая ошибка: использование типа данных text (varchar) для хранения электронных адресов в столбце и навешивание обычного уникального индекса на столбец. Для email-ов нам, конечно, нужны регистронезависимые проверки, поэтому тут лучше подойдет тип данных citext (его нет «в коробке», зато есть расширение citext, доступное в большинстве инсталляций Постгреса) или же навешивание функционального индекса типа `create index … using btree(lower(email))`. Кстати, в последнем случае не забудьте перестроить статистику (`vacuum analyze …`), чтобы postgres осознал, какое распределение в таблице имеют значения выражения `lower(email)`.
Кроме грамотного использования типов данных и поддержки разных видов ограничений целостности СУБД позволяет реализовывать сложную логику проверки данных — например для случаев, когда надо при модификации данных в одной таблице сделать некоторые проверки с использованием сразу нескольких таблиц. Это задача для триггеров. С позиции своего опыта, который включает очень разные проекты и разных людей, я берусь утверждать: нелюбовь к триггерам прямо пропорциональна БД-невежеству разработчика. Такая вот простая формула.
Никто в здравом уме не будет заявлять, что PL/pgSQL или, скажем, PL/Python супербыстры. На обычных арифметических вычислениях PL/pgSQL (как, впрочем, и простой SQL) заметно уступают С и даже PHP. Так медленны, что их для таких целей в значительных масштабах будет использовать только безумец (ну или тот, кто возьмет на вооружение, скажем, библиотеку MADlib, которую я, кстати, очень уважаю и иногда с удовольствием использую). А вот для работы с очень большим количеством данных, когда надо найти правильные иголки в стогах сена, нет ничего лучше позиции «рядом с данными», когда на вашей стороне играют все доступные в БД индексы и отсутствие сетевой сложности, и помощи одного из двух самых популярных языков программирования в мире — SQL. Не использовать эти возможности, когда это точно выгодно, и есть глупость! Грамотно написанный триггер и быстро отрабатывает, и довольно прост в отладке (для профайлинга и отладки помогают расширения pg_stat_statements и auto_explain с включенными опциями `pg_stat_statements.track = all` и `auto_explain.log_triggers = on`) и, главное, является рубежом, который не преодолеют грязные данные.
— В продолжение предыдущего вопроса, скажи, почему именно встроенные возможности PostgreSQL по контролю и манипуляциям с данными — оптимальнее и выигрышнее, чем самописные конструкции?
Одна очевидная причина: встроенные возможности разработаны и многие годы развиваются умными людьми, создателями Постгреса — такими как Том Лейн.
Другую — архитектурную — причину мы уже обсудили, осталось разве что проиллюстрировать. Вот сколько у вас входов в дом? Один? Два? Когда уходите, сколько дверей закрываете/контролируете? Точно же не десять? В современном проекте может быть одновременно и веб-сайт, и back-office, и различные API для мобильных приложений, а может еще и для внешних пользователей. Если вы реализуете поддержку целостности средствами приложения, то в вашем доме оказывается множество дверей, через которые входят и выходят посетители (в случае БД — данные). А если вам еще больше «повезло» и проект развивается силами не пары-тройки программистов, а большой команды или даже группой команд, то все, привет, приехали. Ваши двери сделаны и поддерживаются разными людьми/командами, которые зачастую еще и говорят на разных языках… Понятно же, о чем речь, да? Или вам придется ограничивать и сдерживать развитие проекта («нельзя подключать этот уже готовый GUI для работы с данными — ведь тогда менеджер сможет в БД записать что угодно, лучше уж мы сами создадим админку!..») или же как-то синхронизировать разработку одних и тех же механизмов контроля данных в разных подсистемах, зачастую и на разных языках.
На самом деле я тут рассказываю тривиальные вещи, но мои личные наблюдения показывают, как много стереотипов типа однозначных «хранимки — зло» или «FK — большие тормоза» еще живы и приводят к массовому велосипедостроению, и как дорого за это приходится впоследствии платить проектам.
— Очень много обсуждений и вопросов идет вокруг релизов PostgreSQL. Наверное, тебя часто спрашивают о корректных вариантах перехода с версий 9.3 — 9.6 на 10.
Всегда ли использование инструмента pg_upgrade оправданно? Встречал ли ты на практике ситуации, когда нужно опасаться данного инструмента?
Был очень болезненный баг в версии 9.3, были бессонные ночи у многих (включая меня) «благодаря» этому багу. К счастью, это уже в прошлом. Конечно, от багов нет стопроцентной страховки, но сегодня pg_upgrade – практически промышленный стандарт, его применение разумно в большинстве ситуаций, когда допустимы несколько минут простоя. Тут повезло тем, кто уже в облаках и с managed database типа AWS RDS — там про него вообще не думают, просто планируют maintenance window и производят апгрейд. Если же вам приходится об этом думать, обязательно стоит поэкспериментировать по возможности, проведя как хотя бы несколько тестовых прогонов на склонированной БД (именно в полноценном объеме и в идентичной инфраструктуре — конечно, если позволяют объемы данных и ресурсы). Тут, кстати, заманчиво опять же использование облаков, но уже на более низком уровне — просто EC2-машины в Amazon, например. Это очень дешево, если вы не забываете про такую возможность как спотовые инстансы.
Свежий и подробно расписанный кейс, как 1500 БД общим объёмом 55 ТБ в 6 ДЦ проапгрейдили всего за 15 минут: https://bricklen.github.io/2018-03-27-Postgres-10-upgrade/. Обратите внимание, как много тестов они проделали, прежде чем проводить операции «в бою». Главная формула этой статьи универсальна: «Test, find problems, fix; lather, rinse, repeat». Тут мне очень хочется опять завести речь про автоматизацию экспериментов, но я вас, наверное, уже утомил.
Если же и такое малое время простоя недопустимо, то нужно рассматривать более трудоемкие в реализации решения — прежде всего, на базе pglogical (свежий пост на эту тему).
— На майский РИТ++ ты заявлен с докладом "Continuous Database Administration". В описании выступления первая часть посвящена инструменту «postgres_dba». Расскажи, пожалуйста о нем.
postgres_dba – это такой «полуавтоматический» «швейцарский нож» для работы с Постгресом. У любого опытного DBA есть накопленная годами подборка полезных скриптов, отвечающих на разные вопросы — от «какие таблицы в этой БД занимают больше всего места» до оценки bloat-а, нахождения неиспользуемых или избыточных индексов, работы с pg_stat_statements. Я перелопатил не одну подборку таких скриптов и сделал интерактивную менюшку для них — и теперь родной постгресовой консольке, psql, вы можете «общаться» с Постгресом, получая ответы на свои вопросы очень быстро. Очень просто добавить в этот набор и любые свои отчёты или интерактивные скрипты (например, можно добавить что-то для добавления/удаления пользователей БД с генерацией паролей так, чтобы это было максимально безопасно).
Работу DBA этот инструмент, конечно, не делает полностью автоматизированной. Но уже заметно ускоряет. Для себя я отметил, что получившийся инструмент сближает DBA и БД, с которыми она/он работает: отчёты теперь доступны на расстоянии нажатий всего пары клавиш, время сильно экономится, полноценное «общупывание» БД происходит очень быстро, а значит и чаще. Проект открытый, приглашаю попробовать и поучаствовать в развитии: https://github.com/NikolayS/postgres_dba.
— Вторая часть доклада состоит из нескольких блоков, посвященных автоматизации, облачным решениям и вопросам, связанным с AI. Как ты думаешь, какое из этих направлений будет активно использоваться в ближайшем будущем?
Тут сразу несколько направлений. Во-первых, Amazon, Google и Microsoft уже предоставляют так называемые managed databases — это когда за вас решаются вопросы развертывания БД, настройки репликации, switch-over/fail-over, автоматических бэкапов и базового мониторинга. Но такие решения, хоть и строятся на Open Source продуктах, сейчас сделаны отнюдь не в духе FLOSS. AWS RDS даже не дает скачать бэкапы, не говоря уж о возможности репликации куда-то еще, кроме как на другой RDS-инстанс. А Google Cloud SQL for Postgres, хоть и объявил в апреле о GA, все еще чрезвычайно беден в плане конфигурации Постгреса. Не дает даже логировать запросы, только ошибки.
Но в целом это все успешные истории построения проприетарных решений на базе открытых, особенно если говорить об RDS и RDS Aurora. В то же время я верю, что в ближайшем будущем появятся открытые аналоги, готовые работать где угодно (в амазоновоском или гугловском облаке, в частном облаке или же on-premise), при этом не менее продвинутые, с различными вариантами построения HA-решений, политиками бэкапов, при этом с полным доступом к ОС, ФС с superuser-доступом. По моим наблюдениям, эта ниша точно есть и она пока не занята. Кстати, строительные блоки для этого уже созданы и обкатаны в многочисленных компаниях: тут и Patroni со Stolon для поднятия мастера и реплик с поддержкой автофейловера, и не так давно начавшиеся развиваться k8s-операторы от Zalando и от Crunchy, и решения для бэкапов WAL-E, WAL-G, pgBackRest.
Кстати, инженерам из России — вообще всем, не только DBA — я настоятельно рекомендую поскорее двигать свое сознание в сторону облаков, если они еще не сделали этого. Тут вышла странная история. Общеизвестно, что в большинстве случаев задержка с адаптацией новых технологий по сравнению с Долиной в России составляет два-три года. А вот в случае облаков этот лаг явно больше. В США облака сегодня — это практически уже commodity (сорри, не знаю русского слова-эквивалента). А вот у нас в прошедшие годы «облачных» докладов на конференциях РИТ/Highload++ и прочих было по пальцем сосчитать. Но сейчас, кажется, чувствуется переломный момент. По разным причинам люди наконец-то созревают. Улучшаются каналы до европейских AWS-регионов, RTT из Москвы, по моим наблюдениям, опустился уже до ~50 мс. Яндекс и Mail.ru вовсю растят собственные решения — очень ждем, когда можно будет просто зарегистрироваться, ввести данные карточки и начать использовать. Вдобавок Роскомнадзор тут старательно учит всех гибкости и мобильности.
Вторая история — постепенное осознание того, что нужна еще большая автоматизация, чем только лишь поднятие Постгреса, настройка репликации и бэкапов. Если вам более 35-40 лет и вы программист, то, возможно, вы застали эру работы без систем контроля версий (сейчас повсеместно Git, а до него — CSV, SVN и прочие). Люди использовали ftp, верстальщик отправлял HTML по почте программисту. Был мрак, такой каменный век, что сейчас даже сложно уже представить. Всё это уже автоматизировано, отдельное спасибо Линусу Торвальдсу, а также командам GitHub, BitTorrent, GitLab. Та же история с тестами — когда-то было только ручное тестирование, теперь же повсюду автотесты и CI. Аналогично с вопросами деплоя: есть devops-инструменты, никакой ручной настройки серверов и сервисов, всё скриптуется, автоматизируется.
Так вот, в области DBA сейчас, наверное, уже не каменный век (спасибо облачным компаниям за хотя бы базовую автоматизацию), но еще и далеко не железный. Труд DBA по-прежнему ручной. Я уже приводил примеры. Ещё очень многого предстоит достичь, будут появляться новые технологии. У нас в PostgreSQL.support уже проходит внутреннее тестирование аналог ораклового Database Replay, позволяющий проводить массу параллельных экспериментов без ручных действий. Конечно же, прежде всего в облаках. Например, если вы хотите подобрать оптимальный параметр — скажем, попробовать разные варианты значений `shared_buffers`, `seq_page_cost` или же `default_statistics_target` — вам достаточно задать вопрос нашему роботу-DBA Nancy, она развернёт сразу несколько копий вашей БД (одну с вариантами параметров «как сейчас на проде», другие — с такими, которые вы хотите проверить), прогонит кусок реальной нагрузки с вашей боевой БД или же запросы, заданные вами вручную, и сведёт результаты в одну таблицу, где будет видно, как в целом каждый вариант себя показал, сколько времени ушло, плюс сравнение по каждому кластеру из самых нагружающих систему запросов. Аналогично можно поступить, если вы оптимизируете набор индексов — можно попросить систему проверить разные индексы.
Тут очень важный момент: зачастую, оптимизируя вручную один запрос, вы забываете проверить смежные запросы, а они запросто могут ухудшиться. Недавний пример: соптимизировали было SELECT-ы за счет замещения части индексов таблицы на их более легковесные частичные аналоги (`create index … where …`), но оказалось, что при этом существенно замедлили UPDATE-ы. Причина в том, что после замены индексов перестали срабатывать HOT Updates (кейс подробно разобран в моей статье). Автоматизация экспериментов с помощью нашего решения позволяет увидеть картину целиком, все trade-offs. Только такая автоматизированная система позволяет гарантировать выполнение базового принципа оптимизаций — найденное решение должно улучшать что-то конкретное, не ухудшая при этом всё остальное.
И наконец, третье направление — история с DBA AI. В прошлом году появилось решение, использующие ML, чтобы тюнить Postgres и MySQL, называется OtterTune. Его сделала команда того же Andy Pavlo. До этого появлялись разные решения у проприетарных СУБД — тут выделяется проект AutoAdmin у Microsoft начала нулевых, наработки которого потом перетекли в сам SQL Server. Сегодня весь такой облачный и автономный (якобы) Oracle, а также Peloton, которых я уже упоминал, – еще одни звоночки.
Это направление чрезвычайно интересное. Тут точно стоит ждать прорывов. Я поясню, почему сейчас. Очень важны два аспекта. Первый — взрывное развитие методов машинного обучения, которое мы наблюдаем последние лет пять-шесть, новые технологии, железо. Второй — развитие облаков, их удешевление. Маленькая РИТ-история. Мой добрый друг и физтех Дима Пушкарев рассказывал на РИТ-2013, как он в десять раз снизил стоимость расшифровки генома за счет интересных собственных алгоритмов использования спотовых инстансов в AWS, это был большой прорыв. А потом в 2015 его компанию купил Amazon и поглотил эти разработки, так что теперь EC2-споты являются рабочей лошадкой в огромном количестве компаний, включая крупнейших из списка Fortune-500, например, Disney. Нам споты очень кстати, проведение экспериментов становится экономически выгодным, без них появление нашего робота-DBA Nancy было бы маловероятным.
Тема создания искусственного интеллекта, обучающегося на экспериментах с разными БД и нагрузками (включая ваши) и помогающего инженерам с настройкой БД, индексами, партиционированием, оптимизацией запросов, не нова в научной среде и в enterprise-секторе (разные решения появляются не одно десятилетие и у Oracle, и у Microsoft, и у IBM), но для нас — тех, кто использует в основном Open Source, — это целый новый мир. Некоторые компоненты уже есть, их мы обсудим на предстоящем фестивале РИТ++, но если говорить в целом, то мы пока находимся в самом начале очень интересного пути.
— Мы затронули темы конференции, но не поговорили о тенденциях индустрии в целом. Как ты считаешь, хайп вокруг NoSQL решений уже закончился? Какие прогнозы ты можешь дать по поводу соперничества MySQL и PostgreSQL? Или это можно считать обоюдовыгодным противостоянием?
Хайп изменился. В тренде теперь NewSQL, а не NoSQL. Причем в этом термине зашиты разные смыслы. Можно выделить как минимум три значения. Первое — те же NoSQL-решения, добавляющие поддержку своих диалектов SQL. В этом плане SQL сейчас — язык-победитель. Уродливый, избыточный, с неподъемными талмудами стандарта (в который, кстати, недавно добавили раздел SQL/JSON, работы по внедрению в Постгрес которого ведутся), но он сейчас явно язык-победитель.
Вторая история — это про традиционные РСУБД, расширенные поддержкой нарушающих первую нормальную форму данных, прежде всего данных JSON, что в итоге приводит нас к гибридной модели данных — получаем реляции, например, с JSON-документами внутри. В Постгресе очень давно были массивы, hstore, XML, а теперь и отличная поддержка JSON, с кучей возможностей и различными вариациями индексов. В этом смысле Постгрес — тоже NewSQL-СУБД.
И наконец, третий вариант трактовки понятия «NoSQL»: новые РСУБД, сразу ориентированные на язык SQL. Это прежде всего облачный Google Spanner, опенсорсные CocroachDB и ClickHouse. Создается много интересного, это большой новый вызов Постгресу. Хайпы предыдущих десятилетий — объектные СУБД, потом XML и далее NoSQL — он пережил очень успешно, окреп и вырос, а вот как пойдут дела далее, время покажет.
В целом с вызовами эпохи NewSQL пока неясно. Тут надо много работать, новые решения уже бьют по слабым местам Постгреса: например, один из крупнейших клиентов Citus-а CloudFlare недавно для своей аналитики отказался от их решения (а значит, и от Postgres) в пользу ClickHouse. Что неудивительно — колоночная БД с векторизированными вычислениями и встроенным шардингом в данный момент на задачах аналитики оказывается на голову лучше Постгреса, даже снабженного шардированием от Citus. Если сообществу удастся в обозримом будущем добавить качественную поддержку pluggable engines, новые «движки хранения» — прежде всего, column store, а также row store нового типа (c «undo», с замещением кортежей «на месте», избавляющий от необходимости проведения частых и дорогих операций VACUUM – см. разработку компании EnterpriseDB zheap) — и развить, а может даже и встроить в ядро Постгреса решения для шардинга (решения «сбоку» уже есть, например, Citus, а вот про встроенный ведутся пока только разговоры), то всё у Постгреса будет хорошо в обозримом будущем. Лично я очень надеюсь, что в ближайшие несколько лет Постгрес-сообщество успешно решит перечисленные задачи.
А с MySQL да, есть какое-то взаимовыгодное… Как бы лучше сказать. Наверное, не противостояние, а уже какая-то даже кооперация. Постгресовые конференции приглашают докладчиков из MySQL и Percona и наоборот, делаются совместные бенчмарки (см. совместный доклад разработчиков ПостгресПро и Percona на Highload++ 2016) и так далее. Один из самых активных участников российского постгрес-сообщества — Алексей Копытов, человек из MySQL-сообщества, автор sysbench, активно «топит» за MySQL и против Постгреса, причем почему-то очень часто объявляется в нашей постгресовой фейсбук-группе. Не знаю, что им движет, но в итоге делает он очень хорошую работу, не дает забыть о недостатках Постгреса, подталкивает к развитию.
— И главный вопрос на сегодня. Когда все таки митап-группа #RuPostgres будет первой?
Была некоторая личная скромная цель — обогнать группу SF Bay Area, где я теперь живу. Цель достигнута. Группа Нью-Йорка очень активна, и ее мы пока вряд ли догоним, но меня это особо уже не тревожит. Переезжать туда пока не планирую.
С учетом того, что и я, и соведущий наших трансляций Илья Космодемьянский в основном находимся не в Москве, группу мы сейчас активно тянем в онлайн. Я думаю, тут есть еще очень большой потенциал для роста. По-первых, русскоговорящие постгресмены раскиданы по всему миру. Во-вторых, средства проведения онлайн-митапов становятся доступнее и совершеннее — например, совсем недавно в YouTube чат стал, наконец, сохраняться после завершения трансляции, а это для наших онлайн-сессий очень важно. Во время трансляций там часто разгорались интересные параллельные обсуждения затронутых тем. И вот YouTube теперь синхронно накладывает все реплики на запись, смотреть становится ещё интереснее.
— Поскольку ты отвечаешь за доклады по БД к новосибирскому HighLoad++ Siberia, не могу не спросить, какие темы будут затронуты в этом году и на какие доклады надо обратить внимание в первую очередь? Какова будет специфика сибирского форума, стоит ли туда приезжать после РИТ++?
Конечно стоит. Highload++ Siberia — полноценный, «взрослый» Highload, его не стоит путать с прошлогодним Highload++ Junior. Большая конференция приезжает в новый регион, чтобы активировать обмен опытом между еще большим количеством экспертов. Программа у нее своя, уникальная, сейчас формируется. Мы стараемся минимизировать пересечения тем, представлять новую информацию.
Уже поданы очень интересные заявки. Например рассказ о внедрении ClickHouse в VK, очень интересные доклады от специалистов из Яндекс, Mail.ru, Одноклассников, Badoo — про базы данных, видеостриминг, алгоритмы сжатия.
Отдельно отмечу, что целый блок заявок получен от enterprise-сектора. Местные компании готовы делиться своим опытом работы с Oracle, прежде всего в финансовом секторе. И так вышло, что в этот раз я поддержал большую часть заявок — потому что в отличии от прошлого опыта (когда к нам приходили люди из российского офиса Oracle и не могли ответить даже на базовые технические вопросы) тут есть новые ожидания, видна хорошая техническая экспертиза.
Ну и конечно, будут доклады о Postgres. Обещали приехать Andreas Scherbaum (Greenplum) и Alvaro Hernandez (OnGres), лидеры немецкого и испанского постгресовых сообществ.
Уверен, будет интересно!
— Расскажи немного о себе. Что заканчивал, с чего начинал и чем занимаешься сейчас?
Физтех, ФУПМ выпуска 2004, кафедра ИСП РАН. В далеком 2005 месте с небольшой командой разработчиков из МФТИ и МГУ создал исторически первую соцсеть МойКруг, а потом ещё несколько социальных сетевых проектов.
В 2006-2007 годах поучаствовал в создании типа данных XML для Postgres, тогда же начал проводить постгресовые митапы (не было тогда еще такого слова) в Москве. Теперь это превратилось в русскоязычную группу #RuPostgres, представленную на площадках Meetup.com и YouTube. На Meetup.com мы, кстати, вторые по численности среди всех постгресовых сообществ в мире, более 1600 участников — опередили группу SF Bay Area, но уступаем Нью-Йорку.
Сейчас базируюсь в Долине, регулярно бываю в Москве. Помогаю компаниям получать максимум от Postgres, все чаще — в облаках Amazon и Google.
— На чем сейчас сфокусировано твое внимание в контексте работы с данными?
Одна из самых горячих тем в мире баз данных сегодня — самоуправляемые СУБД. Oracle с прошлого года активно «топит» за то, что их СУБД в облаках автономна и не нуждается в «водителе» (DBA), а митапы с изобретателем понятия self-driving databases и создателем СУБД Peloton профессором Carnegie Mellon University Andy Pavlo собирают по 200+ человек. Кстати, он недавно принял наше приглашение и приедет на Highload++ 2018.
Тем временем Постгрес, будучи, конечно же, лучшей СУБД с открытым исходным кодом и обладая безумно растущей популярностью, сейчас требует огромного количества знаний и ручных действий при эксплуатации.
Я уверен, что в ближайшие годы ситуация изменится к лучшему. Появятся более понятные и автоматизированные инструменты, помогающие и DBA, и разработчикам. Разовьются средства автоматизации тюнинга БД и оптимизации запросов.
— То есть DBA сейчас должен обладать обширными знаниями по различным направлениям? Реальная работа выходит за рамки знаний БД?
Деятельность DBA далеко не тривиальна. Внутри и вокруг БД всегда есть огромное количество служебных данных: внутренняя статистика, логи, показатели мониторинга. Чтобы найти самые узкие места производительности, надо уметь быстро разбираться в куче чисел, а это требует большого количество знаний и опыта. При оценке работы грамотного DBA я часто слышу фразы «чёрная магия», «отличная интуиция». Хотя на самом деле у такого DBA на вооружении прежде всего большой багаж знаний и многие годы опыта.
И в то же время работа DBA сейчас — это чисто ручные действия! Например: нашли самый «тормозной» запрос в pg_stat_statements. Но чтобы его оптимизировать, вам нужен конкретный запрос с конкретными параметрами — ведь от этого зависит и план выполнения, и скорость запроса, и EXPLAIN без них вы не прогоните (ситуация немного улучшится в Постгрес 12, если будет принят патч от ПостгресПро). И что же сейчас делает DBA? Одно из двух: или лезет в логи откапывать конкретные примеры запросов, или же «высасывает из пальца» какие-то значения, оптимизируя в итоге сферического коня в вакууме. Последний вариант хорошо сработает, только если за плечами годы опыта. Если есть «интуиция».
А дальше, когда подобрано конкретное решение, устраняющее проблему, — скажем, надо добавить какой-то индекс — происходит еще более забавная штука. Если DBA опытный и с доступом к «проду», то он, возможно, прямо «на проде» и отладится, и даже индекс создаст вручную. Минуя git, да. Если же «ну прям очень надо» проекту провести DDL через git, то индекс получит название типа i_tmp_killme, а разработчикам будет предложено добавить в систему миграции и отрелизить индекс с уже более вменяемым названием.
Если у DBA авторитет зашкаливает, покорные разработчики и вопросов не будут задавать. Но в компаниях с хорошей культурой git flow, code review, devops и любознательными разработчиками необходимо заранее, до каких-то реальных действий с «боевыми» БД объяснять, почему именно такой индекс выбран, как конкретно он ускоряет запрос. В Долине, кстати, разработчики довольно часто попадаются дотошные, им всё надо разжевать, обосновать. И тут очень выручают облака. Это очень удобно — в пару кликов создать реплику боевой БД в AWS RDS, на ней прогнать `explain (analyze, buffers)` в разных вариантах, найти наилучшее решение и представить его разработчикам с конкретными оценками улучшения производительности и детальной диагностикой. В RDS отлично автоматизировали процессы создания БД, но от массы ручных действий по оптимизации запросов и тюнингу БД RDS никак не избавляет — эксплейны за вас никто (пока!) не прогонит и объяснения разработчикам не представит.
В итоге работа Postgres DBA сейчас выглядит как управление прекрасным скоростным болидом с ручной коробкой передач. Вы любите ездить «на ручке»? Я — да, но только не каждый день.
— Фактически ты кратко описал начало алгоритма действий для поиска проблемных запросов. Данные знания могут служить основой создания новых полезных «надстроек»?
Верно. Именно поэтому область моих интересов сейчас — это DBA AI. Искусственный интеллект, помогающий «готовить» Postgres быстро и эффективно, без чисто ручных действий, в больших и растущих масштабах (как правило, в облаках). Такого в природе пока нет, но работы в этом направлении уже ведутся (одна из интересных, хотя и пока сугубо исследовательских разработок — уже упомянутая Peloton).
— На РИТ++ 2017, выступая с докладом Database First! О распространённых ошибках использования РСУБД, ты говорил, что СУБД — это сердце IT системы, неиспользование возможностей БД — это глупость. Какие примеры ты можешь привести в поддержку своих слов? Прежде всего интересуют факты, когда именно использование стандартных механизмов контроля БД помогло избежать ошибок или наоборот, когда не использование стандартных фич привело к плачевным результатам? Например, отсутствие FK и, возможно, другие, на первый взгляд, обычные механизмы.
В том же докладе я утверждал, что «плачевные результаты» наблюдаются в большинстве проектов, в которых поддержка целостности и «чистоты» данных вынесена из СУБД и реализована на стороне приложения — на PHP, Ruby, Python или на чём-то ещё. По мере того как такой проект накапливает данные, собираются и «грязные данные» — такие как «строки-сироты» (не стали использовать внешние ключи, удалили пользователей, а приписанные им данные удалить забыли), дубликаты (не реализована или некорректно реализована проверка на уникальность на стороне приложения), недопустимые или ошибочные значения. Другой вопрос — как вы относитесь к таким проблемам. Если это небольшой блог, то, может быть, большой беды и нет. Но если это система биллинга… Как только вы «уносите» проверку данных за пределы СУБД, вы допускаете возможность, что появится кто-то (человек или программа), кто эту проверку обойдет. Не говоря уже о том, что ваша реализация проверок может быть далека от идеала.
Так что полезно знать и применять доступные в СУБД возможности поддержки ограничений целостности данных. Их всего несколько: поддержка уникальных значений (на практике реализуется с помощью уникального индекса), внешние ключи, пользовательские ограничения (то, что достигается использованием ключевого слова CHECK), запрет значений NULL, а в Постгресе еще специальные exclusion constraints, с помощью которых удобно обеспечивать, например, непересекаемость интервалов.
Использование подходящих типов данных тоже является важным инструментом обеспечения чистоты данных. Простой пример. Очевидная и очень частая ошибка: использование типа данных text (varchar) для хранения электронных адресов в столбце и навешивание обычного уникального индекса на столбец. Для email-ов нам, конечно, нужны регистронезависимые проверки, поэтому тут лучше подойдет тип данных citext (его нет «в коробке», зато есть расширение citext, доступное в большинстве инсталляций Постгреса) или же навешивание функционального индекса типа `create index … using btree(lower(email))`. Кстати, в последнем случае не забудьте перестроить статистику (`vacuum analyze …`), чтобы postgres осознал, какое распределение в таблице имеют значения выражения `lower(email)`.
Кроме грамотного использования типов данных и поддержки разных видов ограничений целостности СУБД позволяет реализовывать сложную логику проверки данных — например для случаев, когда надо при модификации данных в одной таблице сделать некоторые проверки с использованием сразу нескольких таблиц. Это задача для триггеров. С позиции своего опыта, который включает очень разные проекты и разных людей, я берусь утверждать: нелюбовь к триггерам прямо пропорциональна БД-невежеству разработчика. Такая вот простая формула.
Никто в здравом уме не будет заявлять, что PL/pgSQL или, скажем, PL/Python супербыстры. На обычных арифметических вычислениях PL/pgSQL (как, впрочем, и простой SQL) заметно уступают С и даже PHP. Так медленны, что их для таких целей в значительных масштабах будет использовать только безумец (ну или тот, кто возьмет на вооружение, скажем, библиотеку MADlib, которую я, кстати, очень уважаю и иногда с удовольствием использую). А вот для работы с очень большим количеством данных, когда надо найти правильные иголки в стогах сена, нет ничего лучше позиции «рядом с данными», когда на вашей стороне играют все доступные в БД индексы и отсутствие сетевой сложности, и помощи одного из двух самых популярных языков программирования в мире — SQL. Не использовать эти возможности, когда это точно выгодно, и есть глупость! Грамотно написанный триггер и быстро отрабатывает, и довольно прост в отладке (для профайлинга и отладки помогают расширения pg_stat_statements и auto_explain с включенными опциями `pg_stat_statements.track = all` и `auto_explain.log_triggers = on`) и, главное, является рубежом, который не преодолеют грязные данные.
— В продолжение предыдущего вопроса, скажи, почему именно встроенные возможности PostgreSQL по контролю и манипуляциям с данными — оптимальнее и выигрышнее, чем самописные конструкции?
Одна очевидная причина: встроенные возможности разработаны и многие годы развиваются умными людьми, создателями Постгреса — такими как Том Лейн.
Другую — архитектурную — причину мы уже обсудили, осталось разве что проиллюстрировать. Вот сколько у вас входов в дом? Один? Два? Когда уходите, сколько дверей закрываете/контролируете? Точно же не десять? В современном проекте может быть одновременно и веб-сайт, и back-office, и различные API для мобильных приложений, а может еще и для внешних пользователей. Если вы реализуете поддержку целостности средствами приложения, то в вашем доме оказывается множество дверей, через которые входят и выходят посетители (в случае БД — данные). А если вам еще больше «повезло» и проект развивается силами не пары-тройки программистов, а большой команды или даже группой команд, то все, привет, приехали. Ваши двери сделаны и поддерживаются разными людьми/командами, которые зачастую еще и говорят на разных языках… Понятно же, о чем речь, да? Или вам придется ограничивать и сдерживать развитие проекта («нельзя подключать этот уже готовый GUI для работы с данными — ведь тогда менеджер сможет в БД записать что угодно, лучше уж мы сами создадим админку!..») или же как-то синхронизировать разработку одних и тех же механизмов контроля данных в разных подсистемах, зачастую и на разных языках.
На самом деле я тут рассказываю тривиальные вещи, но мои личные наблюдения показывают, как много стереотипов типа однозначных «хранимки — зло» или «FK — большие тормоза» еще живы и приводят к массовому велосипедостроению, и как дорого за это приходится впоследствии платить проектам.
— Очень много обсуждений и вопросов идет вокруг релизов PostgreSQL. Наверное, тебя часто спрашивают о корректных вариантах перехода с версий 9.3 — 9.6 на 10.
Всегда ли использование инструмента pg_upgrade оправданно? Встречал ли ты на практике ситуации, когда нужно опасаться данного инструмента?
Был очень болезненный баг в версии 9.3, были бессонные ночи у многих (включая меня) «благодаря» этому багу. К счастью, это уже в прошлом. Конечно, от багов нет стопроцентной страховки, но сегодня pg_upgrade – практически промышленный стандарт, его применение разумно в большинстве ситуаций, когда допустимы несколько минут простоя. Тут повезло тем, кто уже в облаках и с managed database типа AWS RDS — там про него вообще не думают, просто планируют maintenance window и производят апгрейд. Если же вам приходится об этом думать, обязательно стоит поэкспериментировать по возможности, проведя как хотя бы несколько тестовых прогонов на склонированной БД (именно в полноценном объеме и в идентичной инфраструктуре — конечно, если позволяют объемы данных и ресурсы). Тут, кстати, заманчиво опять же использование облаков, но уже на более низком уровне — просто EC2-машины в Amazon, например. Это очень дешево, если вы не забываете про такую возможность как спотовые инстансы.
Свежий и подробно расписанный кейс, как 1500 БД общим объёмом 55 ТБ в 6 ДЦ проапгрейдили всего за 15 минут: https://bricklen.github.io/2018-03-27-Postgres-10-upgrade/. Обратите внимание, как много тестов они проделали, прежде чем проводить операции «в бою». Главная формула этой статьи универсальна: «Test, find problems, fix; lather, rinse, repeat». Тут мне очень хочется опять завести речь про автоматизацию экспериментов, но я вас, наверное, уже утомил.
Если же и такое малое время простоя недопустимо, то нужно рассматривать более трудоемкие в реализации решения — прежде всего, на базе pglogical (свежий пост на эту тему).
— На майский РИТ++ ты заявлен с докладом "Continuous Database Administration". В описании выступления первая часть посвящена инструменту «postgres_dba». Расскажи, пожалуйста о нем.
postgres_dba – это такой «полуавтоматический» «швейцарский нож» для работы с Постгресом. У любого опытного DBA есть накопленная годами подборка полезных скриптов, отвечающих на разные вопросы — от «какие таблицы в этой БД занимают больше всего места» до оценки bloat-а, нахождения неиспользуемых или избыточных индексов, работы с pg_stat_statements. Я перелопатил не одну подборку таких скриптов и сделал интерактивную менюшку для них — и теперь родной постгресовой консольке, psql, вы можете «общаться» с Постгресом, получая ответы на свои вопросы очень быстро. Очень просто добавить в этот набор и любые свои отчёты или интерактивные скрипты (например, можно добавить что-то для добавления/удаления пользователей БД с генерацией паролей так, чтобы это было максимально безопасно).
Работу DBA этот инструмент, конечно, не делает полностью автоматизированной. Но уже заметно ускоряет. Для себя я отметил, что получившийся инструмент сближает DBA и БД, с которыми она/он работает: отчёты теперь доступны на расстоянии нажатий всего пары клавиш, время сильно экономится, полноценное «общупывание» БД происходит очень быстро, а значит и чаще. Проект открытый, приглашаю попробовать и поучаствовать в развитии: https://github.com/NikolayS/postgres_dba.
— Вторая часть доклада состоит из нескольких блоков, посвященных автоматизации, облачным решениям и вопросам, связанным с AI. Как ты думаешь, какое из этих направлений будет активно использоваться в ближайшем будущем?
Тут сразу несколько направлений. Во-первых, Amazon, Google и Microsoft уже предоставляют так называемые managed databases — это когда за вас решаются вопросы развертывания БД, настройки репликации, switch-over/fail-over, автоматических бэкапов и базового мониторинга. Но такие решения, хоть и строятся на Open Source продуктах, сейчас сделаны отнюдь не в духе FLOSS. AWS RDS даже не дает скачать бэкапы, не говоря уж о возможности репликации куда-то еще, кроме как на другой RDS-инстанс. А Google Cloud SQL for Postgres, хоть и объявил в апреле о GA, все еще чрезвычайно беден в плане конфигурации Постгреса. Не дает даже логировать запросы, только ошибки.
Но в целом это все успешные истории построения проприетарных решений на базе открытых, особенно если говорить об RDS и RDS Aurora. В то же время я верю, что в ближайшем будущем появятся открытые аналоги, готовые работать где угодно (в амазоновоском или гугловском облаке, в частном облаке или же on-premise), при этом не менее продвинутые, с различными вариантами построения HA-решений, политиками бэкапов, при этом с полным доступом к ОС, ФС с superuser-доступом. По моим наблюдениям, эта ниша точно есть и она пока не занята. Кстати, строительные блоки для этого уже созданы и обкатаны в многочисленных компаниях: тут и Patroni со Stolon для поднятия мастера и реплик с поддержкой автофейловера, и не так давно начавшиеся развиваться k8s-операторы от Zalando и от Crunchy, и решения для бэкапов WAL-E, WAL-G, pgBackRest.
Кстати, инженерам из России — вообще всем, не только DBA — я настоятельно рекомендую поскорее двигать свое сознание в сторону облаков, если они еще не сделали этого. Тут вышла странная история. Общеизвестно, что в большинстве случаев задержка с адаптацией новых технологий по сравнению с Долиной в России составляет два-три года. А вот в случае облаков этот лаг явно больше. В США облака сегодня — это практически уже commodity (сорри, не знаю русского слова-эквивалента). А вот у нас в прошедшие годы «облачных» докладов на конференциях РИТ/Highload++ и прочих было по пальцем сосчитать. Но сейчас, кажется, чувствуется переломный момент. По разным причинам люди наконец-то созревают. Улучшаются каналы до европейских AWS-регионов, RTT из Москвы, по моим наблюдениям, опустился уже до ~50 мс. Яндекс и Mail.ru вовсю растят собственные решения — очень ждем, когда можно будет просто зарегистрироваться, ввести данные карточки и начать использовать. Вдобавок Роскомнадзор тут старательно учит всех гибкости и мобильности.
Вторая история — постепенное осознание того, что нужна еще большая автоматизация, чем только лишь поднятие Постгреса, настройка репликации и бэкапов. Если вам более 35-40 лет и вы программист, то, возможно, вы застали эру работы без систем контроля версий (сейчас повсеместно Git, а до него — CSV, SVN и прочие). Люди использовали ftp, верстальщик отправлял HTML по почте программисту. Был мрак, такой каменный век, что сейчас даже сложно уже представить. Всё это уже автоматизировано, отдельное спасибо Линусу Торвальдсу, а также командам GitHub, BitTorrent, GitLab. Та же история с тестами — когда-то было только ручное тестирование, теперь же повсюду автотесты и CI. Аналогично с вопросами деплоя: есть devops-инструменты, никакой ручной настройки серверов и сервисов, всё скриптуется, автоматизируется.
Так вот, в области DBA сейчас, наверное, уже не каменный век (спасибо облачным компаниям за хотя бы базовую автоматизацию), но еще и далеко не железный. Труд DBA по-прежнему ручной. Я уже приводил примеры. Ещё очень многого предстоит достичь, будут появляться новые технологии. У нас в PostgreSQL.support уже проходит внутреннее тестирование аналог ораклового Database Replay, позволяющий проводить массу параллельных экспериментов без ручных действий. Конечно же, прежде всего в облаках. Например, если вы хотите подобрать оптимальный параметр — скажем, попробовать разные варианты значений `shared_buffers`, `seq_page_cost` или же `default_statistics_target` — вам достаточно задать вопрос нашему роботу-DBA Nancy, она развернёт сразу несколько копий вашей БД (одну с вариантами параметров «как сейчас на проде», другие — с такими, которые вы хотите проверить), прогонит кусок реальной нагрузки с вашей боевой БД или же запросы, заданные вами вручную, и сведёт результаты в одну таблицу, где будет видно, как в целом каждый вариант себя показал, сколько времени ушло, плюс сравнение по каждому кластеру из самых нагружающих систему запросов. Аналогично можно поступить, если вы оптимизируете набор индексов — можно попросить систему проверить разные индексы.
Тут очень важный момент: зачастую, оптимизируя вручную один запрос, вы забываете проверить смежные запросы, а они запросто могут ухудшиться. Недавний пример: соптимизировали было SELECT-ы за счет замещения части индексов таблицы на их более легковесные частичные аналоги (`create index … where …`), но оказалось, что при этом существенно замедлили UPDATE-ы. Причина в том, что после замены индексов перестали срабатывать HOT Updates (кейс подробно разобран в моей статье). Автоматизация экспериментов с помощью нашего решения позволяет увидеть картину целиком, все trade-offs. Только такая автоматизированная система позволяет гарантировать выполнение базового принципа оптимизаций — найденное решение должно улучшать что-то конкретное, не ухудшая при этом всё остальное.
И наконец, третье направление — история с DBA AI. В прошлом году появилось решение, использующие ML, чтобы тюнить Postgres и MySQL, называется OtterTune. Его сделала команда того же Andy Pavlo. До этого появлялись разные решения у проприетарных СУБД — тут выделяется проект AutoAdmin у Microsoft начала нулевых, наработки которого потом перетекли в сам SQL Server. Сегодня весь такой облачный и автономный (якобы) Oracle, а также Peloton, которых я уже упоминал, – еще одни звоночки.
Это направление чрезвычайно интересное. Тут точно стоит ждать прорывов. Я поясню, почему сейчас. Очень важны два аспекта. Первый — взрывное развитие методов машинного обучения, которое мы наблюдаем последние лет пять-шесть, новые технологии, железо. Второй — развитие облаков, их удешевление. Маленькая РИТ-история. Мой добрый друг и физтех Дима Пушкарев рассказывал на РИТ-2013, как он в десять раз снизил стоимость расшифровки генома за счет интересных собственных алгоритмов использования спотовых инстансов в AWS, это был большой прорыв. А потом в 2015 его компанию купил Amazon и поглотил эти разработки, так что теперь EC2-споты являются рабочей лошадкой в огромном количестве компаний, включая крупнейших из списка Fortune-500, например, Disney. Нам споты очень кстати, проведение экспериментов становится экономически выгодным, без них появление нашего робота-DBA Nancy было бы маловероятным.
Тема создания искусственного интеллекта, обучающегося на экспериментах с разными БД и нагрузками (включая ваши) и помогающего инженерам с настройкой БД, индексами, партиционированием, оптимизацией запросов, не нова в научной среде и в enterprise-секторе (разные решения появляются не одно десятилетие и у Oracle, и у Microsoft, и у IBM), но для нас — тех, кто использует в основном Open Source, — это целый новый мир. Некоторые компоненты уже есть, их мы обсудим на предстоящем фестивале РИТ++, но если говорить в целом, то мы пока находимся в самом начале очень интересного пути.
— Мы затронули темы конференции, но не поговорили о тенденциях индустрии в целом. Как ты считаешь, хайп вокруг NoSQL решений уже закончился? Какие прогнозы ты можешь дать по поводу соперничества MySQL и PostgreSQL? Или это можно считать обоюдовыгодным противостоянием?
Хайп изменился. В тренде теперь NewSQL, а не NoSQL. Причем в этом термине зашиты разные смыслы. Можно выделить как минимум три значения. Первое — те же NoSQL-решения, добавляющие поддержку своих диалектов SQL. В этом плане SQL сейчас — язык-победитель. Уродливый, избыточный, с неподъемными талмудами стандарта (в который, кстати, недавно добавили раздел SQL/JSON, работы по внедрению в Постгрес которого ведутся), но он сейчас явно язык-победитель.
Вторая история — это про традиционные РСУБД, расширенные поддержкой нарушающих первую нормальную форму данных, прежде всего данных JSON, что в итоге приводит нас к гибридной модели данных — получаем реляции, например, с JSON-документами внутри. В Постгресе очень давно были массивы, hstore, XML, а теперь и отличная поддержка JSON, с кучей возможностей и различными вариациями индексов. В этом смысле Постгрес — тоже NewSQL-СУБД.
И наконец, третий вариант трактовки понятия «NoSQL»: новые РСУБД, сразу ориентированные на язык SQL. Это прежде всего облачный Google Spanner, опенсорсные CocroachDB и ClickHouse. Создается много интересного, это большой новый вызов Постгресу. Хайпы предыдущих десятилетий — объектные СУБД, потом XML и далее NoSQL — он пережил очень успешно, окреп и вырос, а вот как пойдут дела далее, время покажет.
В целом с вызовами эпохи NewSQL пока неясно. Тут надо много работать, новые решения уже бьют по слабым местам Постгреса: например, один из крупнейших клиентов Citus-а CloudFlare недавно для своей аналитики отказался от их решения (а значит, и от Postgres) в пользу ClickHouse. Что неудивительно — колоночная БД с векторизированными вычислениями и встроенным шардингом в данный момент на задачах аналитики оказывается на голову лучше Постгреса, даже снабженного шардированием от Citus. Если сообществу удастся в обозримом будущем добавить качественную поддержку pluggable engines, новые «движки хранения» — прежде всего, column store, а также row store нового типа (c «undo», с замещением кортежей «на месте», избавляющий от необходимости проведения частых и дорогих операций VACUUM – см. разработку компании EnterpriseDB zheap) — и развить, а может даже и встроить в ядро Постгреса решения для шардинга (решения «сбоку» уже есть, например, Citus, а вот про встроенный ведутся пока только разговоры), то всё у Постгреса будет хорошо в обозримом будущем. Лично я очень надеюсь, что в ближайшие несколько лет Постгрес-сообщество успешно решит перечисленные задачи.
А с MySQL да, есть какое-то взаимовыгодное… Как бы лучше сказать. Наверное, не противостояние, а уже какая-то даже кооперация. Постгресовые конференции приглашают докладчиков из MySQL и Percona и наоборот, делаются совместные бенчмарки (см. совместный доклад разработчиков ПостгресПро и Percona на Highload++ 2016) и так далее. Один из самых активных участников российского постгрес-сообщества — Алексей Копытов, человек из MySQL-сообщества, автор sysbench, активно «топит» за MySQL и против Постгреса, причем почему-то очень часто объявляется в нашей постгресовой фейсбук-группе. Не знаю, что им движет, но в итоге делает он очень хорошую работу, не дает забыть о недостатках Постгреса, подталкивает к развитию.
— И главный вопрос на сегодня. Когда все таки митап-группа #RuPostgres будет первой?
Была некоторая личная скромная цель — обогнать группу SF Bay Area, где я теперь живу. Цель достигнута. Группа Нью-Йорка очень активна, и ее мы пока вряд ли догоним, но меня это особо уже не тревожит. Переезжать туда пока не планирую.
С учетом того, что и я, и соведущий наших трансляций Илья Космодемьянский в основном находимся не в Москве, группу мы сейчас активно тянем в онлайн. Я думаю, тут есть еще очень большой потенциал для роста. По-первых, русскоговорящие постгресмены раскиданы по всему миру. Во-вторых, средства проведения онлайн-митапов становятся доступнее и совершеннее — например, совсем недавно в YouTube чат стал, наконец, сохраняться после завершения трансляции, а это для наших онлайн-сессий очень важно. Во время трансляций там часто разгорались интересные параллельные обсуждения затронутых тем. И вот YouTube теперь синхронно накладывает все реплики на запись, смотреть становится ещё интереснее.
— Поскольку ты отвечаешь за доклады по БД к новосибирскому HighLoad++ Siberia, не могу не спросить, какие темы будут затронуты в этом году и на какие доклады надо обратить внимание в первую очередь? Какова будет специфика сибирского форума, стоит ли туда приезжать после РИТ++?
Конечно стоит. Highload++ Siberia — полноценный, «взрослый» Highload, его не стоит путать с прошлогодним Highload++ Junior. Большая конференция приезжает в новый регион, чтобы активировать обмен опытом между еще большим количеством экспертов. Программа у нее своя, уникальная, сейчас формируется. Мы стараемся минимизировать пересечения тем, представлять новую информацию.
Уже поданы очень интересные заявки. Например рассказ о внедрении ClickHouse в VK, очень интересные доклады от специалистов из Яндекс, Mail.ru, Одноклассников, Badoo — про базы данных, видеостриминг, алгоритмы сжатия.
Отдельно отмечу, что целый блок заявок получен от enterprise-сектора. Местные компании готовы делиться своим опытом работы с Oracle, прежде всего в финансовом секторе. И так вышло, что в этот раз я поддержал большую часть заявок — потому что в отличии от прошлого опыта (когда к нам приходили люди из российского офиса Oracle и не могли ответить даже на базовые технические вопросы) тут есть новые ожидания, видна хорошая техническая экспертиза.
Ну и конечно, будут доклады о Postgres. Обещали приехать Andreas Scherbaum (Greenplum) и Alvaro Hernandez (OnGres), лидеры немецкого и испанского постгресовых сообществ.
Уверен, будет интересно!
