Заявки на доклады

Узкотематические секции: видео, поиск, RTB, биллинги

Масштабировать видеосвязь повышая качество: маленькой командой и с кучей ограничений на старте

Скайэнг, был 2019 год, 1,5к одновременных урока и жалобы на видеосвязь.
В докладе я пройду по нашему пути понимания проблем с видеосвязью, как мы начали ее измерять, как от субъективных оценок перешли к объективным на базе ML и определили основные проблемы с видеосвязью.
Как попробовали Pion вместо Janus и принудительную деградацию видеосвязи вместо встроенного механизма в WebRTC.
В итоге мы выросли с 1,5 до 4к одновременных уроков, снизив при этом негативные отзывы на видеосвязь с 14% до 5%.

Программный комитет ещё не принял решения по этому докладу

Тестирование, нагрузочное тестирование

RPS имеет значение

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

За 3 года работы мы попробовали много различных инструментов и подходов. В докладе мы расскажем:
- Зачем нужно нагрузочное тестирование
- Какую полезную информацию мы можем из него извлечь
- Какой эволюционный путь мы прошли по налаживанию процессов нагрузочного тестирования
- Какими инструментами пользовались, с какими подводными камнями сталкивались
- Что такое K6, и почему в конечном счете мы выбрали его основным инструментом

Программный комитет ещё не принял решения по этому докладу

Бэкенд, теория программирования

TLA+/TLC: формальный метод верификации конкурентных алгоритмов для инженеров.

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

Находить такие ошибки можно, даже не написав ни строчки кода -- если пользоваться методами формальной верификации алгоритмов. Таких методов много, но один из них -- разработанный в 1999 г. Лесли Лампортом (Leslie Lamport) формализм TLA+ и инструмент верификации TLC -- оказался ближе всего инженерам, и приобретает все большую популярность.

Мы поговорим про TLA+/TLC, про PlusCal -- транслируемый в TLA+ язык спецификации алгоритмов специально для инженеров, про инструментарий, а также про практики применения TLA+/TLC в реальных проектах.

Программный комитет ещё не принял решения по этому докладу

BigData и машинное обучение

ETL сервисы и таски для Такси, Еды и Лавки. Как мы разрабатываем платформу управления данными

Такси, Еда и Лавка - компания с устойчивой Data Driven культурой, где все решения анализируются и проверяются с оглядкой на данные, а скрипт на Python или SQL может написать любой. Мы начали строить централизованное Хранилище Данных (Data Warehouse, DWH) в Такси порядка 4-х лет назад. Год назад провели масштабный ребрендинг и стали себя гордо именовать DMP, Data Managment Platform. На текущий момент у нас порядка 5 сотен бизнес-пользователей, пара сотен продвинутых потребителей данных - аналитиков, data scientist'ов и бекенд разработчиков из смежных команд. Объем Data Lake на YT (in-house аналог Hadoop, https://habr.com/ru/company/yandex/blog/311104/) более 1ПБ и ежемесячный прирост по 100ТБ. Целевое эффективное пространство в DWH на Greenplum 0.5ПБ. Каждый день в нашей инфраструктуре запускается сотни тысяч ETL процессов. Мы поддерживаем ETL на MapReduce, Spark, 3-х диалектах SQL и голом Python. Мы выстроили свои процессы и инфраструктуру таким образом, что к нам могут контрибьютить аналитики данных и бекенд разработчики.

В своем докладе я расскажу:

1. Немного деталей про DMP в Яндекс.Такси, Еде и Лавке: какие данные хранятся в Data Lake и в каком формате, какие слои и потоки данных есть в DWH: как мы несем данные от десятков различных источников до дашбордов в Tableau и OLAP кубов в MS SSAS.
2. Почему мы решили вместо готового ETL инструмента написать свой, и как он работает с такими вычислительными системами, как Spark, Greenplum, ClickHouse и YT.
3. Как устроена наша монорепа из ETL сервисов и процесс разработки, отладки и деплоя.
4. Технические подробности: запуск ETL процессов в 2-х дата центрах, организация тяжелых потоков данных между большими хранилищами, мониторинг наших процессов, проверки качества данных и многое другое.
5. Про взаимодействие между дата инженерами и бекенд-разработчиками и аналитиками данных на уровне кода.

