Главная » Хабрахабр » Мир магии PostgreSQL: интервью с Николаем Самохваловым

Мир магии PostgreSQL: интервью с Николаем Самохваловым

Сегодня мы поговорим с Николаем, «борцом» за продвижение новых технологий в мире БД, членом нашего программного коммитета и активным участником всевозможных конференций. Главные темы — самоуправляемые СУБД, DBA AI, облака, NoSQL, встроенные механизмы контроля БД, доклады на РИТ++ и HighLoad++ Siberia, а также масса дельных советов и примеров, которые могут пригодится в реальной работе как разработчику, так и DBA.

Что заканчивал, с чего начинал и чем занимаешься сейчас?
— Расскажи немного о себе.

В далеком 2005 месте с небольшой командой разработчиков из МФТИ и МГУ создал исторически первую соцсеть МойКруг, а потом ещё несколько социальных сетевых проектов. Физтех, ФУПМ выпуска 2004, кафедра ИСП РАН.

Теперь это превратилось в русскоязычную группу #RuPostgres, представленную на площадках Meetup.com и YouTube. В 2006-2007 годах поучаствовал в создании типа данных XML для Postgres, тогда же начал проводить постгресовые митапы (не было тогда еще такого слова) в Москве. На 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 на вооружении прежде всего большой багаж знаний и многие годы опыта.

Например: нашли самый «тормозной» запрос в pg_stat_statements. И в то же время работа DBA сейчас — это чисто ручные действия! И что же сейчас делает DBA? Но чтобы его оптимизировать, вам нужен конкретный запрос с конкретными параметрами — ведь от этого зависит и план выполнения, и скорость запроса, и EXPLAIN без них вы не прогоните (ситуация немного улучшится в Постгрес 12, если будет принят патч от ПостгресПро). Последний вариант хорошо сработает, только если за плечами годы опыта. Одно из двух: или лезет в логи откапывать конкретные примеры запросов, или же «высасывает из пальца» какие-то значения, оптимизируя в итоге сферического коня в вакууме. Если есть «интуиция».

Если DBA опытный и с доступом к «проду», то он, возможно, прямо «на проде» и отладится, и даже индекс создаст вручную. А дальше, когда подобрано конкретное решение, устраняющее проблему, — скажем, надо добавить какой-то индекс — происходит еще более забавная штука. Если же «ну прям очень надо» проекту провести DDL через git, то индекс получит название типа i_tmp_killme, а разработчикам будет предложено добавить в систему миграции и отрелизить индекс с уже более вменяемым названием. Минуя git, да.

Но в компаниях с хорошей культурой git flow, code review, devops и любознательными разработчиками необходимо заранее, до каких-то реальных действий с «боевыми» БД объяснять, почему именно такой индекс выбран, как конкретно он ускоряет запрос. Если у DBA авторитет зашкаливает, покорные разработчики и вопросов не будут задавать. И тут очень выручают облака. В Долине, кстати, разработчики довольно часто попадаются дотошные, им всё надо разжевать, обосновать. В RDS отлично автоматизировали процессы создания БД, но от массы ручных действий по оптимизации запросов и тюнингу БД RDS никак не избавляет — эксплейны за вас никто (пока!) не прогонит и объяснения разработчикам не представит. Это очень удобно — в пару кликов создать реплику боевой БД в AWS RDS, на ней прогнать `explain (analyze, buffers)` в разных вариантах, найти наилучшее решение и представить его разработчикам с конкретными оценками улучшения производительности и детальной диагностикой.

Вы любите ездить «на ручке»? В итоге работа Postgres DBA сейчас выглядит как управление прекрасным скоростным болидом с ручной коробкой передач. Я — да, но только не каждый день.

Данные знания могут служить основой создания новых полезных «надстроек»? — Фактически ты кратко описал начало алгоритма действий для поиска проблемных запросов.

Именно поэтому область моих интересов сейчас — это DBA AI. Верно. Такого в природе пока нет, но работы в этом направлении уже ведутся (одна из интересных, хотя и пока сугубо исследовательских разработок — уже упомянутая Peloton). Искусственный интеллект, помогающий «готовить» Postgres быстро и эффективно, без чисто ручных действий, в больших и растущих масштабах (как правило, в облаках).

