2. Вкратце
• Немного о NoSQL вцелом
• Что такое Apache Cassandra и для чего она может
понадобиться
• Как она устроена изнутри
• Несколько примеров
• Нюансы...
• Администрирование
5.
Join, group by, count начинают работать медленно
на больших объемах данных
BigData – данных много (не помещаются на один
сервер) и они все нужны
Необходима репликация данных между
датацентрами и их постоянная доступность
(availability)
Partitioning/sharding вручную не всегда удобен
А еще хотим гибкую схему данных...
NoSQL. Зачем?
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*?
• Данные помещаются в память
• Данные помещаются на одном сервере
• Не предвидится серьезного роста объема данных
• Данные редко модифицируется и возможно
реализовать шардинг
21. Anti-entropy repair
• Что будет, если Coordinator Node умрет?
• Лучше запускать по расписанию
• bin/nodetool repair
22. Физическая организация данных
• Нет B-Trees
• Используются отсортированные в памяти таблицы
фиксированного размера (SSTables)
• SSTable последовательно записываются на диск, а
потом объеденяются в отдельном потоке
(compaction)
• При удалении физически ничего не меняется, а
ставится маркер (tombstone)
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';
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)
);
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 или часто удалять
данные из него
43. Слишком Wide Rows
• Запись в Wide Row оказалась в 5 раз медленне,
чем в row с разными ключами
• Удаления из Wide Row требуют много памяти во
время compaction
(TombstoneOverwhelmingException)
• Все записи из Wide Row физически находятся на
одном ноде (и его репликах)
44. Синхронизация времени между нодами
• Время на нодах (даже в AWS) может быть
рассинхронизированно
• Timestamps оказываются неверными
• Данные в итоге тоже
46. Администрирование
• Nodetool – command-line утилита, в которой есть
все (или почти все) для администрирования
кластера
• DataStax OpsCenter – красивый веб-интерфейс для
администрирования, есть Community Edition