Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)
Download as PPTX, PDF3 likes2,133 views
Документ обсуждает Apache Cassandra как одно из NoSQL-хранилищ данных, сравнивая его с Amazon Dynamo и Google Bigtable. Он объясняет внутренние механизмы архитектуры, такие как memtable, SSTable и принцип репликации, а также достоинства и недостатки системы, включая высокий уровень записи и проблемы с диапазонным сканированием. Также описываются примеры использования Cassandra для хранения событий в сфере онлайн-рекламы и приводятся результаты тестирования производительности кластера.
![Операции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_sliceCounters: add/remove(key, column)](https://image.slidesharecdn.com/apachecassandra-nosql-111005041855-phpapp01/85/Apache-Cassandra-NoSQL-23-320.jpg)
Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)
- 1. Apache CassandraЕще одно NoSQLхранилище
- 2. О чем будет идти речь?Пару слов про NoSQLAmazon DynamoGoogle Big TableCassandra снаружи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, MapReduceGoogle BigTable family: HbaseAmazon Dynamo: RiakGoogle 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для каждой SSTableSSTable compaction – переодическийmerge маленьких SSTable
- 19. Что взяли из DynamoToken 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. Терминология CassandraCluster. Глобальные настройки: тип ключей, partitioning (ordered, md5), размер кэша, топология кластераKeyspace. Аналог в MySQL: база данных. Настройки уровня keyspace: replication factorColumn 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_sliceCounters: add/remove(key, column)
- 24. ЗаписьКоманда идет на произвольный сервер в кластере. Сервер находит нужные реплики (ReplicationStrategy)Сервер сохраняет данные локально(Hinted handoff)Критерий успешности записи определяет клиент согласно настройки ConsistencyLevel
- 27. Запись: внутренностиMemtable: хранилище новых записей. Настраиваемый flush-критерий (по таймауту, по размеру)Commit-log: дублирует memtableна случай падения сервераMemtable flush -> SSTableSSTable: data + index + bloomfilterSSTable compaction – борьба с фрагметнацией
- 28. ЧтениеКоманду на чтение обрабатывает произвольный серверСервер определяет ближайшую реплику на основе настройки snitch: Simple, Topology, DynamicКлиент определяет критерий успешности чтенияRead repair (optional): убедится, что все реплики содержат свежие данные
- 29. КонфликтыКаждое значение в колонке имеет timstampTimestamp проставляется клиентом как текущее времяМожно переопределить timestamp на любое 64-х битное числоКлиент получает всегда последний timestamp
- 30. Кеширование запросовKey cache: кеширование позиции ключей внутри SSTableRow 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 миллионов ключей