Доклады секции "Базы данных и системы хранения"

Хранение данных — это всегда боль, у которой может быть больше 50 оттенков: железо, кэш, гарантии, производительность, скорость восстановления при проблемах, удобство и так далее. Как бы решить большинство проблем, при этом получив что-то легко обслуживаемое да ещё бесплатно?

Поcмотрим на проверенную боем OpenZFS, почему её хочется использовать (кто сказал "деградация данных"?) и когда её использовать не стоит (ммм, zero copy в Copy-on-Write).

Также не забудем о людях — обсудим комьюнити, как ФС может пережить родную ОС и жить вне ядра.

Взгляд со стороны контрибьютора.

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

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

YTsaurus — основная платформа Яндекса для хранения и обработки больших данных, ad hoc-аналитики, построения ETL-задач и регулярных batch-процессов. Сегодня самый большой кластер YTsaurus содержит более 20К хостов различной конфигурации — от 4 до 24 дисков, суммарно более 180К дисков.

В докладе я расскажу, как мы управляем таким количеством дисков с минимальными операционными издержками. Затронем:
* политики размещения блобов, для достижения отказоустойчивости и производительности записи;
* защитные механизмы, для ограничения фоновых процессов при восстановлении erasure-реплик;
* способы изоляции разных классов IO-нагрузки в одном кластере;
* инструменты автоматизации и примеры проблем, с которыми мы сталкивались при их внедрении.

В рекламе Яндекса мы работаем со многими сложными сущностями, которые храним в базах данных.

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

Данные баннера нужно постоянно обновлять — они включаются, выключаются, обновляют какие-то свои данные, по ним пересчитываются эмбеддинги. Так что у нас потоковая обработка данных с результатом в виде актуального состояния данных баннеров в таблице (в YT).

Вроде все просто, какие тут могут быть проблемы? На самом деле проблемы ожидаемые, у нас же Highload, и, если работать с нашей таблицей с баннерами наивным способом, то будем создавать слишком большую нагрузку.

Наивный способ — это когда мы данные одного баннера храним в таблице в одной бинарной строке в сериализованном виде. А проблема с нагрузкой в том, что мы на каждое, даже очень маленькое изменение (допустим, изменилось 20 байт в состоянии), загружаем и пишем обратно все состояние (десятки килобайт).

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

Приходите, чтобы узнать новое, обсудить известное и поделиться своими идеями про работу с состояниями.

В Тинькофф тысячи сервисов, и все эти сервисы пишут логи. За сбор логов и метрик отвечает Sage — платформа мониторинга собственной разработки с Elasticsearch под капотом. Объемы логов постоянно росли и сейчас это 7 ПБ, а суммарное количество нод на 15 кластерах в двух ДЦ достигло 370 штук. На таких объемах вылезает много проблем: под нагрузкой кластеры могут разваливаться, встроенный ILM уже неудобен, да и сопровождать это непросто. В докладе автор расскажет, как эти проблемы были решены в Sage, а также поделится информацией о внутреннем устройстве Elastic.

1. Почему графы.
2. Бизнес-сценарий: цели, задачи и результаты.
3. Модели данных — "реляционка" против графа.
4. Области применения.
5. Наши планы по развитию.

Tarantool прошёл большой путь в репликации. Начиналось всё с master-replica без поддержки транзакций, затем появилась поддержка master-master, потом и поддержка транзакций. Одновременно с этим появились нереплицируемые таблицы. Последним нововведением стала синхронная репликация и автоматические выборы лидера.

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

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

В современном мире ни один средний или крупный IТ-проект и/или решение не обходится без аналитики. В высоконагруженных информационных системах с большим объемом данных это особенно актуально.

Аналитическая подсистема позволяет анализировать как данные, поступающие в реальном времени, так и исторические данные, диагностировать проблемы, выявлять тренды, строить прогнозы и планы на будущее, список можно продолжать бесконечно… Казалось бы, в чем тут проблема? Прикрути BI-систему и строй себе отчеты на оперативных данных. К сожалению, когда речь заходит про объемы данных, характерные для систем класса BigData, то это перестает работать и нужно строить отдельный аналитический кластер, который синхронизируется с оперативным хранилищем.

Почему не работает подход с единой СУБД при очень больших объемах данных и как сделать так, чтобы данные в аналитическом слое не отставали от оперативных и при этом не растерять эти данные по дороге, я расскажу в своем докладе.

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

На фоне роста данных за последние пару десятилетий на рынке сложилась интересная картина. С одной стороны, появляется множество решений поверх традиционных СУБД, и сами производители этих СУБД не стоят на месте, с другой стороны, появляются совершенно новые продукты.

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

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

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

В чем существенные отличия графовых СУБД, какие преимущества и новые методы они предлагают для аналитики, и почему будущее аналитики на Больших Данных может оказаться именно за графовыми СУБД?