Асинхронный транспорт Cassandra

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

СУБД / DataLake / Хранимки

Java
Бэкенд / другое
Базы данных / другое
Организация доступа к базам данных, ORM, собственные драйвера
Асинхронное программирование, реактивное программирование
Оптимизация производительности
Распределенные системы
Архитектура данных, потоки данных, версионирование
Хранилища
Расширение кругозора

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

Мнение Программного комитета о докладе

Целевая аудитория

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

Тезисы

Cassandra является основным хранилищем (мета)данных в Одноклассниках. У нас развёрнуты сотни высоконагруженных кластеров из сотен узлов и тысяч клиентов, распределённых по нескольким дата-центрам. Мы используем и активно развиваем собственный форк Cassandra 2.x. Помимо фиксов множества багов и многочисленных оптимизаций, мы реализовали глобальные индексы (которые работают), поддержали партиционированные транзакции (NewSQL), полностью автоматизировали эксплуатацию в production и многое другое. Но в этом докладе мы сконцентрируемся на подходе FatClient, который используется в наших системах повсеместно.

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

В докладе мы подробно рассмотрим собственную реализацию асинхронного транспорта Cassandra, которая позволила нам существенно сэкономить ресурсы и упростить жизнь разработчиков. Новый транспорт основан исключительно на Java SDK и лаконичной, но эффективной реализации Actor Model. Помимо устройства нашего решения, поговорим про различные оптимизации, возникшие по пути проблемы, а также переключение на асинхронный транспорт нагруженных кластеров Cassandra в production.

Начал свой путь в IT/CS в 2004 с создания систем гидроакустики и исследовательских проектов по статическому анализу кода на C/C++. Потом переключился на распределённые системы и разрабатывал высоконагруженные распределённые сервисы на Java/Scala в Яндексе, затем в Платформе Одноклассников, а теперь и в VK. Сейчас в роли главного инженера технологической платформы VK продолжает распределенное дело. Попутно преподаёт NoSQL базы данных и высоконагруженные системы в VK Education.

VK

Развивает сервисы, которые помогают миллионам людей решать повседневные задачи онлайн

Видео

Другие доклады секции

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