Программный комитет ещё не принял решения по этому докладу

Проксирование данных для Hadoop

Андрей Ильин

Сбербанк

Для чего нужно проксированние данных - HDFS/Hive/Sentry?
Как проксировать данные для Hadoop?
Особенности при разработке продуктов на основе библиотек Hadoop-а.

Программный комитет ещё не принял решения по этому докладу

Как построить Data Mesh в компании на Open Source

Дмитрий Шостко

Леруа Мерлен

• Data Mesh — что это и зачем он нам (зачем Data Mesh в ритейле, и где Леруа Мерлен нашёл свой особый путь).
• Не весь Open Source одинаково полезен. Карго-культ в open source, и как мы натягивали технологии на подход и философию.
• Мета-принципы для Data Mesh в Леруа Мерлен: Cloud native, Open Source, API First, Scalable by default, Fault tolerance.
• Как и зачем доносить мета-принципы до линейных сотрудников?
• Технологии и подходы к эволюции технологий.
• Из чего состоит наша платформа и как она строится? Как мы работаем с клиентами в ее построении — Customer Development.
• Таймлайн совершенствования платформы.
• Как мерить эффективность? Деньгами? Нет — довольными клиентами!
• Как уравновесить хотелки клиента и базовые мета-принципы?
• Fail fast Fail cheap-подход.

Программный комитет ещё не принял решения по этому докладу

Как автоматически оптимизировать Spark-расчёты в высоконагруженном кластере

Представьте: каждый день по расписанию запускаются сотни ресурсоемких расчётов. Эти расчёты формируются без участия разработчика с помощью гибкого конструктора, могут быть любой сложности, и число их постоянно растёт. В этих условиях разработчику бесполезно оптимизировать каждый отдельный расчёт: это чересчур трудозатратно. Как же при этом сохранить жизнеспособность кластера? Мы будем говорить о том, как гибко оценивать требуемые ресурсы, не прибегая к ручному тюнингу.

В своём докладе я расскажу:
– Как извлечь полезную информацию из логов Spark
– Как подбирать оптимальную память для расчёта на основе истории запусков
– Как полностью автоматизировать этот процесс

Программный комитет ещё не принял решения по этому докладу

Нейронные сети, искусственный интеллект

Использование технологий компьютерного зрения и глубокого обучения в ритейле

Расскажу про проекты, которыми занимается наша команда в X5 Retail Group: анализ доступности товаров на полках и детектирование очередей на кассах. Данная система развернута в десятках магазинов. Она использует нейронные сети для анализа данных с камер, на основе обработанных данных система находит проблемы с пустотами на полках и большим количеством людей на кассах и отсылает уведомления сотрудникам магазинов.

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

Доклад принят в программу конференции

Производительность мобильных приложений

Life-style банкинг

Life-style банкинг, Банк в Social Media, Финтех проекты, Синергия Банков и IT компаний.

Программный комитет ещё не принял решения по этому докладу

Разбираем монолит по кирпичикам

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

В докладе хочу поделиться опытом, как мы перешли от нашего монолитного проекта к мультимодульному. С какими проблемами столкнулись, какие технические решения использовали. На примерах покажу решения задач: с зависимостями, навигацией и оптимизацией скорости сборки.

Также отвечу на вопросы: нужна ли мультимодульность в ваших мобильных проектах и что следует учитывать, чтобы переход на нее был максимально безболезненным.

Доклад принят в программу конференции

Аппаратное обеспечение, инфраструктура

Повседневная практическая векторизация

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

Попробуем посмотреть на современный процессор Х86 и его векторные расширения с практической стороны — как это можно использовать повседневно и для базовых задач. Параллельный поиск в дереве, параллельное вычисление множества хэш-функций, сортировка, переупорядочивание и транслирование данных — все это может быть ускорено при корректном применении векторизации. Как и может быть существенно замедлено при некорректном. Практическое применение AVX2 и AVX-512 на примерах проб и ошибок, подчеркивая архитектурные основы векторизации и методику их применения в повседневной практике.

