Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)

3,874 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,874
On SlideShare
0
From Embeds
0
Number of Embeds
751
Actions
Shares
0
Downloads
57
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)

  1. 1. Apache Cassandra<br />Еще одно NoSQLхранилище<br />
  2. 2. О чем будет идти речь?<br />Пару слов про NoSQL<br />Amazon Dynamo<br />Google Big Table<br />Cassandra снаружи<br />Cassandra кассандра изнутри<br />Наш опыт использования<br />
  3. 3.
  4. 4. NoSQL - WTF?<br />Казалось бы, причем тут ЛужковSQL?<br />Абсолютно не причем! SQL – просто язык запросов<br />Под “SQL” понимают MySQL/InnoDB, MSSQL и аналоги (row oriented, b-tree индексы).<br />NoSQL== No MySQL<br />Некоторые из NoSQLхранилищ предоставляют SQL-синтаксис. Например, Apache Hive<br />
  5. 5. CAP-теорема<br />Consistency: в один момент времени, все клиенты видят один и тот же набор данных<br />Availability: на каждый запрос будет дан ответ (включая сообщение об ошибке)<br />Partition tolerance: система продолжает работать при нарушении связи между любыми двумя узлами<br />Можно выбрать только два!<br />
  6. 6. NoSQLхранилища – тысячи их!<br />MongoDBтот же MySQL, только в профиль. <br />Apache Hadoop: offline, MapReduce<br />Google BigTable family: Hbase<br />Amazon Dynamo: Riak<br />Google BigTable + Amazon Dynamo= Apache Cassandra<br />
  7. 7. Dynamo<br />
  8. 8. Amazon Dynamo<br />Описана в статье 2007-ого года<br />Две операции: get(key), put(key, value)<br />Область использования в Amazon: session management, shopping cart, etc<br />Полная распределенность<br />Отсутствует master node: клиент общается сразу со всеми серверами в кластере<br />Ближайший родственник – DHT в BitTorrent<br />
  9. 9. Token Ring<br />
  10. 10. Replication<br />
  11. 11. Запись<br />Клиент не знает ничего о топологии кластера<br />Команда на запись отправляется на произвольный сервер, который становится координатором данной операции<br />Координатор записывает данные на нужные сервера<br />Клиент выбирает критерий успешности записи<br />Если одна из реплик недоступна, запись будет завершена позже<br />
  12. 12. Чтение<br />Команда на чтение оправляется произвольному серверу в кластере<br />Сервер знает опрашивает нужные реплики<br />Критерий успешности чтений (количество живых реплик) настраивается клиентом <br />
  13. 13. BigTable<br />
  14. 14. BigTable<br />У каждой строки может быть индивидуальный набор колонок<br />Схема данных отсутствует<br />
  15. 15. Пример схемы данных<br />Будем хранить список друзей в социальной сети<br />Ключ – имя пользователя<br />Колонка – тоже имя пользователя!<br />Значение: 1/2/3 в зависимости от взаимности дружбы<br />f(key, column_name) ->column_value – более удобное представление модели данных<br />SELECT WHERE key >= start AND key <= end AND name<=maxColumn AND name<minColumn<br />
  16. 16. Хранение данных<br />
  17. 17. Данные внутри tablet server’а<br />Memtable – данные, которые были добавлены недавно<br />Memtableдублируется commit log’ом на диске<br />SSTable – неизменяемая структура данных на диске с O(1) временем доступа к ключу<br />Bloomfilterдля каждой SSTable<br />SSTable compaction – переодическийmerge маленьких SSTable<br />
  18. 18. Тандем BigTableи Dynamo<br />
  19. 19. Что взяли из Dynamo<br />Token ring<br />Алгоритм записи/чтения<br />
  20. 20. Что взяли из BigTable?<br />Модель данных: key/column<br />Локальную структуру данных на серверах<br />Memtable/commit log – временное хранилище<br />SSTable/Bloomfilter – постоянное хранилище<br />SSTable compaction<br />Вместо put/get доступны сложные запросы: SELECT WHERE key>=start AND key <= end AND columnName >= c1 AND columnName <= c2<br />Индексы!<br />
  21. 21. Терминология Cassandra<br />Cluster. Глобальные настройки: тип ключей, partitioning (ordered, md5), размер кэша, топология кластера<br />Keyspace. Аналог в MySQL: база данных. Настройки уровня keyspace: replication factor<br />Column family. Аналог в MySQL: таблица.размер кэша, индексы<br />Super columns.<br />
  22. 22. Super column<br />Еще один уровень вложенности<br />
  23. 23. Операции<br />mutation(key, column, value)<br /> get(key, column)<br />multi_get([k1, k2,…], column)<br />get_slice(key, column_predicate). column_predicate: набор колонок или интервал<br />get_range_slices(start_key, end_key, column_predicate)<br />multi_get_slice<br />Counters: add/remove(key, column)<br />
  24. 24. Запись<br />Команда идет на произвольный сервер в кластере. Сервер находит нужные реплики (ReplicationStrategy)<br />Сервер сохраняет данные локально(Hinted handoff)<br />Критерий успешности записи определяет клиент согласно настройки ConsistencyLevel<br />
  25. 25. Репликация: один датацентр<br />
  26. 26. Репликация: два датацентра<br />
  27. 27. Запись: внутренности<br />Memtable: хранилище новых записей. Настраиваемый flush-критерий (по таймауту, по размеру)<br />Commit-log: дублирует memtableна случай падения сервера<br />Memtable flush -> SSTable<br />SSTable: data + index + bloomfilter<br />SSTable compaction – борьба с фрагметнацией<br />
  28. 28. Чтение<br />Команду на чтение обрабатывает произвольный сервер<br />Сервер определяет ближайшую реплику на основе настройки snitch: Simple, Topology, Dynamic<br />Клиент определяет критерий успешности чтения<br />Read repair (optional): убедится, что все реплики содержат свежие данные<br />
  29. 29. Конфликты<br />Каждое значение в колонке имеет timstamp<br />Timestamp проставляется клиентом как текущее время<br />Можно переопределить timestamp на любое 64-х битное число<br />Клиент получает всегда последний timestamp<br />
  30. 30. Кеширование запросов<br />Key cache: кеширование позиции ключей внутри SSTable<br />Row cache: кеширование ключей и их значений в памяти<br />Принцип кеширования: LIFO. Настраивается для каждой column family отдельно<br />Но! Кассандра использует mmapдля чтения файлов<br />Настройки кеширования использовать не рекомендуется. Лучше полагаться на кеширование файловой системы<br />
  31. 31. Индексы<br />Secondary Indexes: на columns, но не на super columns!<br />При полностью распределенной архитектуре сложно реализовать индексы<br />Чтобы найти значение по индексу, нужно опросить все сервера<br />Ограничение реализации: можно делать запросы только по строгому сравнению (SELECT … WHERE column>value– не поддерживается)<br />Индексы сильно замедляют вставку данных<br />Итого: индексы довольно бесполезная фича<br />
  32. 32. Масштабирование: как добавить сервера в кластер?<br />У каждого сервера есть операцияmove token. Можно переназначит token у любого сервера<br />Топология кластера измениться, миграция данных будет происходить в фоне<br />Пока миграция не закончена, сервер будет отвечать за старый кусок данных<br />Аналогично будет отработана ситуация добавления нового сервера в token ring<br />
  33. 33. Проще всего масштабироватьсяв 2 раза<br />
  34. 34. Преимущества<br />Быстрый write, особенно когда не нужна consistency<br />Легкость в администрировании. Один daemon с одним конфигурационным файлом<br />В HBase: четыре daemon’а на каждый сервер<br />
  35. 35. Недостатки<br />Плохо реализован range scan: кассандра не умеет передавать данные поточно.<br />Слишком много настроек вынесено на cluster-level: вид и стратегия хранения ключей, и т.д.<br />Compaction существенно замедляет запросы<br />Протоколобщения между нодами: Thrift<br />
  36. 36. Наш опыт<br />Храним события в online рекламы: показы/клики/конверсии<br />Типичный клиент: 1 миллиард событий в месяц, 100 миллионов уникальных пользователей (ключей)<br />Ключ: ID пользователя. Имя колонки:ID события<br />Вопрос N1: сколько уникальных пользователей было в каждом городе<br />Вопрос N2: сколько уникальных пользователей видели баннер X, но не видели баннер Y; какое распределение таких пользователей по городам<br />Вопрос N3: на какие объявления нажимал конкретный пользователь<br />
  37. 37. Плюсы и минусы<br />+ Быстрая запись, группировка по пользователям во время записи<br />+ Нет проблемы дубликации данных<br />- Плохо реализованный range scan<br />- Нельзя выполнять логику прямо на серверах<br />
  38. 38. Решение проблем<br />Аггрегация данных на сервере. Опции: Hadoop/MapReduce, кастомное решение<br />Минусы Hadoop: операционные расходы, возможность использовать лишь один column family как источник данных<br />Свое решение: кастомный демон на каждом сервере (аналог map), финальная аггрегация на клиенте.<br />
  39. 39. Наши цифры на тестовых данных<br />Кластер: 3 x (m1.large EC2: 7.5Gb RAM, 2CPU)<br />Скорость записи: 12тысяч событий в секунду<br />Скорость чтения: 9 тысяч событий в секунду<br />Объем данных: 600Gb за 1.5 месяца, 1.5 миллиарда событий (значений колонок), 100 миллионов ключей<br />

×