О распространённых ошибках использования РСУБД, ты говорил, что СУБД — это сердце IT системы, неиспользование возможностей БД — это глупость. — На РИТ++ 2017, выступая с докладом Database First! Прежде всего интересуют факты, когда именно использование стандартных механизмов контроля БД помогло избежать ошибок или наоборот, когда не использование стандартных фич привело к плачевным результатам? Какие примеры ты можешь привести в поддержку своих слов? Например, отсутствие FK и, возможно, другие, на первый взгляд, обычные механизмы.

По мере того как такой проект накапливает данные, собираются и «грязные данные» — такие как «строки-сироты» (не стали использовать внешние ключи, удалили пользователей, а приписанные им данные удалить забыли), дубликаты (не реализована или некорректно реализована проверка на уникальность на стороне приложения), недопустимые или ошибочные значения. В том же докладе я утверждал, что «плачевные результаты» наблюдаются в большинстве проектов, в которых поддержка целостности и «чистоты» данных вынесена из СУБД и реализована на стороне приложения — на PHP, Ruby, Python или на чём-то ещё. Если это небольшой блог, то, может быть, большой беды и нет. Другой вопрос — как вы относитесь к таким проблемам. Не говоря уже о том, что ваша реализация проверок может быть далека от идеала. Но если это система биллинга… Как только вы «уносите» проверку данных за пределы СУБД, вы допускаете возможность, что появится кто-то (человек или программа), кто эту проверку обойдет.

Их всего несколько: поддержка уникальных значений (на практике реализуется с помощью уникального индекса), внешние ключи, пользовательские ограничения (то, что достигается использованием ключевого слова CHECK), запрет значений NULL, а в Постгресе еще специальные exclusion constraints, с помощью которых удобно обеспечивать, например, непересекаемость интервалов. Так что полезно знать и применять доступные в СУБД возможности поддержки ограничений целостности данных.

Простой пример. Использование подходящих типов данных тоже является важным инструментом обеспечения чистоты данных. Для email-ов нам, конечно, нужны регистронезависимые проверки, поэтому тут лучше подойдет тип данных citext (его нет «в коробке», зато есть расширение citext, доступное в большинстве инсталляций Постгреса) или же навешивание функционального индекса типа `create index … using btree(lower(email))`. Очевидная и очень частая ошибка: использование типа данных text (varchar) для хранения электронных адресов в столбце и навешивание обычного уникального индекса на столбец. Кстати, в последнем случае не забудьте перестроить статистику (`vacuum analyze …`), чтобы postgres осознал, какое распределение в таблице имеют значения выражения `lower(email)`.

Это задача для триггеров. Кроме грамотного использования типов данных и поддержки разных видов ограничений целостности СУБД позволяет реализовывать сложную логику проверки данных — например для случаев, когда надо при модификации данных в одной таблице сделать некоторые проверки с использованием сразу нескольких таблиц. Такая вот простая формула. С позиции своего опыта, который включает очень разные проекты и разных людей, я берусь утверждать: нелюбовь к триггерам прямо пропорциональна БД-невежеству разработчика.

На обычных арифметических вычислениях PL/pgSQL (как, впрочем, и простой SQL) заметно уступают С и даже PHP. Никто в здравом уме не будет заявлять, что PL/pgSQL или, скажем, PL/Python супербыстры. А вот для работы с очень большим количеством данных, когда надо найти правильные иголки в стогах сена, нет ничего лучше позиции «рядом с данными», когда на вашей стороне играют все доступные в БД индексы и отсутствие сетевой сложности, и помощи одного из двух самых популярных языков программирования в мире — SQL. Так медленны, что их для таких целей в значительных масштабах будет использовать только безумец (ну или тот, кто возьмет на вооружение, скажем, библиотеку MADlib, которую я, кстати, очень уважаю и иногда с удовольствием использую). Грамотно написанный триггер и быстро отрабатывает, и довольно прост в отладке (для профайлинга и отладки помогают расширения pg_stat_statements и auto_explain с включенными опциями `pg_stat_statements.track = all` и `auto_explain.log_triggers = on`) и, главное, является рубежом, который не преодолеют грязные данные. Не использовать эти возможности, когда это точно выгодно, и есть глупость!

— В продолжение предыдущего вопроса, скажи, почему именно встроенные возможности PostgreSQL по контролю и манипуляциям с данными — оптимальнее и выигрышнее, чем самописные конструкции?

Одна очевидная причина: встроенные возможности разработаны и многие годы развиваются умными людьми, создателями Постгреса — такими как Том Лейн.

