Давайте немного пофилософствуем. Давайте поговорим о будущем. Будущем разработки, будущем индустрии. Каким оно может оказаться?

ClickHouse — это не только популярная поколоночная СУБД, но и быстроразвивающийся opensource-проект на языке C++. В неделю мы вливаем около 40 пул-реквестов, 15% из которых привносится внешними контрибьюторами. Такие темпы развития требуют хорошей автоматизированной инфраструктуры тестирования кода на всех уровнях.

В докладе я расскажу о том, как устроен CI ClickHouse и из каких компонентов состоит pipeline тестирования. Сначала речь пойдёт об особенностях покоммитных сборок ClickHouse с разными конфигурациями в различных OS. Затем будут рассмотрены все этапы тестирования, начиная от статического анализа кода и заканчивая интеграционными тестами и тестами производительности. В заключение я расскажу о преимуществах, которые нам дает CI: удобство в обнаружении багов, организация двухнедельного релизного цикла и улучшение работы с контрибьюторами.

Я расскажу о том, какие уроки мы извлекли, создавая высокодоступный геораспределённый сервис персистентных очередей на основе широко используемой в Яндексе Yandex Database. Мы обсудим различные подходы, позволившие нам эффективно разрабатывать, тестировать, мониторить и отлаживать систему, используемую одновременно сотнями клиентов с высокими требованиями к доступности и скорости работы.

Также мы поговорим о клиентских сценариях, в которых использование распределённых очередей сообщений оказывается наиболее эффективным.

План доклада:
Архитектура
- Что такое распределённая очередь и зачем она нужна.
- API распределённой очереди.
- Yandex Database и её свойства, которые используются для решения задачи.
- Наивное решение и его проблемы.
- Понятие мастера: обработка всех запросов к одной очереди на конкретной машине кластера.
- Проблема нескольких мастеров.
- Кэширование информации по очередям в памяти.
- Как сделать меньше одной транзакции на пользовательский запрос.
- Что делать, если запросов слишком много.

Разработка
- Связывание событий по одному запросу на разных машинах.
- Борьба со слишком большим количество логов.
- Написание неудобных клиентов.
- Тест консистентности.
- Логирование медленных запросов.
- Трассировка по требованию.
- Включение подробных графиков.

Когда в компании надо принимать решения на основании показателей, отдел BI — главный помощник.

В ход идут пересечения потоков данных, витрины, data research и просто метод пристального взгляда.

Для решения всех возникающих случаев манипуляции данными не всегда существует универсальное хранилище, которое является серебряной пулей. Hadoop — это, как правило, высокий показатель latency, аналитические базы данных — не OLTP, в каких-то решениях отсутствует поддержка транзакционности.

В докладе рассмотрим, как мы в BI используем связку Exasol и Hadoop. Рассмотрим аспекты ETL и технические решения, которые мы используем для интеграции этих хранилищ.

Мы расскажем про Event Storming — отличный способ проектировать, используя Domain Driven Design.

Поговорим про DDD и обсудим опыт использования. Попробуем спроектировать систему с помощью Event Storming.

Чем хорош Event Storming?

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

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

* Что такое фасетный поиск, общие принципы работы.
* Как это было реализовано на Solr. Как мы обновляли данные в поиске. Почему мы решили взять ElasticSearch. * Как работать с legacy-кодом. Какая конфигурация кластера нам подойдет. Как обновлять данные в реальном времени без downtime.

В докладе мы расскажем, как используем устройства и технологии Яндекс.Станции, Google Home, Irbis A и DEXP Smartbox для управления корпоративным порталом Битрикс24. Поговорим об алгоритмах и возможностях Google Ассистента и Яндекс.Алисы для распознавания голоса, определения намерения и разбора текста. Расскажем, как мы подружили эти технологии с нашими для создания Задач, событий в Календаре, Встреч, Совещаний и отправки Сообщений сотрудникам компании.

Отдельно рассмотрим практики применения технологий машинного обучения для решения возникающих при голосовом управлении задач и как обходить подводные камни. Проанализируем возможности библиотеки deeppavlov.ai.

Разбор трех реальных кейсов внедрения GraphQL.

• Доводы за и против перехода на GraphQL.
• Как безопасно делегировать логику группировки данных на frontend и разгрузить backend-разработчиков.
• Использование на примере проекта с микросервисной архитектурой, монолита.
• Недостатки, которые мы осознали, только столкнувшись с ними.
• Инструменты для разработки с сервисов GraphQL в продуктах от Jetbrains.