Доклад принят в программу конференции

Архитектуры, масштабируемость

Модульный монолит вместо микросервисов: как, когда и зачем

Микросервисы сегодня - это хайп, о котором говорят на каждой конференции. Складывается мнение, что старый добрый монолит - это плохо, а микросервисы - таблетка от всех болезней. Но так ли это на самом деле?
В своем докладе мы расскажем о том, когда стоит предпочесть монолит микросервисам. А также о том, что монолиты бывают разные, это не обязательно большой комок грязи. Модульный монолит позволяет сделать такую же качественную изоляцию частей системы друг от друга, как это предлагают микросервисы, при этом сохранив простоту отладки, деплоя и работу в рамках одной транзакции. Да, писать хорошие монолиты тоже нужно уметь :)
В докладе мы расскажем о том, когда обычному монолиту пора становиться модульным и как перейти от обычного монолита к модульному.

Программный комитет ещё не принял решения по этому докладу

Доставим смс мгновенно! Практики построения транспортного хаба, в условиях повышенных требований к скорости и надежности.

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

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

В своем докладе я расскажу как с нуля и в короткие сроки построить enterprise систему, как выбрать ключевые метрики, как в "день X", когда разово будет переключен весь трафик оператора, успешно выдержать эту нагрузку и стать не просто новой системой обмена трафиком, а корпоративным транспортным хабом.

Программный комитет ещё не принял решения по этому докладу

Как "мамкины архитекторы" бизнес международный масштабировали. Как избежать ошибок.

Ошибки с которыми столкнулись разработчики (Ruby, Golang, Python) при масштабировании финтех стартапа в странах Азии.

Программный комитет ещё не принял решения по этому докладу

Как масштабировать Чистую Архитектуру

Сейчас о Чистой Архитектуре много говорят, но в основном это делают разработчики Andriod-приложений :) А о практике применения Чистой Архитектуры в кровавом Enterprise практически нет информации, хотя эта архитектура предназначена как раз для масштабных проектов со сложной бизнес-логикой.
В докладе мы расскажем об опыте применения Чистой Архитектуры в проектах разного размера: микросервис, стартап, средний и большой проект с несколькими Backends-For-Frontend. После доклада все слушатели получат шаблон проекта для каждого размера и четкую инструкцию как масштабировать проект от меньшего размера к большему, сохранив при этом его соответствие Чистой Архитектуре.

Программный комитет ещё не принял решения по этому докладу

Как мы придумали API для управления кластерами K8s

Можно ли деплоить Kubernetes-кластеры так же просто, как мы деплоим приложения? Да, мы сделали Kubernetes проще.

Декларативные API и инструменты для автоматизации развертывания и сопровождения жизненного цикла отдельных узлов и целых кластеров OpenShift.

Доклад принят в программу конференции

Концентрируемся на бизнес-модели данных: от ETL к ELT

Два года назад мы (компания Scentbird), пережив серьезный рост, решили строить свою систему аналитики для обеспечения необходимой гибкости. Мы постоянно совершенствуемся в этом направлении, и самым качественным изменением в нашей архитектуре за последнее время стал переход от ETL к ELT-концепции посредством инструмента DBT. Это позволило нам сосредоточится на бизнес-смысле перевозимых данных, вместо технических особенностей процесса трансформации данных.

В отведенные 45 минут обсудим:
- отличия концепции ETL и ELT на примере нашего стека технологий;
- базовые концепции инструмента для преобразования данных DBT;
- как мы используем DBT для построения сложных моделей, а также осуществляем тестирование данных;
- как масштабируется такое решение.

Программный комитет ещё не принял решения по этому докладу

Есть ли польза от CQRS не только для высокой нагрузки?

Обычно говорят, что CQRS полезен для HighLoad проектов, где денормализованная Read модель отделяется от Write модели, и за счет этого скорость Read запросов качественно возрастает. При этом рекомендуется реализовывать логику приложения в виде отдельных классов-хендлеров для каждого юскейса. Но будет ли от такого подхода польза, если в приложении не стоит проблема высокой нагрузки?
Я поделюсь своим опытом улучшения архитектуры при помощи CQRS в проектах, где небыло большого количества пользователей и/или данных. Расскажу о том, какие дополнительные возможности по сравнению с классической слоистой архитектурой привнесет этот подход и от каких проблем он позволит избавиться. И, конечно, расскажу как организовать переход с классической слоистой архитектуры на CQRS-хендлеры.

