1. Класс!ная Cassandra
Олег Анастасьев
ведущий разработчик,
Одноклассники.ру

2. > 6 M онлайн
290 000 страниц/сек,
20 ms на страницу
>240 Гбит/сек
> 5 000 серверов в 4 ЦОД
99.9% java

3. Cassandra @
Оценки фото
Класс!
Архив сообщений
... и много других

4. Введение в Cassandra
( сильно упрощенное )

5. Cassandra
- Кластер, gossip - Масштабирование,
- Партиционирование по ключу 0 восстановление на ходу
- Высокая доступность
- Поддержка нескольких ЦОД - Не нужны бакапы
Строки токен(к) Строки токен(к)
192-... 0-63
R1
192 64
R3
Строки токен(к) Строки токен(к)
128-191 64-127
128
R2

6. Запись в кластер
0
THRIFT
Изменение
192 64
Hint
Storage
128

7. Запись в кластер
0
THRIFT
Изменение
192 64
Hint
Storage
128

8. Чтение из кластера
0
Данные
resolved
result
Хэш
192 64
Неправильный хэш
Read Repair
128

9. Column Family
Порядок
Таблица “Х”
Ключ name0:byte[] ... nameN:byte[]
byte[] value0:byte[] valueN:byte[]
timestamp0:long timestampN:long
Таблица “Х”
Ключ name0:byte[] ... nameK:byte[]
Порядок
...

10. Запись изнутри
Write (Key, Column) name value ts
Commit Log
Memtable
Flusher Thread
записывает
SSTable 1 SSTable 2 SSTable 3 SSTable 4
Compaction Thread Сортировка слиянием
SSTable 5
Запись на диск всегда последовательная!

11. Чтение изнутри
name value ts
часть данных 1
resolve
Memtable
часть 2
часть 3
SSTable 1 SSTable 4 SSTable 5
- get( Key, columnNames ... )
- slice( Key, from, to, count, direction )
- key_range( fromKey, toKey, count, slice(...) )

12. Анатомия SSTable
SSTable-5-Filter.db SSTable-5-Index.db SSTable-5-Data.db
Данные
Блум - фильтр Ключ => Смещение Строки и Колонки
“Строка, возможно, есть”
По-строчные
Всегда в ОЗУ блум фильтры и
индексы
для
длинных строк
Что дает: - НОЛЬ чтений с диска, если строки нет и вам повезло
- 1 чтение, если строки нет и не повезло
- 2 чтения с диска для маленьких строк
- 3 чтения - для больших

13. Разрешение конфликтов
SSTable “AccountStatements-3456” Memtable “AccountStatements”
RowKey = “Oleg_Anastasyev” RowKey = “Oleg_Anastasyev”
Column=”LV05HABA95142357516” Column=”LV05HABA95142357516”
vs
Value= $1,000,000 Value= $10
Какое состояние верно ?

14. Разрешение конфликтов
SSTable “AccStatements-3456” Memtable
RowKey = “Oleg_Anastasyev” RowKey = “Oleg_Anastasyev”
Column=”LV05HABA95142357516” Column=”LV05HABA95142357516”
vs
Value= $1,000,000 Value= $10
Timestamp = 13:00:05 Timestamp = 13:00:01
С более свежим timestamp
.

15. Потерянная модификация
$10
1. Читаем AccountStatement Key=”Oleg”
1. Читаем AccountStatement Key=”Oleg”
(получили $10, TS=12:00:00)
(получили $10, TS=12:00:00)
2. Взнос $1,000,000
3. Сохраняем Key=”Oleg”, 2. Снимаем $1
Value=$1,000,010
TS=12:00:01.000 3. Сохраняем Key=”Oleg”,
Value=$9
TS=12:00:01.005
$9

16. Итог таков
Преимущества: Недостатки:
• Высокая и стабильная скорость записи • Нет ACID, нет откатов
• Нет детектора конфликтов
• Очень быстрое чтение отсутсвующего ключа • NoSQL => нет JOIN
• Скорость чтения не зависит от объема О запросах думать зараннее
• Сортированные данные на диске Денормализация данных
• Нет 1 точки отказа
• Высокая доступность
• Масштабирование и восстановление данных на
ходу
• Резервное копирование не нужно
• Эффективная эксплуатация в нескольких ЦОД

17. Устали от теории ?

18. Классная задачка
Класс! 4256

19. Классная задачка
Класс! 4256 Вы и 4256

20. Классная задачка
Класс! 4256 Вы и 4256

21. Классная задачка
таблица
RefId:long RefType:byte UserId:long Created
9999999999 STATUS(2) 11111111111 11:00
запросы
– COUNT ( RefId,RefType=? ): 80% => 0 Вы и 4256
– EXISTS( RefId,RefType,UserId=? ): 98% => Нет
– RefId,RefType=? ORDER BY Created DESC -- кто классил ?

22. Классная задачка
таблица
RefId:long RefType:byte UserId:long Created
9999999999 STATUS(2) 11111111111 11:00
запросы
– COUNT ( RefId,RefType=? ): 80% => 0 Вы и 4256
– EXISTS( RefId,RefType,UserId=? ): 98% => Нет
– RefId,RefType=? ORDER BY Created DESC -- кто классил ?
как то скучно ...

