Cassandra для хранения метаданных: успехи и провалы / Андрей Смирнов (Virtustream)

Cassandra для
хранения метаданных:
успехи и провалы
Андрей Смирнов, Virtustream

Пару слов о себе…
Principal SoDware Engineer at Virtustream
Полностью удаленная команда
Virtustream: облако для enterprise

Virtustream Storage Cloud
Region: us
Site A
Site B
async 
replica2on
DNS 
Load Balancer
Customer
S3-compa2ble 
API

AcRve-AcRve
Перенаправление операций в “ближайший” ДЦ
Доступность данных при отказе ДЦ
Чтение и запись при отказе ДЦ или потере связности

Object
Data 
 
001110110011010101 
101010101010101100 
10101111011011011…
immutable
Metadata 
 
owner: user1 
size: 3456 
acl: private 
…
mutable, 
business logic

Цифры
Данные: 4 Пбайта
Кластеры метаданных: 3
Объекты: 40 миллиардов
Объем метаданных: 160 Тбайт (с учетом репликации)
Скорость изменений (метаданных): 3000 объектов/с

Выбор хранилища для метаданных
Поддержка acRve-acRve
Масштабируемость
Баланс отказоустойчивости и надежности хранения
Настраиваемая консистентность операций

Cassandra
Локальное KV-хранилище на каждом узле
Шардирование данных по узлам (consistent hashing)
Координатор для перенаправления запросов к другим узлам

Стадии познания
время

Хорошее
Время отклика в миллисекундах
Высокая масштабируемость по записи
Отказоустойчивость
Простота

! Потеря объектов
Худший день в истории сервиса или почему уровень
консистентности так важен

Схема хранения объектов
bucket key current_version
backup2017 01/03/data.tar.gz 135
backup2017 01/04/data.tar.gz
photos IMG_0175.JPG 149
objects
object_versions
bucket key version locaRon metadata
backup2017 01/03/data.tar.gz 134 421343dc owner: X, …
backup2017 01/03/data.tar.gz 135 76fa9949 owner: X, …
backup2017 01/04/data.tar.gz 278 4e7ab0d4 owner: X, …
photos IMG_0175.JPG 149 1a2058a6 owner: Y, …

Очистка ненужных версий
photos IMG_0175.JPG 149
objects
object_versions
backup2017 01/03/data.tar.gz 134 421343dc owner: X, …
backup2017 01/03/data.tar.gz 135 76fa9949 owner: X, …
backup2017 01/04/data.tar.gz 278 4e7ab0d4 owner: X, …
photos IMG_0175.JPG 149 1a2058a6 owner: Y, …

Беда пришла незаметно…
Site A Site B
асинхронная репликация
очистка
LOCAL_QUORUM LOCAL_QUORUM LOCAL_QUORUM
3 реплики 3 реплики+

backup2017 01/03/data.tar.gz 135 76fa9949 owner: X
backup2017 01/03/data.tar.gz 135 76fa9949 owner: X
Site A
Site B

💡Решение
Consistency ALL:
очень медленно
зависимость от доступности всех узлов
зато сразу read-repair

# Зомби
Зачем нужны tombstone или почему надо делать 
регулярный repair кластера

Удаление в Cassandra
1 2 3 4 5 6
XX X X X X

1 2 3 4 5 6
X

1 2 3 4 5 6
X
X

1 2 3 4 5 6
XX X X X X
X

Tombstone
Удаление == запись
Tombstone имеет маленький размер
Tombstone удаляется через gc_grace_period секунд

💡Решение
Repair по расписанию, автоматизация процесса
gc_grace_period > интервала repair

$ Large parRRon
Как сохранить отсортированный список ключей заранее
неизвестной структуры, не убив при этом Cassandra

Список объектов в бакете
objects
SELECT * FROM objects WHERE bucket = ?

Список объектов в бакете
objects
primary key
SELECT * FROM objects WHERE bucket = ?

bucket key metadata
backup2017 01/03/data.tar.gz size: 1455, …
bucket_contents
composite key
primary key

bucket key metadata
bucket_contents
composite key
primary key
SELECT * FROM bucket_contents  
WHERE bucket = ? AND key > ? ORDER BY key

bucket key metadata
bucket_contents

bucket key metadata
bucket_contents
bucket key: 01/03/data.tar.gz key: 01/04/data.tar.gz key: 02/01/data.tar.gz …
backup2017 size: 1455, … size: 1459, … size: 1570, … …
на самом деле:
ширина = размер бакета