Программный комитет ещё не принял решения по этому докладу

Service Mesh на стероидах. Часть 1: как построить управляемое взаимодействие между сотнями микросервисами

Доклад основан на кейсе по разработке Enterprise-grade приложение, состоящего из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза и т.д. Суммарно размер такого решения может составлять несколько сотен различных юнитов, преимущественно микросервисов. Между этими юнитам нужно построить управляемое взаимодействие, учитывая множество специфических ограничений и условий, таких как:
• распределенность микросервисов по различным дата центрам
• поддержка "session stickiness"
• поддерживать canary и blue-green модели
• для входящих потоков нужно чётко разделять - какие API публикуются из приложения для каких клиентов
• multitenancy
• и этот список можно продолжать.

На помощь приходит такая концепция как Service Mesh и идея применить "микросервисную модель" и к структуре Service Mesh. В результате был разработан Non Uniform Service Mesh (NUM), который представляет из себя продукт и набор паттернов его применения.
В докладе я на примере крупного приложения разберу типовые паттерны применения NUM:
• интеграция разнородных приложений в единый service mesh и управление связями
• реализация application security (authentication, M2M)
• условная маршрутизация запросов в зависимости от бизнес-параметра
• "stickiness" между микросервисом (kubernetes pod) и запросом (ордером, пользователем, HTTP сессией)
• выкатывание обновлений по canary модели
• multitenancy с применением модели instance per tenant и shared multitenant instance
• кастомизация логики гейтвея
• интеграция с 3rd party системами (серверная, южная)

Программный комитет ещё не принял решения по этому докладу

Распределение нагрузки в SaaS сервисах. Безопасная изоляция без контейнеров.

Кирилл Жуков

QNIUM (КЬЮНИУМ)

Обсудим проблему изоляции данных между логически изолированными пространствами при разработке больших информационных систем с разделением tier по группам пользователей. Современный DevOPS работающий на облаке чаще всего делает это с помощью Docker контейнеров и/или виртуальных серверов в облаке. Создание экземпляров таких автономных систем происходит автоматически, по мере потребности, например когда регистрируется новая организация и для нее создается свое изолированное рабочее пространство. Однако все ли так гладко и всегда ли это эффективно? Рассмотрим альтернативный подход с боевым примером.

Программный комитет ещё не принял решения по этому докладу

How to Stream 100B+ Events Daily with Spark Structured Streaming

Ivan Kosianenko

AppsFlyer

At AppsFlyer we ingest more than 100 billion events daily through our Kafka operation, which is then stored in a data warehouse hosted on Amazon S3. With AppsFlyer's increasing growth & scale, latency of data and resilience of the system began to pose complexities, and we found that we had to start rethinking our current approach and provide a better way to do our raw data processing.

This talk will focus on how we migrated the current raw data ingestion system to a solution based on Spark structured streaming.

I'll discuss what Spark structured streaming even is, some of the motivators for the migration, and why it was the right solution for us. You will get to see some of the challenges we faced during implementation, such as picking the correct data partitioning, how we ensured continued compliance with our GDPR solution, and the tooling we built to support the migration while providing our exactly-once solution.

The solution and the approaches that will be presented in this talk can be applied in your own data pipelines to create more resilient systems and correct data flows.

Доклад принят в программу конференции

Как Яндекс.Афиша 2 раза переезжала на GraphQL

Мы расскажем о том, как переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.
Поясним, почему мы выбрали технологию GraphQL, какие проблемы и задачи решали с ее помощью. Расскажем и покажем как эволюционировала наша архитектура. Дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL. Расскажем для каких команд и проектов подходит наше решение, а для каких нет и почему.

Программный комитет ещё не принял решения по этому докладу

Как снизить накладные расходы на добавление +1 микросервиса

