Работа с базой данных — это то, что заметно отражается на производительности любого веб-сервиса. Если постараться, то можно устроить хайлоад вообще без всякой нагрузки.
А если все сделать по уму, то получится обрабатывать запросы многих тысяч пользователей. Поэтому в расписании HighLoad++ традиционно много докладов по базам данных. У нас есть треки по PostgreSQL, MySQL и ClickHouse, есть несколько докладов по MongoDB (в лучших традициях спикер —инженер по производительности в MongoDB). Кроме того, есть выступления, посвященные сравнению разных подходов или рассматривающие специализированные решения. И для общности прибавим сюда Tarantool и in-memory. Итого 33 доклада прямо относятся к секции «Базы данных и системы хранения» и как минимум 10 — косвенно. И это не считая митапов, которых уже не меньше десяти, а еще будут добавляться новые по ходу дела.
Попробуем помочь сориентироваться во всем многообразии и не пропустить действительно уникальные доклады. Для надежности спросим мнения у члена Программного комитета, отвечающего за эту секцию, Николая Самохвалова. И не смотрите, что Николай основатель Postgres.ai и вообще postgresmen — он отлично ориентируется в мире БД, знает любопытные закулисные истории и тренды.
Обзор организован максимально просто: мы открыли список докладов и пошли сверху вниз, останавливаясь на тех темах, на которые обязательно надо обратить внимание.
Профайлер запросов в аналитических базах данных — очень интересная штука. Подход должен сильно отличаться от OLTP-баз, потому что, как правило, в аналитических базах данных запросы выполняются долго. Если в PostgreSQL план выполнения запроса статический, то тут имеет смысл проводить чуть ли не мониторинг одного запроса.
В этом докладе Никита Лапков расскажет об устройстве такого профайлера для запросов ClickHouse, который позволяет определить, какой участок кода тормозит для конкретного запроса. И принять соответствующие меры, чтобы выполнялось знаменитое «ClickHouse не тормозит».
Этот доклад как раз из серии «рядом с БД», рассматривает системную задачу, но большая его часть посвящена вопросу бэкапов в MySQL. Рассказ Антона Турецкого точно будет интересен, потому что это опыт Badoo, то есть речь об огромном количестве серверов. В таких масштабах все бэкапировать и, главное, проверять — задача нетривиальная. К тому же им удалось подружить современные тренды и парадигмы проектирования систем с резервным копированием так, чтобы не терять уверенности, что нужные данные можно достать в любом, даже самом критическом, случае.
ClickHouse уверенно завоевывает свои позиции, но мало кто из сторонних разработчиков успел накопить солидный опыт работы с ним. Александр Зайцев и Altinity пионеры использования ClickHouse, еще 3 года назад на HighLoad++ они рассказывали о переезде мульти-петабайтоврй аналитической системы на ClickHouse.
Что изменилось с тех пор? Александр поделится накопленным опытом и know-how, которые нельзя найти в документации.
О MongoDB на HighLoad++ будут рассказывать два гостя. У доклада Álvaro Hernández интересная, даже скандальная предыстория. Когда Альваро сделал и представил бенчмарки, сравнивающие MongoDB и PostgreSQL, завязалась перепалка в интернете. Позже MongoDB представили свои бенчмарки.
В итоге просто у каждого из миров своя философия. Адептам PostgreSQL трудно принять такое нечеткое отношение к данным, но решения MongoDB востребованы на рынке. Сравнивать их напрямую — дело почти невозможное, и это делает доклад Альваро очень увлекательным. Легко слепо придерживаться одной точки зрения, но намного лучше знать и понимать обе.
Второй доклад о MongoDB сделает Henrik Ingo — архитектор решений MongoDB, специализируется на повышении производительности MongoDB и обеспечении высокой доступности. Но Хенрик до MongoDB много лет работал в мире MySQL, поэтому точно знаком с аргументами разных лагерей.
На HighLoad++ Хенрик расскажет, как сделать, чтобы транзакции в распределенной NoSQL базе данных удовлетворяли ACID, и зачем вообще это может понадобиться.
Три недели назад главное ограничение PgBouncer, в которое часто упираются компании, было снято, но оно уже успело всем надоесть. Например, потому что невозможно было комитить доработки в open source — патчи Яндекса и Авито не принимали годами.
Яндекс не стали дожидаться этих изменений и сделали свой пулер соединений — Odyssey. Он мультитредовый, у него есть дополнительные фишки, а подробнее расскажет Андрей Бородин в своем докладе. Кроме того, можно будет обсудить roadmap — какие функции пулера хотелось бы видеть в новых версиях сообществу.
Этим докладом Postgres.ai предлагает в корне изменить подход к разработке бэкенда. Вместо того, чтобы проверять код и запросы на маленьких базах, проверять на больших базах и сразу видеть результат. Звучит логично — если запрос медленный, это обнаружится сразу. Другое дело, что делать для этого, например, полноценные копии боевой БД очень неудобно. Вот тут на помощь и приходит искусственный DBA-боту Joe
Joe можно написать запрос или попросить создать индекс, и он выполнит все действия на полноразмерной копии боевой БД. В любой момент можно начать заново, отменив все изменения за несколько секунд, сбросив кэши ОС и СУБД. А для работы десяти разработчикам не понадобится x10 дискового пространства. Как работает эта магия, и из каких open source компонентов ее можно попробовать собрать у себя, расскажет Анатолий Станслер.
А если кому-то кажется, что нет ничего плохого в том, чтобы удалить несколько миллионов строк одним DELETE, когда известно условие и есть подходящий индекс, то нужно послушать доклад Николая Самохвалова. При попытке выполнить операцию в таких условиях, сервис скорее всего ляжет, и у этого есть сразу куча причин: и DBA недоработали, и разработчики неправильно себя вели, и организационный подход неправильный.
Николай покажет, как эти проблемы помогает решать Postgres.ai и как без его использования настроить защиту и всегда действовать надежно, не роняя прод. Все это на реальном опыте боли и огромных финансовых потерь. Потому что как будто бы понятно, что можно не сразу удалять, а, например, сначала помечать данные на удаление, но блокирующие операции над миллионом строк все встречаются.
GitLab во всю используют PostgreSQL, недавно отказались от MySQL, а для обеспечения HA перешли с REPMGR на Patroni. Patroni разработан Zalando, его задача автоматически переключаться, если что-то случилось с мастером, и обеспечивать доступность сервиса.
Сейчас Patroni де-факто стандарт, и GitLab внедрили его на свое облачное решение — на секундочку, 25 000 000 git pull операций в день — и готовят решение для проверки инсталляций. Jose Cores Finotto поделится этим суперинтересным опытом на HighLoad++ 7 ноября.
Álvaro Hernández корме сравнения PostgreSQL и MongoDB представит еще и продукт StackGres — по сути замену RDS. Но дает возможность намного дешевле развернуть RDS у себя в Kubernetes, получить прицепом настроенные с минимальными усилиями бэкапы, Patroni для auto failover, health check и еще кучу разных инструментов.
Это перспективное начинание в направлении, похожем на историю с Linux. Есть ядро Linux, и много разных сборок вокруг него. То же самое мы видим и в отношении PostgreSQL, который можно считать ядром для СУБД, а вокруг него будут появляться сборки. У StackGres хорошие шансы завоевать популярность, потому что и команда задорная есть, и клиенты, на которых можно обкатывать свои решения.
Блокировки — в принципе тема, которую стоит послушать всем, кто работает с PostgreSQL. А тем более рассказывать про них будет Егор Рогов, который зарекомендовал себя, как офигительный лектор. Он глубоко знает материал и поможет разобраться в типах блокировок и понять, как читать pg_locks и pg_stat_activity и избежать ряда ошибок при проектировании систем. Доклад Егора на HighLoad++ — отличная возможность не просто послушать, а поговорить с экспертом, задать ему свои вопросы, возможно, обсудить совсем разные проблемы.
Андрей Бородин и Георгий Рылов работают в Яндексе и занимаются развитием WAL-G — инструмента резервного копирования с открытым исходным кодом.
Изначально WAL-G — это инструмент для PostgreSQL, разработанный Citus (любопытно, что Microsoft недавно поглотил Citus, то есть по сути купил кусок PostgreSQL). Но оказалось, что идеи организации работы с WAL-G хорошо подходят и другим базам данных. Андрей и Георгий как раз и расскажут о функциональности для MySQL, Redis, MongoDB и открывающихся в связи с этим перспективах.
Sugu Sougoumarane — основатель PlanetScale. Возможно, вы пока не слышали об этой компании, но недавно она получила финансирование в 25 миллионов долларов на развитие своего открытого продукта Vitess. Возможно, вы и о Vitess ничего не слышали. Так вот Vitess — это система шардирования MySQL, и вы точно знаете не одну крупную компанию, использующую Vitess для высоконагруженных баз данных.
Всё началось с YouTube. Именно там Сугу и его команда создали то, что потом стало системой с открытым исходным кодом Vitess. Кстати, они выбрали Go — в то время ещё очень молодой язык. Сугу может рассказать много интересных баек про первые годы Go и про его развитие в целом — в Google его команда стала первым крупным пользователем языка.
Ну а сейчас кроме YouTube Vitess используют такие компании как GitHub, Pinterest, Slack, Square. После ухода из Google Сугу основал PlanetScale и продолжает развивать Vitess, сохраняя код открытым. Приходите послушать про шардинг планетарного масштаба и про использование Go в настоящем Highload. И не забудьте спросить про планы Postgres-версии Vitess — Сугу очень любит этот вопрос.
Забавно, что основного мантейнера Patroni мы будем слушать на другую тему, потому что о Patroni он нам уже рассказывал. Зато Алексей Лесовский может рассказать, как Patroni эксплуатируют за пределами Zalando и какие шишки набивают. Потому что эти шишки могут сильно отличаться, и Алексей обещает поделиться деталями реальных crash-кейсов. Из доклада узнаем, какие бывают проблемы, какие уроки извлекли в Data Egret и как правильно конфигурировать Patroni (и, возможно, PostgreSQL). И, конечно, получим представление о том, как оперативно выявлять возникающие проблемы и оперативно их устранять.
В последнее время, граница между реляционными и документоориентированными СУБД размывается. В стандарте SQL есть функции для работы с JSON, а PostgreSQL — пионер эффективной поддержки JSON среди реляционных СУБД. Во многом благодаря Postgres Professional стандарт уже частично реализован.
Доклад Александра Короткова — это рассказ из первых рук о реализации SQL/JSON и его «сердце» jsonpath в PostgreSQL. То есть возможность узнать о внутренних особенностях, опыте эксплуатации и планах на будущее.
Александр Кукушкин — соавтор Patroni, но в этом году будет рассказывать об еще одной интересной разработке Zalando. Два года назад они начали разрабатывать Postgres-Operator, и на данный момент с его помощью оператора DBA обслуживают больше 1000 кластеров Postgres, работающих на Kubernetes.
Пока одни еще сомневаются, можно ли базы данных в Kubernetes, крупные компании уже работают со всем этим. Познакомиться и где-то перенять такой опыт будет еще круто.
Крупные компании все больше используют PostgreSQL, очень часто ожидая от него того, к чему привыкли в энтерпрайзе. Типичный пример — нужно решения для логической репликации — обратимся к вендору. И некоторые вендоры даже сделали такую поддержку — был Oracle, теперь PostgreSQL появился. Но начинаем разбираться, и оказывается, многое работает по-другому.
Иван Панченко как раз расскажет, какие трудности миграции на PostgreSQL для энтерпрайза субъективны и относятся к типу «кривые руки», а когда это важные вызовы, с которыми PostgreSQL должен справиться в ходе своего развития. Тезисы обещают обсуждение таких тем: факторы масштабирования (объемы таблиц, количество объектов, память, коннекты, репликация), особенности хранилища (Heap, Pluggable storages), временные таблицы, вакуум, взаимодействие с ОС.
И на этой ноте — будущее за opensource — закончим подробное изучение докладов. К сожалению, за кадром почти полностью остался MySQL. Если это ваша тема, обратите внимание на выступления Vittorio Cioe и Alkin Tezuysal.
ClickHouse тоже представлен в большем числе докладов, и как всегда особую ценность представляет митап, на котором можно будет задать любые вопросы по ClickHouse, вместе с разработчиками найти решение проблем, обсудить возможности и планы.
Так же мы не касались Tarantool, так как это база данных и сервер приложений в одном флаконе. И доклады в программе HighLoad++ 2019 акцентируют внимание на этой многофункциональности. Василий Тюбек расскажет о Tarantool Kubernetes Operator для запуска базы данных в Kubernetes, Ярослав Дынников покажет удобство построения распределенных систем с использованием Tarantool. И не упустите возможность уточнить все детали у самих разработчиков — это гораздо продуктивнее и интереснее, чем читать документацию.
Мы вообще считаем вопросы спикерам, кулуарные дискуссии и нетворкинг — очень, если не самой, важной частью конференции. Поэтому создаем все условия для неформального общения и стараемся, чтобы вы хорошо провели время.
А если все сделать по уму, то получится обрабатывать запросы многих тысяч пользователей. Поэтому в расписании HighLoad++ традиционно много докладов по базам данных. У нас есть треки по PostgreSQL, MySQL и ClickHouse, есть несколько докладов по MongoDB (в лучших традициях спикер —инженер по производительности в MongoDB). Кроме того, есть выступления, посвященные сравнению разных подходов или рассматривающие специализированные решения. И для общности прибавим сюда Tarantool и in-memory. Итого 33 доклада прямо относятся к секции «Базы данных и системы хранения» и как минимум 10 — косвенно. И это не считая митапов, которых уже не меньше десяти, а еще будут добавляться новые по ходу дела.
Попробуем помочь сориентироваться во всем многообразии и не пропустить действительно уникальные доклады. Для надежности спросим мнения у члена Программного комитета, отвечающего за эту секцию, Николая Самохвалова. И не смотрите, что Николай основатель Postgres.ai и вообще postgresmen — он отлично ориентируется в мире БД, знает любопытные закулисные истории и тренды.
Обзор организован максимально просто: мы открыли список докладов и пошли сверху вниз, останавливаясь на тех темах, на которые обязательно надо обратить внимание.
Профайлер запросов в ClickHouse
Профайлер запросов в аналитических базах данных — очень интересная штука. Подход должен сильно отличаться от OLTP-баз, потому что, как правило, в аналитических базах данных запросы выполняются долго. Если в PostgreSQL план выполнения запроса статический, то тут имеет смысл проводить чуть ли не мониторинг одного запроса.
В этом докладе Никита Лапков расскажет об устройстве такого профайлера для запросов ClickHouse, который позволяет определить, какой участок кода тормозит для конкретного запроса. И принять соответствующие меры, чтобы выполнялось знаменитое «ClickHouse не тормозит».
Бэкап в современной инфраструктуре
Этот доклад как раз из серии «рядом с БД», рассматривает системную задачу, но большая его часть посвящена вопросу бэкапов в MySQL. Рассказ Антона Турецкого точно будет интересен, потому что это опыт Badoo, то есть речь об огромном количестве серверов. В таких масштабах все бэкапировать и, главное, проверять — задача нетривиальная. К тому же им удалось подружить современные тренды и парадигмы проектирования систем с резервным копированием так, чтобы не терять уверенности, что нужные данные можно достать в любом, даже самом критическом, случае.NB: Бэкапы без автоматической верификации — это не бэкапы.
Переезжаем на ClickHouse: 3 года спустя
ClickHouse уверенно завоевывает свои позиции, но мало кто из сторонних разработчиков успел накопить солидный опыт работы с ним. Александр Зайцев и Altinity пионеры использования ClickHouse, еще 3 года назад на HighLoad++ они рассказывали о переезде мульти-петабайтоврй аналитической системы на ClickHouse.Что изменилось с тех пор? Александр поделится накопленным опытом и know-how, которые нельзя найти в документации.
MongoDB vs. Postgres Benchmarks
О MongoDB на HighLoad++ будут рассказывать два гостя. У доклада Álvaro Hernández интересная, даже скандальная предыстория. Когда Альваро сделал и представил бенчмарки, сравнивающие MongoDB и PostgreSQL, завязалась перепалка в интернете. Позже MongoDB представили свои бенчмарки.
В итоге просто у каждого из миров своя философия. Адептам PostgreSQL трудно принять такое нечеткое отношение к данным, но решения MongoDB востребованы на рынке. Сравнивать их напрямую — дело почти невозможное, и это делает доклад Альваро очень увлекательным. Легко слепо придерживаться одной точки зрения, но намного лучше знать и понимать обе.
В этом всем — забавный факт — поучаствовал Майкл Стоунбрейкер. Он обратил внимание на спор между Postgres и Mongo и опубликовал несколько статей о проблемах этой модели. То есть основатель Postgres, который в свое время говорил, что один размер не подходит для всех, и как следствие запустил создание специализированных баз, в том числе NoSQL, сейчас по сути возвращается к Postgres. Он пишет, какие есть проблемы, предлагает поженить модели данных, и в общем говорит, что в Postgres все хорошо. Очень интересно наблюдать этот двадцатилетний цикл.
MongoDB distributed transactions from top to bottom
Второй доклад о MongoDB сделает Henrik Ingo — архитектор решений MongoDB, специализируется на повышении производительности MongoDB и обеспечении высокой доступности. Но Хенрик до MongoDB много лет работал в мире MySQL, поэтому точно знаком с аргументами разных лагерей.На HighLoad++ Хенрик расскажет, как сделать, чтобы транзакции в распределенной NoSQL базе данных удовлетворяли ACID, и зачем вообще это может понадобиться.
Odyssey roadmap: что ещё мы хотим от пулера соединений
Три недели назад главное ограничение PgBouncer, в которое часто упираются компании, было снято, но оно уже успело всем надоесть. Например, потому что невозможно было комитить доработки в open source — патчи Яндекса и Авито не принимали годами.Яндекс не стали дожидаться этих изменений и сделали свой пулер соединений — Odyssey. Он мультитредовый, у него есть дополнительные фишки, а подробнее расскажет Андрей Бородин в своем докладе. Кроме того, можно будет обсудить roadmap — какие функции пулера хотелось бы видеть в новых версиях сообществу.
DBA-бот Joe. Снимаем боль backend-разработки
Этим докладом Postgres.ai предлагает в корне изменить подход к разработке бэкенда. Вместо того, чтобы проверять код и запросы на маленьких базах, проверять на больших базах и сразу видеть результат. Звучит логично — если запрос медленный, это обнаружится сразу. Другое дело, что делать для этого, например, полноценные копии боевой БД очень неудобно. Вот тут на помощь и приходит искусственный DBA-боту Joe
Joe можно написать запрос или попросить создать индекс, и он выполнит все действия на полноразмерной копии боевой БД. В любой момент можно начать заново, отменив все изменения за несколько секунд, сбросив кэши ОС и СУБД. А для работы десяти разработчикам не понадобится x10 дискового пространства. Как работает эта магия, и из каких open source компонентов ее можно попробовать собрать у себя, расскажет Анатолий Станслер.
Дорогой DELETE. Типичные ошибки при выполнении массивных операций в высоконагруженных БД PostgreSQL
А если кому-то кажется, что нет ничего плохого в том, чтобы удалить несколько миллионов строк одним DELETE, когда известно условие и есть подходящий индекс, то нужно послушать доклад Николая Самохвалова. При попытке выполнить операцию в таких условиях, сервис скорее всего ляжет, и у этого есть сразу куча причин: и DBA недоработали, и разработчики неправильно себя вели, и организационный подход неправильный.Николай покажет, как эти проблемы помогает решать Postgres.ai и как без его использования настроить защиту и всегда действовать надежно, не роняя прод. Все это на реальном опыте боли и огромных финансовых потерь. Потому что как будто бы понятно, что можно не сразу удалять, а, например, сначала помечать данные на удаление, но блокирующие операции над миллионом строк все встречаются.
Patroni on GitLab.com
GitLab во всю используют PostgreSQL, недавно отказались от MySQL, а для обеспечения HA перешли с REPMGR на Patroni. Patroni разработан Zalando, его задача автоматически переключаться, если что-то случилось с мастером, и обеспечивать доступность сервиса.
Сейчас Patroni де-факто стандарт, и GitLab внедрили его на свое облачное решение — на секундочку, 25 000 000 git pull операций в день — и готовят решение для проверки инсталляций. Jose Cores Finotto поделится этим суперинтересным опытом на HighLoad++ 7 ноября.
StackGres: Cloud-Native PostgreSQL on Kubernetes
Álvaro Hernández корме сравнения PostgreSQL и MongoDB представит еще и продукт StackGres — по сути замену RDS. Но дает возможность намного дешевле развернуть RDS у себя в Kubernetes, получить прицепом настроенные с минимальными усилиями бэкапы, Patroni для auto failover, health check и еще кучу разных инструментов.Это перспективное начинание в направлении, похожем на историю с Linux. Есть ядро Linux, и много разных сборок вокруг него. То же самое мы видим и в отношении PostgreSQL, который можно считать ядром для СУБД, а вокруг него будут появляться сборки. У StackGres хорошие шансы завоевать популярность, потому что и команда задорная есть, и клиенты, на которых можно обкатывать свои решения.
Блокировки в PostgreSQL
Блокировки — в принципе тема, которую стоит послушать всем, кто работает с PostgreSQL. А тем более рассказывать про них будет Егор Рогов, который зарекомендовал себя, как офигительный лектор. Он глубоко знает материал и поможет разобраться в типах блокировок и понять, как читать pg_locks и pg_stat_activity и избежать ряда ошибок при проектировании систем. Доклад Егора на HighLoad++ — отличная возможность не просто послушать, а поговорить с экспертом, задать ему свои вопросы, возможно, обсудить совсем разные проблемы.
Резервное копирование нагруженных СУБД
Андрей Бородин и Георгий Рылов работают в Яндексе и занимаются развитием WAL-G — инструмента резервного копирования с открытым исходным кодом.
Изначально WAL-G — это инструмент для PostgreSQL, разработанный Citus (любопытно, что Microsoft недавно поглотил Citus, то есть по сути купил кусок PostgreSQL). Но оказалось, что идеи организации работы с WAL-G хорошо подходят и другим базам данных. Андрей и Георгий как раз и расскажут о функциональности для MySQL, Redis, MongoDB и открывающихся в связи с этим перспективах.
Vitess: Fearlessly Scaling in the Cloud
Sugu Sougoumarane — основатель PlanetScale. Возможно, вы пока не слышали об этой компании, но недавно она получила финансирование в 25 миллионов долларов на развитие своего открытого продукта Vitess. Возможно, вы и о Vitess ничего не слышали. Так вот Vitess — это система шардирования MySQL, и вы точно знаете не одну крупную компанию, использующую Vitess для высоконагруженных баз данных.
Всё началось с YouTube. Именно там Сугу и его команда создали то, что потом стало системой с открытым исходным кодом Vitess. Кстати, они выбрали Go — в то время ещё очень молодой язык. Сугу может рассказать много интересных баек про первые годы Go и про его развитие в целом — в Google его команда стала первым крупным пользователем языка.
Ну а сейчас кроме YouTube Vitess используют такие компании как GitHub, Pinterest, Slack, Square. После ухода из Google Сугу основал PlanetScale и продолжает развивать Vitess, сохраняя код открытым. Приходите послушать про шардинг планетарного масштаба и про использование Go в настоящем Highload. И не забудьте спросить про планы Postgres-версии Vitess — Сугу очень любит этот вопрос.
Patroni Failure Stories or How to crash your PostgreSQL cluster
Забавно, что основного мантейнера Patroni мы будем слушать на другую тему, потому что о Patroni он нам уже рассказывал. Зато Алексей Лесовский может рассказать, как Patroni эксплуатируют за пределами Zalando и какие шишки набивают. Потому что эти шишки могут сильно отличаться, и Алексей обещает поделиться деталями реальных crash-кейсов. Из доклада узнаем, какие бывают проблемы, какие уроки извлекли в Data Egret и как правильно конфигурировать Patroni (и, возможно, PostgreSQL). И, конечно, получим представление о том, как оперативно выявлять возникающие проблемы и оперативно их устранять.SQL/JSON: реализуем стандарт и не останавливаемся на этом
В последнее время, граница между реляционными и документоориентированными СУБД размывается. В стандарте SQL есть функции для работы с JSON, а PostgreSQL — пионер эффективной поддержки JSON среди реляционных СУБД. Во многом благодаря Postgres Professional стандарт уже частично реализован.
Доклад Александра Короткова — это рассказ из первых рук о реализации SQL/JSON и его «сердце» jsonpath в PostgreSQL. То есть возможность узнать о внутренних особенностях, опыте эксплуатации и планах на будущее.
PostgreSQL на K8s в Zalando: два года в бою
Александр Кукушкин — соавтор Patroni, но в этом году будет рассказывать об еще одной интересной разработке Zalando. Два года назад они начали разрабатывать Postgres-Operator, и на данный момент с его помощью оператора DBA обслуживают больше 1000 кластеров Postgres, работающих на Kubernetes.
Пока одни еще сомневаются, можно ли базы данных в Kubernetes, крупные компании уже работают со всем этим. Познакомиться и где-то перенять такой опыт будет еще круто.
Энтерпрайзные вызовы для Postgres'а
Крупные компании все больше используют PostgreSQL, очень часто ожидая от него того, к чему привыкли в энтерпрайзе. Типичный пример — нужно решения для логической репликации — обратимся к вендору. И некоторые вендоры даже сделали такую поддержку — был Oracle, теперь PostgreSQL появился. Но начинаем разбираться, и оказывается, многое работает по-другому.
На наших глазах происходит столкновение миров open source и энтерпрайза. Andreessen Horowitz недавно опубликовали исследование, в котором говорят, что интерес инвесторов к open source существенно вырос и будет продолжать расти. Поэтому и вендорам нужно переходить на open source и новые модели монетизации — это будет лучше по ряду причин.
Иван Панченко как раз расскажет, какие трудности миграции на PostgreSQL для энтерпрайза субъективны и относятся к типу «кривые руки», а когда это важные вызовы, с которыми PostgreSQL должен справиться в ходе своего развития. Тезисы обещают обсуждение таких тем: факторы масштабирования (объемы таблиц, количество объектов, память, коннекты, репликация), особенности хранилища (Heap, Pluggable storages), временные таблицы, вакуум, взаимодействие с ОС.И на этой ноте — будущее за opensource — закончим подробное изучение докладов. К сожалению, за кадром почти полностью остался MySQL. Если это ваша тема, обратите внимание на выступления Vittorio Cioe и Alkin Tezuysal.
ClickHouse тоже представлен в большем числе докладов, и как всегда особую ценность представляет митап, на котором можно будет задать любые вопросы по ClickHouse, вместе с разработчиками найти решение проблем, обсудить возможности и планы.
Так же мы не касались Tarantool, так как это база данных и сервер приложений в одном флаконе. И доклады в программе HighLoad++ 2019 акцентируют внимание на этой многофункциональности. Василий Тюбек расскажет о Tarantool Kubernetes Operator для запуска базы данных в Kubernetes, Ярослав Дынников покажет удобство построения распределенных систем с использованием Tarantool. И не упустите возможность уточнить все детали у самих разработчиков — это гораздо продуктивнее и интереснее, чем читать документацию.
Мы вообще считаем вопросы спикерам, кулуарные дискуссии и нетворкинг — очень, если не самой, важной частью конференции. Поэтому создаем все условия для неформального общения и стараемся, чтобы вы хорошо провели время.
7 и 8 ноября HighLoad++ до краев заполнит СКОЛКОВО и выплеснется за его пределы. В Новосибирске и Санкт-Петербурге будут свои филиалы HighLoad++ с телемостом в Главный зал и всеми плюшками нетворкинга на конференции. На youtube запустим открытую видеотрансляцию самых ожидаемых докладов и Премии HighLoad++, а в telegram-канале по другой траектории пустим агентов текстовой трансляции. Короче, даже если вы не едете на HighLoad++ (зря-зря — еще можно передумать, оформить билет и рвануть), то все равно можете получить массу пользы и фана через наши сети.
