Рейтинг@Mail.ru
Highload++ 2017 завершён!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

11-я ежегодная конференция для разработчиков highload-систем, которая соберет   2 700 участников из разных регионов России и мира. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

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

Cassandra для хранения метаданных: успехи и провалы
Базы данных и системы хранения

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

Руководитель разработки, разработчик, фанат Go, Python, DevOps и больших нагрузок. Руководил разработкой backend-сервисов в стартапе Qik, после его покупки продолжил работать в компаниях Skype и Microsoft. До этого участвовал в разработке и руководил созданием таких проектов, как: damochka.ru, delit.net, smotri.com. Андрей - автор open-source проектов aptly (https://github.com/smira/aptly), Redis Resharding Proxy (https://github.com/smira/redis-resharding-proxy) и txZMQ (https://github.com/smira/txZMQ). Автор мастер-класса "Разработка надёжных высоконагруженных систем" (http://smira.highload.ru/).

Тезисы

Мы разработали и поддерживаем экзабайтное облачное объектное хранилище (S3-совместимое), и нам необходимо сохранять метаданные объектов. Работа с метаданными сложнее работы с данными, т.к. необходимо поддерживать конкурентные операции по записи/удалению одного и того же объекта, версионирование и т.п. Наше хранилище поддерживает работу в режиме active-active через два дата-центра (eventual consistency), что дополнительно усложняет слой метаданных.

Cassandra была и остается идеальным решением с точки зрения архитектуры и модели данных. Я расскажу о нашем опыте работы с Cassandra c "нуля" (когда никто из нас никогда не работал с Cassandra в production) через хороший и плохой опыт к сегодняшнему пониманию Cassandra изнутри и снаружи.

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

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

Базы данных / другое
,
Организация доступа к базам данных, ORM, собственные драйвера
,
GO

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

Rambler's Top100