В докладе рассмотрим вопросы накладных расходов при каждом добавлении нового микросервиса с позиции разных ролей команды — архитектора, разработчика и QA. И, конечно же, поговорим о том, как снизить эту стоимость практически до нуля.
Зачем в это вкладываться? Если этого не сделать — велика вероятность напилить набор минимонолитов, т.к. добавить фичу в существующий сервис будет гораздо проще, чем выделить отдельный.
По итогам доклада слушатели получат набор процессных практик, практик разработки, практик devops и QA для снижения стоимости добавления микросервиса. Также поговорим о границах применимости предлагаемых подходов.

Программный комитет ещё не принял решения по этому докладу

Как подготовить интернет магазин на 1С-Bitrix к черной пятнице

Дмитрий Иоффе

ENTER Engineering

CMS 1c-Bitrix одна из самых популярных CMS и CRM в СНГ, поговорим с вами как его готовить и спокойно жить в Черную пятницу, обсудим основные проблемы и решения

Программный комитет ещё не принял решения по этому докладу

Построение масштабируемой и гибкой системы потоковой обработки данных: как мы дали возможность загрузить в 2ГИС товары и услуги для 4.5М компаний

В 2ГИС есть информация о 4.5 миллионах компаний в сотне городов, и для всех мы хотим отображать информацию о товарах и услугах, которые они представляют. У нас есть разные способы загрузить информацию о товарах и услугах: с помощью прайс-листа, поштучно через CRUD интерфейс, настроить синхронизацию с 1С, получать данные от внешних партнеров (Booking, DeliveryClub, Yclients, СберЗдоровье). У каждого из этих источников своя периодичность обновления, объем данных и формат.

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

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

Программный комитет ещё не принял решения по этому докладу

Каталог из 30 млн. товаров в стиле DIY: как мы организовали быстрый доступ к данным с минимумом технологий

В крупнейшем онлайн-гипермаркете перед нами стояла задача: обеспечить быстрый доступ к данным каталога (более 30 млн. товаров), избежав технологического зоопарка. Обилие технологий потребовало бы дополнительных ресурсов — команд и компетенций для поддержки соответствующих подсистем.

В качестве решения мы использовали собственное inMemory-хранилище с быстрым доступом к данным по ключу, индексированием, шардированием и репликациями, разработанное стандартными средствами Golang.

Доклад охватывает весь флоу решения задачи: от постановки до архитектуры и конечной реализации.

Программный комитет ещё не принял решения по этому докладу

DevOps и эксплуатация

Есть ли жизнь без ELK? Как снизить стоимость Log Management используя Kafka, ClickHouse и Vector

Дефолтной системой для обработки логов традиционно является ELK-стэк. Он бесплатный, удобный, но требовательный к вычислительным ресурсам.
Можно ли в разы снизить затраты на хранение и обработку логов?

В докладе я поделюсь опытом построения централизованной системы для управления логами. Расскажу про процесс выбора решений, почему мы остановились на связке Vector/Kafka/ClickHouse, какие есть сложности в работе с логами в ClickHouse и как их решать, а также как мы эффективно пишем, анализируем и храним сотни гигабайт логов в сутки.

Программный комитет ещё не принял решения по этому докладу

Инфраструктура как микросервисы. Зачем и почему?

Подход IaC позволяет решать множество задач, оптимизировать работы с инфраструктурой и создавать надежные системы. Количество и качество инфраструктурного кода растет, но разработчики часто забывают, что кроме унификации и best practice в инструментах, есть еще практики, наработанные разработчиками за многолетнюю историю, в том числе в разработке микросервисов.
В ходе доклада я расскажу о том, как применять подходы, принятые в разработке микросервисов к инфраструктурному коду, зачем это нужно и какие проблемы это решает, а так же как это помогает бизнесу уменьшить затраты на поставки в продакт среду.

Программный комитет ещё не принял решения по этому докладу

Как построить высоконагруженное и отказоустойчивое S3 хранилище.