Вот сколько у вас входов в дом? Другую — архитектурную — причину мы уже обсудили, осталось разве что проиллюстрировать. Два? Один? Точно же не десять? Когда уходите, сколько дверей закрываете/контролируете? Если вы реализуете поддержку целостности средствами приложения, то в вашем доме оказывается множество дверей, через которые входят и выходят посетители (в случае БД — данные). В современном проекте может быть одновременно и веб-сайт, и back-office, и различные API для мобильных приложений, а может еще и для внешних пользователей. Ваши двери сделаны и поддерживаются разными людьми/командами, которые зачастую еще и говорят на разных языках… Понятно же, о чем речь, да? А если вам еще больше «повезло» и проект развивается силами не пары-тройки программистов, а большой команды или даже группой команд, то все, привет, приехали. Или вам придется ограничивать и сдерживать развитие проекта («нельзя подключать этот уже готовый GUI для работы с данными — ведь тогда менеджер сможет в БД записать что угодно, лучше уж мы сами создадим админку!..») или же как-то синхронизировать разработку одних и тех же механизмов контроля данных в разных подсистемах, зачастую и на разных языках.

На самом деле я тут рассказываю тривиальные вещи, но мои личные наблюдения показывают, как много стереотипов типа однозначных «хранимки — зло» или «FK — большие тормоза» еще живы и приводят к массовому велосипедостроению, и как дорого за это приходится впоследствии платить проектам.

Наверное, тебя часто спрашивают о корректных вариантах перехода с версий 9. — Очень много обсуждений и вопросов идет вокруг релизов PostgreSQL. 6 на 10.
Всегда ли использование инструмента pg_upgrade оправданно? 3 — 9. Встречал ли ты на практике ситуации, когда нужно опасаться данного инструмента?

3, были бессонные ночи у многих (включая меня) «благодаря» этому багу. Был очень болезненный баг в версии 9. Конечно, от багов нет стопроцентной страховки, но сегодня 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 (свежий пост на эту тему).

В описании выступления первая часть посвящена инструменту «postgres_dba». — На майский РИТ++  ты заявлен с докладом "Continuous Database Administration". Расскажи, пожалуйста о нем.

У любого опытного DBA есть накопленная годами подборка полезных скриптов, отвечающих на разные вопросы — от «какие таблицы в этой БД занимают больше всего места» до оценки bloat-а, нахождения неиспользуемых или избыточных индексов, работы с pg_stat_statements. postgres_dba – это такой «полуавтоматический» «швейцарский нож» для работы с Постгресом. Очень просто добавить в этот набор и любые свои отчёты или интерактивные скрипты (например, можно добавить что-то для добавления/удаления пользователей БД с генерацией паролей так, чтобы это было максимально безопасно). Я перелопатил не одну подборку таких скриптов и сделал интерактивную менюшку для них — и теперь родной постгресовой консольке, psql, вы можете «общаться» с Постгресом, получая ответы на свои вопросы очень быстро.

Но уже заметно ускоряет. Работу DBA этот инструмент, конечно, не делает полностью автоматизированной. Проект открытый, приглашаю попробовать и поучаствовать в развитии: https://github.com/NikolayS/postgres_dba. Для себя я отметил, что получившийся инструмент сближает DBA и БД, с которыми она/он работает: отчёты теперь доступны на расстоянии нажатий всего пары клавиш, время сильно экономится, полноценное «общупывание» БД происходит очень быстро, а значит и чаще.

Как ты думаешь, какое из этих направлений будет активно использоваться в ближайшем будущем? — Вторая часть доклада состоит из нескольких блоков, посвященных автоматизации, облачным решениям и вопросам, связанным с AI.

Во-первых, Amazon, Google и Microsoft уже предоставляют так называемые managed databases — это когда за вас решаются вопросы развертывания БД, настройки репликации, switch-over/fail-over, автоматических бэкапов и базового мониторинга. Тут сразу несколько направлений. AWS RDS даже не дает скачать бэкапы, не говоря уж о возможности репликации куда-то еще, кроме как на другой RDS-инстанс. Но такие решения, хоть и строятся на Open Source продуктах, сейчас сделаны отнюдь не в духе FLOSS. Не дает даже логировать запросы, только ошибки. А Google Cloud SQL for Postgres, хоть и объявил в апреле о GA, все еще чрезвычайно беден в плане конфигурации Постгреса.

