1. Apache Cassandra Еще одно NoSQLхранилище

2. О чем будет идти речь? Пару слов про NoSQL Amazon Dynamo Google Big Table Cassandra снаружи Cassandra кассандра изнутри Наш опыт использования

4. NoSQL - WTF? Казалось бы, причем тут ЛужковSQL? Абсолютно не причем! SQL – просто язык запросов Под “SQL” понимают MySQL/InnoDB, MSSQL и аналоги (row oriented, b-tree индексы). NoSQL== No MySQL Некоторые из NoSQLхранилищ предоставляют SQL-синтаксис. Например, Apache Hive

5. CAP-теорема Consistency: в один момент времени, все клиенты видят один и тот же набор данных Availability: на каждый запрос будет дан ответ (включая сообщение об ошибке) Partition tolerance: система продолжает работать при нарушении связи между любыми двумя узлами Можно выбрать только два!

6. NoSQLхранилища – тысячи их! MongoDBтот же MySQL, только в профиль. Apache Hadoop: offline, MapReduce Google BigTable family: Hbase Amazon Dynamo: Riak Google BigTable + Amazon Dynamo= Apache Cassandra

7. Dynamo

8. Amazon Dynamo Описана в статье 2007-ого года Две операции: get(key), put(key, value) Область использования в Amazon: session management, shopping cart, etc Полная распределенность Отсутствует master node: клиент общается сразу со всеми серверами в кластере Ближайший родственник – DHT в BitTorrent

9. Token Ring

10. Replication

11. Запись Клиент не знает ничего о топологии кластера Команда на запись отправляется на произвольный сервер, который становится координатором данной операции Координатор записывает данные на нужные сервера Клиент выбирает критерий успешности записи Если одна из реплик недоступна, запись будет завершена позже

12. Чтение Команда на чтение оправляется произвольному серверу в кластере Сервер знает опрашивает нужные реплики Критерий успешности чтений (количество живых реплик) настраивается клиентом

13. BigTable

14. BigTable У каждой строки может быть индивидуальный набор колонок Схема данных отсутствует

15. Пример схемы данных Будем хранить список друзей в социальной сети Ключ – имя пользователя Колонка – тоже имя пользователя! Значение: 1/2/3 в зависимости от взаимности дружбы f(key, column_name) ->column_value – более удобное представление модели данных SELECT WHERE key >= start AND key <= end AND name<=maxColumn AND name<minColumn

16. Хранение данных

17. Данные внутри tablet server’а Memtable – данные, которые были добавлены недавно Memtableдублируется commit log’ом на диске SSTable – неизменяемая структура данных на диске с O(1) временем доступа к ключу Bloomfilterдля каждой SSTable SSTable compaction – переодическийmerge маленьких SSTable

18. Тандем BigTableи Dynamo

19. Что взяли из Dynamo Token ring Алгоритм записи/чтения

20. Что взяли из BigTable? Модель данных: key/column Локальную структуру данных на серверах Memtable/commit log – временное хранилище SSTable/Bloomfilter – постоянное хранилище SSTable compaction Вместо put/get доступны сложные запросы: SELECT WHERE key>=start AND key <= end AND columnName >= c1 AND columnName <= c2 Индексы!

21. Терминология Cassandra Cluster. Глобальные настройки: тип ключей, partitioning (ordered, md5), размер кэша, топология кластера Keyspace. Аналог в MySQL: база данных. Настройки уровня keyspace: replication factor Column family. Аналог в MySQL: таблица.размер кэша, индексы Super columns.

22. Super column Еще один уровень вложенности

23. Операции mutation(key, column, value) get(key, column) multi_get([k1, k2,…], column) get_slice(key, column_predicate). column_predicate: набор колонок или интервал get_range_slices(start_key, end_key, column_predicate) multi_get_slice Counters: add/remove(key, column)