bucket key metadata
bucket_contents
bucket key: 01/03/data.tar.gz key: 01/04/data.tar.gz key: 02/01/data.tar.gz …
backup2017 size: 1455, … size: 1459, … size: 1570, … …
на самом деле:
ширина = размер бакета
LARGE PARTITION!

Хеширование
bucket + key_hash - партиция:
размер партиции должен быть ограничен сверху
возможность быстро получить отсортированный список ключей
bucket key_hash key metadata
backup2017 ? 01/03/data.tar.gz size: 1455, …
bucket_contents
primary key

Статическое хеширование: hash
bucket key_hash key
backup2017 0 …
backup2017 1 …
backup2017 … …
backup2017 N-1 …
key hash
Как выбрать N? Как его изменить?
Выборка отсортированного списка - запрос ко всем key_hash

Статическое хеширование: префикс
Как угадать распределение ключей в бакете?
Сколько символов в префиксе?
bucket key_hash key
backup2017 A Aa, Ab, Ac, …
backup2017 B Ba, Bb, Bc, …
backup2017 … …
backup2017 Z Za, Zb, Zc, …
key LEFT(x, 1)

Динамическое распределение
bucket key_hash key
backup2017 4 …
backup2017 7 …
backup2017 … …
backup2017 3123 …
key DT
bucket keys key_hash
backup2017 [‘’, ‘A1’) 33
backup2017 [‘A1’, ‘Ca5’) 48
backup2017 … …
backup2017 [‘ZZa1’, ∞) 11
distribu2on_table:

Динамическое хеширование
Динамическая таблица распределения
Генетический алгоритм для поиска идеального распределения и
идеального перераспределения
Подсчет размера патриции вне Cassandra
Online-перераспределение (без остановки операций и потери
консистентности)

💡Решение
Никогда, никогда не допускайте появления large par22on
Разбивайте данные по primary key в зависимости от задачи

%Проблемы производительности
Почему узлы Cassandra на самом деле не совсем независимы или
почему нужна детальная статистика на уровне узла (таблицы)

Сложности интерпретации
Время отклика координатора (сам узел vs. реплики)
Конкретная таблица или весь узел?
GC Pause? Недостачный Thread Pool?
Слишком много uncompacted SSTables?

Понимание контекста
Работает ли repair?
Замена/добавление узла? Streaming?
Проблемы с “железом”?
Проблемы JVM?

💡Решение
Детальный мониторинг как со стороны кластера, так и со стороны
приложения
Тюнинг JVM (бесконечный процесс)
Избегать large parRRon, batch, condiRonal update, …

&«Испорченные» данные
Про то, как Cassandra испортила данные, а мы искали иголку в
стоге сена (и нашли)

Проблема
Примерно раз в неделю…
несколько десятков испорченных строк (мусор)…
которые невозможно прочитать

Поиски
Общий узел

Поиски
Общий узел
Плохой диск

Поиски
Общий узел
Плохая память

Поиски
Общий узел
Проблема репликации

Поиски
Общий узел
Проблема приложения

Поиски
Общий узел
Общий узел

Иголка нашлась!
Хм… а почему JVM crash dump?
А почему в stack trace часто есть G1GC?
А что за версию JVM мы используем? Из 2015 г.? 🤦

Восстановление данных
Backup не поможет
Частичное восстановление неповрежденных колонок
Восстановление из разных источников
Логи - это бесценно!

💡Решение
Обновляйте JVM после длительного тестирования
Мониторинг JVM сrash
Имейте независимую от Cassandra копию данных

🐞Баги
Низкое качество тестирования релизов

🐞Баги
Постоянные проблемы со сложными фичами

🐞Баги
… не используйте инкрементальный repair в 2.1 🤦

🐞Баги
… не используйте инкрементальный repair в 3.x 🤦 🤦 🤦

🐞Баги
… не используйте инкрементальный repair в 3.x 🤦 🤦 🤦
Надо следить за JIRA

Предсказуемость
PostgreSQL Redis
предсказуемонепредсказуемо
MySQLCassandra

Cassandra - это хорошо и нескучно!
Только помните о кочках на дороге!

Cassandra для хранения метаданных: успехи и провалы / Андрей Смирнов (Virtustream)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Cassandra для хранения метаданных: успехи и провалы / Андрей Смирнов (Virtustream)

Similar a Cassandra для хранения метаданных: успехи и провалы / Андрей Смирнов (Virtustream) (20)

Más de Ontico

Más de Ontico (20)

Cassandra для хранения метаданных: успехи и провалы / Андрей Смирнов (Virtustream)