Количество данных в современном мире растёт с очень большой скоростью и часто уже не хватает обычных raid хранилищ для хранения пользовательских данных. Поэтому многие задумываются о построение своих больших отказоустойчивых систем для хранения пользовательских данных и по многим причинам отказываются от "облаков". Сразу возникает вопрос, как же построить своё отказоустойчивое и надёжное s3 хранилище.
Для построения собственного s3 облака мы будем использовать Ceph.
Основные тезисы:
* С чего начать построение S3 кластера. Какие способы развёртывания Ceph существуют и какой лучше выбрать для интеграции с ci/cd и для дальнейшей поддержки.(Rook, ceph-ansible, Cephadm и тд.)
* Как работает Сeph под капотом.
* Методы оптимизации Ceph и характеристики железа. Тюниг ОС. Стоит ли использовать raid внутри ceph.
* Настройка RADOS Gateway. Что стоить учесть при работе с объектным хранилищем.
* Поведение кластера в различных ситуациях.
* Репликация данных. Master-Master. Master-Slave. На какие моменты стоит обратить внимание.
* С какими проблемными мы столкнулись в процессе эксплуатации.

Программный комитет ещё не принял решения по этому докладу

Базы данных и системы хранения

Joining Heterogeneous Databases is a reality, not a Myth

Ibrar Ahmed

Percona LLC

PostgreSQL provides a way to communicate with external data sources. This could be another PostgreSQL instance or any other database. The other database might be a relational database such as Clickhouse, MySQL, or Oracle; or any NoSQL database such as MongoDB or Hadoop. To achieve this, PostgreSQL implements ISO Standard call SQL-MED in the form of Foreign Data Wrappers (FDW). This presentation will explain in detail how PostgreSQL FDWs work. It will include a detailed explanation of simple features and will introduce more advanced features that were added in recent versions of PostgreSQL. Examples of these would be to show how aggregate-pushdown and join-pushdown work in PostgreSQL.

The talk will include working examples of these advanced features and demonstrating their use with different databases. These examples show how data from different database flavors can be used by PostgreSQL, including those from heterogeneous relational databases, and showing NoSQL joins.

Программный комитет ещё не принял решения по этому докладу

Подсистема I/O в PostgreSQL: архитектура, проблемы, обходные пути

Несмотря на то, что подсистема ввода-вывода PostgreSQL вполне хорошо подходит для большинства решаемых задач, она все-таки имеет несколько особенностей и проблем:
* трудно предсказать задержку записи/чтения данных, особенно для баз данных, размер которых значительно больше доступной памяти;
* пропускная способность ввода-вывода, особенно в быстрых подсистемах хранения (например, в NVMe-дисках), недостаточно высока для использования на все 100%;
* бэкенды сами выполняют слишком много операций ввода-вывода, так как фоновый писатель (bgwriter) работает не очень оптимально;
* генерируется ненужная случайная запись данных (bgwriter, backends);
* двойная буферизация между страничным кэшем ОС и общими буферами (shared_buffers) памяти Postgres;
* все операции на чтение данных являются синхронными (из страничного кэша ОС);
* большой размер shared_buffers может вызвать проблемы, когда таблицы очень часто удаляются или очищаются.

Об этом и не только я расскажу в своем докладе...

Доклад принят в программу конференции

В поисках идеального хранилища...

Душещипательная история о том как мы выбирали кластерную файловую систему для виртуальных машин и контейнеров, с какими трудностями столкнулись и почему остановили свой выбор на LINSTOR.

Доклад разделён на две части:

В первой частеи будет приведён краткий обзор других OpenSource-решиний, удачных и не очень, которые мы рассматривали, а некоторые из них даже дошли до production, но в последствии мы от них отказались.

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

Хранилище LINSTOR построено на свободных технологиях: ZFS, LVM, DRBD и ориентрировнно на максимальную производительность и высокую доступность данных.

В данном докладе я расскажу про наш опыт его использования в Kubernetes, Proxmox и OpenNebula:

• На наглядном примере посмотрим как оно работает и чем отличается от того же Ceph и других решений.
• Под какие цели стоит использовать LINSTOR, а когда его внедрение может быть нецелесобразным.
• Разберёмся как работает тонкая настройка и планирование ресурсов.
• Проблемы DRBD и их решения.

Программный комитет ещё не принял решения по этому докладу