Поисковый запрос в 2ГИС содержит 25+ параметров, начиная c введенного текста и заканчивая персональными предпочтениями пользователя. Чтобы обеспечить стабильную работу приложения, мы решили не ограничиваться тестовыми запросами, сгенерированными человеческой логикой. Так в нашей жизни появился фаззинг — тестирование приложения на неправильных, неожиданных или случайных данных.

Обсудим, что представляет собой фаззинг и когда его не стоит использовать. Расскажу о причинах выбора библиотеки libFuzzer, интеграции в наш пайплайн и результатах ловли труднонаходимых ошибок.

Многие при создании стартапа для быстрой разработки в условиях неопределенности выбирают NoSQL-решения, планируя с ростом проекта перейти на "более серьезные" базы данных на основе SQL.

Юла существует и быстро развивается уже в течение трех лет и всё еще живет на NoSQL и осознанно не планирует перехода. Этот доклад будет полезен разработчику, который наслышан об историях о ненадежности и сложной поддержке NoSQL. Своим рассказом и конкретными примерами я попробую доказать обратное.

Я буду аргументировать на конкретных примерах наш выбор NoSQL и акцентировать внимание на том, что за три года существования Юлы мы ни разу не пожалели об этом решении. Она до сих пор помогает нам развиваться быстро и максимально безболезненно для текущего состояния кода.

Во всех ключевых облачных хранилищах данных существует множество средств миграций из in-house-хранилищ, однако, как мне кажется, путь к успеху в миграции в "облака" состоит не только из уменьшения затрат на обслуживание инфраструктуры, но и повышения производительности путём изменения модели данных под особенности каждого из хранилищ.

Я попробую доказать, что копирование традиционных star- и snowflake-схем не позволяет получить максимальную производительность в таких хранилищах как Amazon Redshift и Google Big Query, но и приводит к дополнительным финансовым затратам.

Мы обсудим, почему модели данных одного и того же хранилища должны быть разными между Redshift и Big Query, как эффективно использовать возможности данных СУБД.

Большинство советов по работе с данными СУБД сводится к "увеличьте размер кластера" или "добавьте sort key". Порой это уменьшает скорость выполнения запросов при гораздо более высокой стоимости владения.

Будет продемонстрировано несколько примеров с production, как с уменьшением мощности кластера общая производительность системы повысилась, а также рассмотрен ряд радикальных подходов, как системы с единственной сверхширокой таблицей фактов вместо star-схемы с таблицами фактов и измерений.

nbtree-индексы существуют в PostrgeSQL более 20 лет, это основной и самый используемый тип индексов. В 12-й версии были внесены существенные изменения в то, как работают эти индексы.

Для начала мы рассмотрим устройство и принципы работы таких индексов: внутренние структуры, основные операции, а также проблемные места при эксплуатации этих индексов (да, это связано с распуханием).

Затем поговорим о том, какие изменения были сделаны для 12-й версии PostgreSQL (выйдет осенью 2019 года) и о заложенных возможностях для будущих улучшений.

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

Как обстоят дела с High Availability в PostgreSQL в 2019 году.

Очень коротко и быстро посмотрим на решения, которые были созданы в до-облачную эпоху... pgpool, bucardo, postgres-xc/xl. Разберем их недостатки (и преимущества?) и почему эти решения остались за бортом прогресса.

Более подробно остановимся на современных молодых решениях, таких как repmgr, patroni, stolon. Рассмотрим их перспективы, преимущества и недостатки, отличия и ниши для применения.

Чтобы поддерживать базы данных в здоровом состоянии, необходимо периодически заглядывать «под капот», «прощупывать» её на наличие ранних симптомов — другими словами, делать профилактическое исследование, оно же технический аудит БД, оно же healthcheck.