В то же время я верю, что в ближайшем будущем появятся открытые аналоги, готовые работать где угодно (в амазоновоском или гугловском облаке, в частном облаке или же on-premise), при этом не менее продвинутые, с различными вариантами построения HA-решений, политиками бэкапов, при этом с полным доступом к ОС, ФС с superuser-доступом. Но в целом это все успешные истории построения проприетарных решений на базе открытых, особенно если говорить об RDS и RDS Aurora. Кстати, строительные блоки для этого уже созданы и обкатаны в многочисленных компаниях: тут и Patroni со Stolon для поднятия мастера и реплик с поддержкой автофейловера, и не так давно начавшиеся развиваться k8s-операторы от Zalando и от Crunchy, и решения для бэкапов WAL-E, WAL-G, pgBackRest. По моим наблюдениям, эта ниша точно есть и она пока не занята.

Тут вышла странная история. Кстати, инженерам из России — вообще всем, не только DBA — я настоятельно рекомендую поскорее двигать свое сознание в сторону облаков, если они еще не сделали этого. А вот в случае облаков этот лаг явно больше. Общеизвестно, что в большинстве случаев задержка с адаптацией новых технологий по сравнению с Долиной в России составляет два-три года. А вот у нас в прошедшие годы «облачных» докладов на конференциях РИТ/Highload++ и прочих было по пальцем сосчитать. В США облака сегодня — это практически уже commodity (сорри, не знаю русского слова-эквивалента). По разным причинам люди наконец-то созревают. Но сейчас, кажется, чувствуется переломный момент. Яндекс и Mail.ru вовсю растят собственные решения — очень ждем, когда можно будет просто зарегистрироваться, ввести данные карточки и начать использовать. Улучшаются каналы до европейских AWS-регионов, RTT из Москвы, по моим наблюдениям, опустился уже до ~50 мс. Вдобавок Роскомнадзор тут старательно учит всех гибкости и мобильности.

Если вам более 35-40 лет и вы программист, то, возможно, вы застали эру работы без систем контроля версий (сейчас повсеместно Git, а до него — CSV, SVN и прочие). Вторая история — постепенное осознание того, что нужна еще большая автоматизация, чем только лишь поднятие Постгреса, настройка репликации и бэкапов. Был мрак, такой каменный век, что сейчас даже сложно уже представить. Люди использовали ftp, верстальщик отправлял HTML по почте программисту. Та же история с тестами — когда-то было только ручное тестирование, теперь же повсюду автотесты и CI. Всё это уже автоматизировано, отдельное спасибо Линусу Торвальдсу, а также командам GitHub, BitTorrent, GitLab. Аналогично с вопросами деплоя: есть devops-инструменты, никакой ручной настройки серверов и сервисов, всё скриптуется, автоматизируется.

Труд DBA по-прежнему ручной. Так вот, в области DBA сейчас, наверное, уже не каменный век (спасибо облачным компаниям за хотя бы базовую автоматизацию), но еще и далеко не железный. Ещё очень многого предстоит достичь, будут появляться новые технологии. Я уже приводил примеры. Конечно же, прежде всего в облаках. У нас в PostgreSQL.support уже проходит внутреннее тестирование аналог ораклового Database Replay, позволяющий проводить массу параллельных экспериментов без ручных действий. Аналогично можно поступить, если вы оптимизируете набор индексов — можно попросить систему проверить разные индексы. Например, если вы хотите подобрать оптимальный параметр — скажем, попробовать разные варианты значений `shared_buffers`, `seq_page_cost` или же `default_statistics_target` — вам достаточно задать вопрос нашему роботу-DBA Nancy, она развернёт сразу несколько копий вашей БД (одну с вариантами параметров «как сейчас на проде», другие — с такими, которые вы хотите проверить), прогонит кусок реальной нагрузки с вашей боевой БД или же запросы, заданные вами вручную, и сведёт результаты в одну таблицу, где будет видно, как в целом каждый вариант себя показал, сколько времени ушло, плюс сравнение по каждому кластеру из самых нагружающих систему запросов.

Недавний пример: соптимизировали было SELECT-ы за счет замещения части индексов таблицы на их более легковесные частичные аналоги (`create index … where …`), но оказалось, что при этом существенно замедлили UPDATE-ы. Тут очень важный момент: зачастую, оптимизируя вручную один запрос, вы забываете проверить смежные запросы, а они запросто могут ухудшиться. Автоматизация экспериментов с помощью нашего решения позволяет увидеть картину целиком, все trade-offs. Причина в том, что после замены индексов перестали срабатывать HOT Updates (кейс подробно разобран в моей статье). Только такая автоматизированная система позволяет гарантировать выполнение базового принципа оптимизаций — найденное решение должно улучшать что-то конкретное, не ухудшая при этом всё остальное.

