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

1. Алексей Чумаков
achumakov@exadel.com
Skype: alexey.chumakov

2. Вкратце
• Немного о NoSQL вцелом
• Что такое Apache Cassandra и для чего она может
понадобиться
• Как она устроена изнутри
• Несколько примеров
• Нюансы...
• Администрирование

3. НЕМНОГО О NOSQL…

4. NoSQL. Зачем?

5. 
Join, group by, count начинают работать медленно
на больших объемах данных

BigData – данных много (не помещаются на один
сервер) и они все нужны

Необходима репликация данных между
датацентрами и их постоянная доступность
(availability)

Partitioning/sharding вручную не всегда удобен

А еще хотим гибкую схему данных...
NoSQL. Зачем?

6. Pull on Demand vs Push on Change

7. CAP-теорема
http://blog.nahurst.com/visual-guide-to-nosql-systems

8. ЧТО ТАКОЕ
APACHE CASSANDRA?

9. История
Организация
кластера
(consistent hashing),
hinted handoff, read
repair
Структура
данных
(SSTables),
timestamps
?

10. Распределенная и горизонтально масштабируемая
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

11. Добавление новых нодов
• Скачать и распаковать дистрибутив
• Настроить IP
• Указать seed nodes
• Запустить 

12. Что-то еще?
• Децентрализованная (кольцо, нет master node, нет
single point of failure)
• Репликация между нодами и дата-центрами
• Настраиваемая Consistency (Tunable Consistency)
• Низкий уровень вхождения в NoSQL благодаря
CQL (Cassandra Query Language)
• Поддержка Hadoop

13. И в чем подвох?
• Нет ACID транзакций
• Сложно гарантировать 100% consistency данных
• Нет сложных запросов (никаких like, join, group by)
• Схему данных приходится продумывать исходя из
будущих запросов, а не наоборот

14. Когда имеет смысл использовать Apache Cassandra?
• Количество операций записи больше, чем чтения
• Данные должны быть постоянно доступны для
чтения и записи, несмотря на потерю N нодов
• Анализ поведения пользователя
• Агрегаторы
• Мониторинг

15. Когда не нужна C*?
• Данные помещаются в память
• Данные помещаются на одном сервере
• Не предвидится серьезного роста объема данных
• Данные редко модифицируется и возможно
реализовать шардинг

16. КАК APACHE CASSANDRA
УСТРОЕНА ИЗНУТРИ?

17. Организация кластера

18. Запись в любой доступный нод кластера

19. Hinted Handoff

20. Read repair

21. Anti-entropy repair
• Что будет, если Coordinator Node умрет?
• Лучше запускать по расписанию
• bin/nodetool repair

22. Физическая организация данных
• Нет B-Trees
• Используются отсортированные в памяти таблицы
фиксированного размера (SSTables)
• SSTable последовательно записываются на диск, а
потом объеденяются в отдельном потоке
(compaction)
• При удалении физически ничего не меняется, а
ставится маркер (tombstone)

23. Физическая организация данных

24. ЛОГИЧЕСКАЯ СТРУКТУРА
ДАННЫХ
= Map<Key, Map<Column, Value>>

25. Map<Key, Map<Column, Value>>

26. При использовании CQL все очень похоже на RDBMS
CREATE TABLE order_events (
order_id ascii,
operation_time timestamp,
operation_type ascii,
waiter ascii,
changed_menu_items list<ascii>,
PRIMARY KEY (order_id, operation_time)
);

27. Но в действительности все немного не так...

28. Идемпотентность
• Повторная запись по тому же ключу c теми же
значениями ничего не меняет
• Insert == Update
INSERT INTO NerdMovies (movie, director, main_actor, year)
VALUES ('Serenity', 'Joss Whedon', 'Nathan Fillion', 2005);
UPDATE NerdMovies
SET director = 'Joss Whedon',
main_actor = 'Nathan Fillion',
year = 2005
WHERE movie = 'Serenity';

29. Распределенные счетчики
• Работают с той же скоростью, что и обычный
update
• Не идемпотентны
UPDATE UserActions
SET total = total + 2
WHERE user = B70DE1D0-9908-4AE3-BE34-5573E5B09F14 AND action = 'click';

30. НЕСКОЛЬКО ПРИМЕРОВ...

31. Нагрузочное тестирование Black Box

32. Данные для каждой транзакции
CREATE TABLE transactions (
transaction_id ascii,
transaction_data map<text, text>,
PRIMARY KEY (transaction_id)
);

33. Данные для каждой транзакции
CREATE TABLE transaction_metrics (
transaction_id ascii,
tr_type ascii,
time timestamp,
PRIMARY KEY (transaction_id, tr_type)
);

35. Статистика
CREATE TABLE transaction_count (
stat_id ascii,
time_string ascii,
ops_count counter,
PRIMARY KEY (detail_key, time_string)
)

37. А теперь получаем нужный нам промежуток
SELECT time_string, ops_count FROM transaction_count
WHERE stat_id = ‘B_REQ|20140510'
AND time > '2014051003' AND time <= '2014051015'

38. Что не стоит делать с C*?
• Пытаться создать очередь на ее основе
• Читать перед записью – в большинстве случаев
можно воспользоваться счетчиками или
идемпотентностью
• Писать все в один Wide Row или часто удалять
данные из него

39. НЮАНСЫ

40. Очень высокая загрузка CPU
• Слишком большой HEAP
• concurrent_reads/concurrent_writes
• native_transport_max_threads
• rpc_max_threads

41. Anti Entropy Repair
• nodetool repair
• Осбенно нужен в тех случаях, когда кластер
оказался перегружен

42. Amazon EBS volumes

43. Слишком Wide Rows
• Запись в Wide Row оказалась в 5 раз медленне,
чем в row с разными ключами
• Удаления из Wide Row требуют много памяти во
время compaction
(TombstoneOverwhelmingException)
• Все записи из Wide Row физически находятся на
одном ноде (и его репликах)

44. Синхронизация времени между нодами
• Время на нодах (даже в AWS) может быть
рассинхронизированно
• Timestamps оказываются неверными
• Данные в итоге тоже

45. Bugs
Баги есть!
...но правят их быстро

46. Администрирование
• Nodetool – command-line утилита, в которой есть
все (или почти все) для администрирования
кластера
• DataStax OpsCenter – красивый веб-интерфейс для
администрирования, есть Community Edition

47. Правильный выбор технологий
VS

48. Q & A