Проведение такого исследования вручную у нас занимало обычно несколько недель, особенно в случаях, когда БД мы видим впервые. В эру облаков и автоматизации это никуда не годится, пришло время соптимизировать эту процедуру. Так появился новый открытый проект: postgres-checkup (https://gitlab.com/postgres-ai-team/postgres-checkup). С ним аналогичные исследования стали длиться всего несколько часов.

Десятки различных отчётов, включающие в себя опыт DBA из различных компаний, объединены в удобный для запуска и использования инструмент. Среди основных его качеств:
- малозаметность (эффект наблюдателя сведён к минимуму),
- отсутствие требования установки чего-либо на машины с СУБД,
- форматы отчётов, удобные для потребления как людьми (markdown, HTML, PDF), так и машинами (JSON).

Мы поговорим о том, как postgres-checkup помогает нам диагностировать проблемы с производительностью и масштабированием в различных проектах, от небольших стартапов до многомиллиардных компаний. Также обсудим следующие вопросы:
- расширяемость (добавление своих отчётов) и интеграция с существующими системами;
- автоматизация и встраивание в процессы организации;
- особенности доведения информации до инженеров, которые не являются специалистами по СУБД, так, чтобы слова превращались в действия, оптимизирующие состояние БД.

Подробнее остановимся на крупных темах:
* bloat & autovacuum,
* здоровье индексов,
* комплексных глубокий анализ запросов на основе pg_stat_statements и pg_stat_kcache.

Yandex Database (YDB) — геораспределенная транзакционная база данных, позволяющая выполнять декларативные запросы над данными с низкими задержками и строгой консистентностью. В докладе будут рассмотрены основные моменты, связанные с выполнением распределенных запросов в YDB.

Мы поговорим про применяемую модель транзакций и уровни изоляции, особенности SQL-диалекта Yandex Query Language (YQL), параметризацию и подготовку запросов, многошаговые транзакции и механизм оптимистичных блокировок.

Также будут затронуты общие вопросы эффективного выполнения запросов в распределенных базах данных. Мы рассмотрим основные факторы, влияющие на производительность запросов, и стандартные практики при работе с YDB.

GraphQL-схема может обернуться головой болью и кучей дополнительного кода для разработчиков. Поэтому, чем удобнее схема, тем быстрее, легче и с меньшим количеством ошибок будут разработаны ваши клиентские приложения.

Рекомендации и правила, о которых будет доклад, были выработаны за 3 года использования GraphQL как на стороне сервера (при построении схем), так и на клиентской стороне (написания GraphQL-запросов и покрытием клиентского кода статическим анализом).

Версия 2, доработанная с учетом правок от комьюнити и ревью от GraphQL-гуру Михаила Новикова и Ивана Гончарова.

В данном докладе я хочу поделиться опытом Авито, полученным за годы эксплуатации бинарной репликации и стендбаев. Мы многое переосмыслили, разработали свои подходы и техники, планы восстановления после аварий в распределенных системах.

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

Вторая часть выступления — о подводных камнях, о которых многие даже не подозревает, а другие принимают все риски. Речь пойдет о различных кейсах, которые могут привести к деградации вашего приложения и способах решения, а именно:
* высокий уровень TPS;
* применение DDL;
* отправка большого кол-ва WAL-файлов в архив и восстановление из архива;
* и др.

Расскажу про использование пула стендбаев и переключения запросов между ними. Также о планах восстановления после аварий для приведения в согласованное состояние мастера, стендбаев и архива.

Нет смысла искать серебряную пулю, которая одновременно найдёт потенциальные уязвимости, проверит оформление кода, предупредит о запахах кода и вообще сделает "хорошо". Есть возможность собрать коллекцию инструментов, которая будет решать те задачи, которые стоят перед разработчиками. Однако, собрать коллекцию мало, нужно ещё иметь возможность единообразно работать со всеми отчётами, предоставляемыми разнородными инструментами, такими как статические анализаторы кода, санитайзеры, компиляторы, инструменты анализа покрытия кода и так далее. Поэтому поговорим о SonarQube, который может стать такой обобщающей платформой и посмотрим на примерах, как осуществляется интеграция различных средств.

Работа с транзакциями в базе данных — одна из больных тем при разработке backend-приложения. При кажущейся простоте процесса ("сначала BEGIN, в конце COMMIT") в разных проектах периодически возникают одни и те же ошибки. Причина в одинаковых подходах к работе с транзакциями, которые правильнее назвать анти-паттернами. Я расскажу, как решать основные проблемы:
• Зависание транзакций (с помощью автоматизации операций ROLLBACK).
• Вложенные транзакции (средствами СУБД, и почему это опасно делать на уровне приложения).
• Выбор нужного сервера (мастер или реплика) в зависимости от ситуации.
• И ряд проблем поменьше, но от этого не менее важных.

Все решения я проиллюстрирую живыми примерами (PHP+PostgreSQL), взятыми из практики. Итогом доклада будет общая стратегия организации кода, позволяющая обойти рассмотренные грабли, и связывающая воедино транзакции, подключения к базе данных и обработку ошибок. Доклад будет полезен разработчикам, а также тем DBA, которые всё ещё страдают от выходок разработчиков.