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

Лидеры рынка СУБД в сегменте крупных предприятий — Oracle, MS SQL, PostgreSQL, несмотря на то, что архитектура этих платформ складывалась больше трех десятилетий назад.

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

Умело установленный «точный» индекс может значительно ускорить целое семейство запросов с фильтрацией. Но когда нет возможности создать такой индекс и не остается ничего кроме сканирования всей таблицы, нас может выручить data skipping. С появлением нового колоночного движка в Tarantool в этом появилась необходимость, потому что индексы в нем менее эффективны, чем в строчном хранилище, и сканировать таблицу приходится чаще.

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

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

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

Авито постоянно растет, и по мере этого роста нам пришлось перевозить наши шардированные БД размером от 1 ТБ до 5 ТБ с больших и быстрых Bare Metal на маленькие и медленные K8s-коробочки до 300 ГБ. В докладе расскажу, как именно мы с этим справились и какие «подводные камни» встретились на пути.

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

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

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

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

Можно ли увеличить latency, добавив слой кеширования? Конечно, да. Ведь в облаках между нашим приложением и Valkey (опенсорсный форк Redis) будет сеть. А если мы решили горизонтально масштабироваться, то где гарантия, что мы выбрали лучший хост для выполнения наших запросов?

Посмотрим, что с этим делать. Обсудим, что случилось в Valkey 8.0 и 8.1 для улучшения latency (и почему это помогает). Разберемся, стоит ли переходить на valkey-only-клиенты, если наша цель — минимальные задержки выполнения запросов.

И заодно посмотрим, что нового с точки зрения улучшения latency в высоких перцентилях в rdsync (Open Source-тул для улучшения отказоустойчивости Valkey от Yandex Cloud).

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

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

В 2024 году Ozon полностью перенес свою инфраструктуру объектного хранилища на собственное решение S3-server Lusca. В докладе я расскажу, как мы выбирали хранилища индекса; думали, как реализовать strong consistency на eventual consistency базе; открывали для себя особенности фоновых процессов ScyllaDB и придумывали свои алгоритмы. А еще о том, как боролись с восстанием зомби на Хеллоуин и воскрешали терабайты данных.

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

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

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

Опыт кастомного подхода к шардированию PostgreSQL в ядре процессинга заказов Яндекс Такси. Как справляемся с нагрузками и строгими требования к доступности и latency. Как организация данных помогла реализовать простой и надежный механизм решардирования.

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

Мы обсудим:
* как векторный поиск улучшает ответы больших языковых моделей;
* принципы работы векторного поиска и его применение в YDB;
* основные проблемы и сложности при разработке векторного индекса;
* особенности и преимущества глобального синхронного индекса;
* стратегии масштабирования и оптимизации производительности;

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

Уже дважды на хайлоаде я рассказывал про наш опыт развертывания и управления распределенным S3-совместимым хранилищем на базе MinIO. Приятно, что доклады находят своих слушателей и вопросы мне в телеграм продолжают приходить до сих пор. Некоторе просят продолжения. Поэтому я решил сделать еще один доклад на эту тему, тем более, что наш опыт растет вместе с объемом места, которое занимает информация в нашем хранилище. Сейчас оно размещается в 4 ДЦ, включает в себя 12 нод и 300 дисков.

Итак, коротко о том, что я хочу рассказать в этом году.

1. Расширение хранилища.
Рано или поздно место заканчивается, и приходит время добавлять новые ноды и диски. В прошлый раз я рассказывал, как мы расширялись с 3 до 4 дата-центров, по сути, скопировав все данные, что съело много времени. В этот раз я расскажу, как мы добавляем новые ноды, дисковые полки и диски в них, соответственно. С одной стороны, казалось бы, тривиальная процедура, с другой, она представляет собой куда более сложный процесс, чем увеличение просто раздела на локальном диске.

2. Эффективность сжатия.
Я уже рассказывал, что MinIO поддерживает сжатие. Но насколько оно эффективно и как быстро работает? Красивые цифры и графики.

3. Быстродействие.
Расскажу, как клиентам удалось под 100% загрузить нам канал в одном из ДЦ, переливая данные с серверов в S3. При том, что для хранения мы используем обычные SAS-диски.