24. Запись Команда идет на произвольный сервер в кластере. Сервер находит нужные реплики (ReplicationStrategy) Сервер сохраняет данные локально(Hinted handoff) Критерий успешности записи определяет клиент согласно настройки ConsistencyLevel

25. Репликация: один датацентр

26. Репликация: два датацентра

27. Запись: внутренности Memtable: хранилище новых записей. Настраиваемый flush-критерий (по таймауту, по размеру) Commit-log: дублирует memtableна случай падения сервера Memtable flush -> SSTable SSTable: data + index + bloomfilter SSTable compaction – борьба с фрагметнацией

28. Чтение Команду на чтение обрабатывает произвольный сервер Сервер определяет ближайшую реплику на основе настройки snitch: Simple, Topology, Dynamic Клиент определяет критерий успешности чтения Read repair (optional): убедится, что все реплики содержат свежие данные

29. Конфликты Каждое значение в колонке имеет timstamp Timestamp проставляется клиентом как текущее время Можно переопределить timestamp на любое 64-х битное число Клиент получает всегда последний timestamp

30. Кеширование запросов Key cache: кеширование позиции ключей внутри SSTable Row cache: кеширование ключей и их значений в памяти Принцип кеширования: LIFO. Настраивается для каждой column family отдельно Но! Кассандра использует mmapдля чтения файлов Настройки кеширования использовать не рекомендуется. Лучше полагаться на кеширование файловой системы

31. Индексы Secondary Indexes: на columns, но не на super columns! При полностью распределенной архитектуре сложно реализовать индексы Чтобы найти значение по индексу, нужно опросить все сервера Ограничение реализации: можно делать запросы только по строгому сравнению (SELECT … WHERE column>value– не поддерживается) Индексы сильно замедляют вставку данных Итого: индексы довольно бесполезная фича

32. Масштабирование: как добавить сервера в кластер? У каждого сервера есть операцияmove token. Можно переназначит token у любого сервера Топология кластера измениться, миграция данных будет происходить в фоне Пока миграция не закончена, сервер будет отвечать за старый кусок данных Аналогично будет отработана ситуация добавления нового сервера в token ring

33. Проще всего масштабироватьсяв 2 раза

34. Преимущества Быстрый write, особенно когда не нужна consistency Легкость в администрировании. Один daemon с одним конфигурационным файлом В HBase: четыре daemon’а на каждый сервер

35. Недостатки Плохо реализован range scan: кассандра не умеет передавать данные поточно. Слишком много настроек вынесено на cluster-level: вид и стратегия хранения ключей, и т.д. Compaction существенно замедляет запросы Протоколобщения между нодами: Thrift

36. Наш опыт Храним события в online рекламы: показы/клики/конверсии Типичный клиент: 1 миллиард событий в месяц, 100 миллионов уникальных пользователей (ключей) Ключ: ID пользователя. Имя колонки:ID события Вопрос N1: сколько уникальных пользователей было в каждом городе Вопрос N2: сколько уникальных пользователей видели баннер X, но не видели баннер Y; какое распределение таких пользователей по городам Вопрос N3: на какие объявления нажимал конкретный пользователь

37. Плюсы и минусы + Быстрая запись, группировка по пользователям во время записи + Нет проблемы дубликации данных - Плохо реализованный range scan - Нельзя выполнять логику прямо на серверах

38. Решение проблем Аггрегация данных на сервере. Опции: Hadoop/MapReduce, кастомное решение Минусы Hadoop: операционные расходы, возможность использовать лишь один column family как источник данных Свое решение: кастомный демон на каждом сервере (аналог map), финальная аггрегация на клиенте.

39. Наши цифры на тестовых данных Кластер: 3 x (m1.large EC2: 7.5Gb RAM, 2CPU) Скорость записи: 12тысяч событий в секунду Скорость чтения: 9 тысяч событий в секунду Объем данных: 600Gb за 1.5 месяца, 1.5 миллиарда событий (значений колонок), 100 миллионов ключей