23. Классная задача

24. Классная задача

25. Классная задача
x8

26. Классная проблема
таблица
RefId:long RefType:byte UserId:long Created
9999999999 STATUS(2) 11111111111 11:00
нагрузка 8х
– 16 миллиардов показов в день (~ 300 000/сек)
– 100 M класс!ов в день ( ~ 2500/сек )
– 2TB данных
новый запрос
– RefId,RefType=? ORDER BY ДрузьяСверху
длинный хвост
– 40% EXISTS(RefId,UserId) не кешируются в принципе

27. Классная проблема
уже есть:
– 8 SQL кластеров (без учета резерва)
– 12 кешей (увеличение количества большого эффекта не дает)
– И они близки к пределу по CPU, дисковым операциям
А мы хотим в 8 раз больше

28. Простые решения ?
• Добавить больше SQL
– Уже есть 8, доставляем до 32
– Дорого ( железо + лицензии MS)
– Добавление SQL - ручная офлайн работа
– Повторяем раз в полгода ( 64 => 128 =>256 )
– Ненадежно
• Добавить кешей
– Много NOT EXISTS + длинный хвост => LRU кеш не работает
– Значит нужно кешировать 100% Классов!
– 2TB ОЗУ не дешево
– ( и надо умножить на 2 или 3 для надежности )

29. Cassandra !
• Упираем на хорошее
– Дешевый NOT EXISTS ( отсекается Блум-фильтром )
– Простая структура
– Хвост хранится на дисках
– Удобное масштабирование
– Высокая доступность
• Не попадая в плохое
– Нет требований ACID
– Eventual Consistency приемлемо
– Класс!ы никогда не меняются
– У нас есть время для compaction

30. Класс!ная модель данных
LikeByRef Все класс!ы по сущности
LikeCount Счетчики отдельно
LikeByUser Мои класс!ы

31. Класс!ная модель данных
LikeByRef
Key Column Column Value Timestamp
Type+RefId userId:byte[8] <null> Created
– EXISTS ( Type,RefId=?, UserId=?) 98% calls => “NOT EXISTS”
– WHERE Type,RefId=? ORDER BY ДрузьяСверху LIMIT XX
Мы не хотим читать диск на этих запросах
...но Cassandra использует блум-фильтр только для отсечки строк

32. Колоночный блум-фильтр
• что делает
– Хранит пары (Key, Column name) прямо в SSTable *-Filter.db
• хорошо
– Полностью убрали чтения с диска на NOT EXISTS
– ... то есть 98% запросов идут только в память
– больше фильтр => меньше false positives
• плохо
– блум фильтры стали большими - сотни мегабайт
– .. GC Promotion Failures (так как были в одном long[])
– исправили (CASSANDRA-2466) в cassandra 1.0

33. Классная модель
LikeCount
Key Column Column Value Timestamp
Type+RefId nodeIp:byte[4] nodeCounter:int Created
– COUNT ( RefType,RefId=?) 80% calls => “NOT EXISTS”
Мы не хотим делать сетевые запросы если классов нет
...но Cassandra всегда это делает для RR или пострадает консистентность

34. и еще плохо
1. COUNT()
application server
2. EXISTS
cassandra
- DTO <-> hector <-> THRIFT <-> cassandra
- THRIFT медленный и неудобный
- Несконсистентные транзакции
- Дополнительная коммуникация из-за RR
- Кеш только LRU, некомпактный

35. классное решение
application server one-nio
odnoklassniki-like
cassandra
- Бакенд и Cassandra в той же JVM
- Бакенд в том же ринге
- Работает через one-nio транспорт

36. классное решение
• локальный доступ
– запросы COUNT(RefId), EXISTS(RefId,UserId)
проверяются по блум - фильтрам в памяти локальной ноды
• спец кеш счетчиков
– более компактный, off heap
– ... 40M элементов -> 1G RAM
– сохраняется на диск для быстрого старта
– учитывает длинный хвост

37. Кеш счетчиков
0
m
64
128

38. Кеш счетчиков
0
m
64
128

39. Кеш счетчиков
0
m
64
128

40. Кеш счетчиков
0
m * 50
m
64
m * 50
128

41. Кеш счетчиков
Фейковые
0 изменения
TS = TS
- при изменении
- на втором чтении
- повторить раз в 8 ч
m
64
128

42. профит
– 12 cassandra nodes ( вместо 8 SQLs + резерв + 12 кешей )
– более надежная: RF = 3, в каждом ЦОД по реплике
– более производительная ( 1M бизнес запросов/сек )
– более быстрая ( более чем в 10 раз, менее 1.5 мс в среднем )
– расширяемая (12 -> 24 -> 48 )
– быстрорастущая 8 TB, + 15 G в день

43. Интересно?
Можно узнать больше !
Odnoklassniki.ru
Интеграция с Odnoklassniki.ru
http://v.ok.ru
http://connect.ok.ru
one-nio
Cassandra
slideshare.net/m0nstermind/presentations
github.com/odnoklassniki/apache-cassandra
github.com/odnoklassniki/one-nio
cassandra.apache.org
Олег Анастасьев
oa@odnoklassniki.ru
odnoklassniki.ru/oa

44. Интересно?
connect.ok.ru
Можно узнать больше !