4. Стоимость.
Мы используем не просто SAS-диски. Мы используем б/у SAS-диски небольшого объема, но в большом количестве. Расскажу, как мы к этому пришли.

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

Часто при работе с графами требуются инструменты для быстрой аналитики, проверки гипотез и прототипирования алгоритмов с высокой производительностью. У таких задач часто нет высоких требований к частоте запросов, но если граф слишком большой для Python, результатом аналитики является сравнимый по размеру граф, а результаты нужны очень быстро, то не всегда и графовая БД является удобным решением. Альтернативой может быть хранение в S3 исходного графа свойств (LPG) и результатов аналитики.

Наша команда анализирует графы крупного размера (~1 млрд вершин, ~50 млрд ребер с историей изменений) в облачной инфраструктуре, мы быстро вычисляем метрики, где необходимо обработать большую часть графа (OLAP и Graphalytics) для фич и и точечных запросов для OLTP-сценариев аналитики. Например, PageRank рассчитываем за 25 минут, Jaccard — за 100 минут.

В докладе поделимся опытом работы с JanusGraph поверх Cassandra, DuckDB с расширением DuckPGQ и GraphScope. Расскажем о производительности решений для работы с графами в S3. Покажем результаты сравнения форматов хранения LPG: от Parguet и Iceberg до нового GraphAR от Alibaba, с обсуждением их преимуществ и ограничений в сценариях аналитики (OLAP и OLTP).

Доклад будет интересен исследователям и разработчикам Big Data, специалистам по графовой аналитике и архитекторам распределенных систем.

В процессе развития сервиса мы упирались в несколько проблем — ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть — мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду.

По роду деятельности мы занимаемся аналитикой товаров на маркетплейсах, собираем очень много данных. Например, на WildBerries размещено 110 млн товаров, для каждого товара мы зайдем в его карточку, запишем данные (как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель). Сохраним это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров — каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed-данных в ClickHouse.

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

История развития одного из самых высоконагруженных сервисов компании: как мы справлялись с кратным ростом нагрузки и данных без шардирования. И как не справлялись: аварии и деградации базы данных, приводившие к недоступности критичных бизнес-сценариев. Честно поговорим, какие ошибки в проектировании мы допустили, как исправили и на каком «волшебном слове» все работало, пока исправляли.

Сейчас в хранилище RUTUBE более 250 Пбайт и более 400 млн единиц видеоконтента. Архитектура хранилища была заложена еще до появления таких решений, как Ceph и Amazon S3, используется до сих пор и имеет ряд преимуществ перед коробочными решениями.

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

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

Как с помощью Debezium и Kafka настроить синхронизацию данных между географически распределенными узлами БД Postgres, а также как автоматизировать переключение между базами в случае отказа и минимизировать простой.

Что слушатель вынесет с доклада?
* Рабочий подход к реализации георезервирования PostgreSQL. Он успешно работает в продакшне для клиентского MDM у одного из крупнейших заказчиков.
* Пошаговое руководство по настройке Debezium, написанию sink-коннектора и адаптации Java-приложения для работы с несколькими базами.

В любом облаке встает задача о доставке пользовательского I/O из виртуальной машины в систему хранения. У себя в MWS мы сделали это с помощью SPDK (storage performance development kit).

В докладе мы расскажем о том, что SPDK из себя представляет и зачем его, вообще, использовать. Рассмотрим, какие концепты были приняты при его проектировании и как это влияет на разработку. Покажем, какую нагрузку мы от него ожидали и как получилось на самом деле. Углубимся в подход message passing'a, который используется при обработке I/O, и расскажем, что пришлось доработать, чтобы целевые показатели производительности были достигнуты в нашем случае.

В конце доклада решим, готов ли SPDK к использованию в production и стоит ли, вообще, за него браться.

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

Вопрос только, с какой СУБД это возможно. Требования известны:
* СУБД должна работа с 10К и большим количеством соединений на заурядном серверном оборудовании;
* СУБД должна работать как с диском, так и с данным в памяти;
* эффективность работы дисковой СУБД с данными из кэша должна быть сравнима с показателями in-memory-решений;
* СУБД должна уметь масштабироваться на оборудовании с большим числом ядер.

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

Предлагаем рассмотреть СУБД Сокол в озвученных обстоятельствах в сравнении с другими системами.

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