В прошлом году появилось решение, использующие ML, чтобы тюнить Postgres и MySQL, называется OtterTune. И наконец, третье направление — история с DBA AI. До этого появлялись разные решения у проприетарных СУБД — тут выделяется проект AutoAdmin у Microsoft начала нулевых, наработки которого потом перетекли в сам SQL Server. Его сделала команда того же Andy Pavlo. Сегодня весь такой облачный и автономный (якобы) Oracle, а также Peloton, которых я уже упоминал, – еще одни звоночки.

Тут точно стоит ждать прорывов. Это направление чрезвычайно интересное. Очень важны два аспекта. Я поясню, почему сейчас. Второй — развитие облаков, их удешевление. Первый — взрывное развитие методов машинного обучения, которое мы наблюдаем последние лет пять-шесть, новые технологии, железо. Мой добрый друг и физтех Дима Пушкарев рассказывал на РИТ-2013, как он в десять раз снизил стоимость расшифровки генома за счет интересных собственных алгоритмов использования спотовых инстансов в AWS, это был большой прорыв. Маленькая РИТ-история. Нам споты очень кстати, проведение экспериментов становится экономически выгодным, без них появление нашего робота-DBA Nancy было бы маловероятным. А потом в 2015 его компанию купил Amazon и поглотил эти разработки, так что теперь EC2-споты являются рабочей лошадкой в огромном количестве компаний, включая крупнейших из списка Fortune-500, например, Disney.

Некоторые компоненты уже есть, их мы обсудим на предстоящем фестивале РИТ++, но если говорить в целом, то мы пока находимся в самом начале очень интересного пути. Тема создания искусственного интеллекта, обучающегося на экспериментах с разными БД и нагрузками (включая ваши) и помогающего инженерам с настройкой БД, индексами, партиционированием, оптимизацией запросов, не нова в научной среде и в enterprise-секторе (разные решения появляются не одно десятилетие и у Oracle, и у Microsoft, и у IBM), но для нас — тех, кто использует в основном Open Source, — это целый новый мир.

— Мы затронули темы конференции, но не поговорили о тенденциях индустрии в целом. Как ты считаешь, хайп вокруг NoSQL решений уже закончился? Какие прогнозы ты можешь дать по поводу соперничества MySQL и PostgreSQL? Или это можно считать обоюдовыгодным противостоянием?

В тренде теперь NewSQL, а не NoSQL. Хайп изменился. Можно выделить как минимум три значения. Причем в этом термине зашиты разные смыслы. В этом плане SQL сейчас — язык-победитель. Первое — те же NoSQL-решения, добавляющие поддержку своих диалектов SQL. Уродливый, избыточный, с неподъемными талмудами стандарта (в который, кстати, недавно добавили раздел SQL/JSON, работы по внедрению в Постгрес которого ведутся), но он сейчас явно язык-победитель.

В Постгресе очень давно были массивы, hstore, XML, а теперь и отличная поддержка JSON, с кучей возможностей и различными вариациями индексов. Вторая история — это про традиционные РСУБД, расширенные поддержкой нарушающих первую нормальную форму данных, прежде всего данных JSON, что в итоге приводит нас к гибридной модели данных — получаем реляции, например, с JSON-документами внутри. В этом смысле Постгрес — тоже NewSQL-СУБД.

Это прежде всего облачный Google Spanner, опенсорсные CocroachDB и ClickHouse. И наконец, третий вариант трактовки понятия «NoSQL»: новые РСУБД, сразу ориентированные на язык SQL. Хайпы предыдущих десятилетий — объектные СУБД, потом XML и далее NoSQL — он пережил очень успешно, окреп и вырос, а вот как пойдут дела далее, время покажет. Создается много интересного, это большой новый вызов Постгресу.

Тут надо много работать, новые решения уже бьют по слабым местам Постгреса: например, один из крупнейших клиентов Citus-а CloudFlare недавно для своей аналитики отказался от их решения (а значит, и от Postgres) в пользу ClickHouse. В целом с вызовами эпохи NewSQL пока неясно. Если сообществу удастся в обозримом будущем добавить качественную поддержку pluggable engines, новые «движки хранения» — прежде всего, column store, а также row store нового типа (c «undo», с замещением кортежей «на месте», избавляющий от необходимости проведения частых и дорогих операций VACUUM – см. Что неудивительно — колоночная БД с векторизированными вычислениями и встроенным шардингом в данный момент на задачах аналитики оказывается на голову лучше Постгреса, даже снабженного шардированием от Citus. Лично я очень надеюсь, что в ближайшие несколько лет Постгрес-сообщество успешно решит перечисленные задачи. разработку компании EnterpriseDB zheap) — и развить, а может даже и встроить в ядро Постгреса решения для шардинга (решения «сбоку» уже есть, например, Citus, а вот про встроенный ведутся пока только разговоры), то всё у Постгреса будет хорошо в обозримом будущем.

Наверное, не противостояние, а уже какая-то даже кооперация. А с MySQL да, есть какое-то взаимовыгодное… Как бы лучше сказать. совместный доклад разработчиков ПостгресПро и Percona на Highload++ 2016) и так далее. Постгресовые конференции приглашают докладчиков из MySQL и Percona и наоборот, делаются совместные бенчмарки (см. Не знаю, что им движет, но в итоге делает он очень хорошую работу, не дает забыть о недостатках Постгреса, подталкивает к развитию. Один из самых активных участников российского постгрес-сообщества — Алексей Копытов, человек из MySQL-сообщества, автор sysbench, активно «топит» за MySQL и против Постгреса, причем почему-то очень часто объявляется в нашей постгресовой фейсбук-группе.

Когда все таки митап-группа #RuPostgres будет первой? — И главный вопрос на сегодня.

Цель достигнута. Была некоторая личная скромная цель — обогнать группу SF Bay Area, где я теперь живу. Переезжать туда пока не планирую. Группа Нью-Йорка очень активна, и ее мы пока вряд ли догоним, но меня это особо уже не тревожит.

Я думаю, тут есть еще очень большой потенциал для роста. С учетом того, что и я, и соведущий наших трансляций Илья Космодемьянский в основном находимся не в Москве, группу мы сейчас активно тянем в онлайн. Во-вторых, средства проведения онлайн-митапов становятся доступнее и совершеннее — например, совсем недавно в YouTube чат стал, наконец, сохраняться после завершения трансляции, а это для наших онлайн-сессий очень важно. По-первых, русскоговорящие постгресмены раскиданы по всему миру. И вот YouTube теперь синхронно накладывает все реплики на запись, смотреть становится ещё интереснее. Во время трансляций там часто разгорались интересные параллельные обсуждения затронутых тем.

Какова будет специфика сибирского форума, стоит ли туда приезжать после РИТ++? — Поскольку ты отвечаешь за доклады по БД к новосибирскому HighLoad++ Siberia, не могу не спросить, какие темы будут затронуты в этом году и на какие доклады надо обратить внимание в первую очередь?

Highload++ Siberia — полноценный, «взрослый» Highload, его не стоит путать с прошлогодним Highload++ Junior. Конечно стоит. Программа у нее своя, уникальная, сейчас формируется. Большая конференция приезжает в новый регион, чтобы активировать обмен опытом между еще большим количеством экспертов. Мы стараемся минимизировать пересечения тем, представлять новую информацию.

Например рассказ о внедрении ClickHouse в VK, очень интересные доклады от специалистов из Яндекс, Mail.ru, Одноклассников, Badoo — про базы данных, видеостриминг, алгоритмы сжатия. Уже поданы очень интересные заявки.

Местные компании готовы делиться своим опытом работы с Oracle, прежде всего в финансовом секторе. Отдельно отмечу, что целый блок заявок получен от enterprise-сектора. И так вышло, что в этот раз я поддержал большую часть заявок — потому что в отличии от прошлого опыта (когда к нам приходили люди из российского офиса Oracle и не могли ответить даже на базовые технические вопросы) тут есть новые ожидания, видна хорошая техническая экспертиза.

Обещали приехать Andreas Scherbaum (Greenplum) и Alvaro Hernandez (OnGres), лидеры немецкого и испанского постгресовых сообществ. Ну и конечно, будут доклады о Postgres.

Уверен, будет интересно!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Образ современного тестировщика. Что нужно знать и уметь

Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования. Бытует мнение, что простейший путь к IT лежит через тестирование. Сейчас же ...

[Из песочницы] Нейронная сеть с использованием TensorFlow: классификация изображений

Привет, Хабр! Представляю вашему вниманию перевод статьи «Train your first neural network: basic classification». Для создания нейронной сети используем python и библиотеку TensorFlow. Это руководство по обучению модели нейронной сети для классификации изображений одежды, таких как кроссовки и рубашки. Установка ...