Downloaded 62 times
![Операции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)
![Операции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/75/Apache-Cassandra-NoSQL-23-2048.jpg)
Uploaded byOntico
Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)
Документ обсуждает Apache Cassandra как одно из NoSQL-хранилищ данных, сравнивая его с Amazon Dynamo и Google Bigtable. Он объясняет внутренние механизмы архитектуры, такие как memtable, SSTable и принцип репликации, а также достоинства и недостатки системы, включая высокий уровень записи и проблемы с диапазонным сканированием. Также описываются примеры использования Cassandra для хранения событий в сфере онлайн-рекламы и приводятся результаты тестирования производительности кластера.
More Related Content
Similar to Apache Cassandra. Ещё одно NoSQL хранилище (Владимир Климонтович)
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.
- 8. Amazon DynamoОписана встатье 2007-ого годаДве операции: get(key), put(key, value)Область использования в Amazon: session management, shopping cart, etcПолная распределенностьОтсутствует master node: клиент общается сразу со всеми серверами в кластереБлижайший родственник – DHT в BitTorrent
- 9.
- 10.
- 11. ЗаписьКлиент не знаетничего о топологии кластераКоманда на запись отправляется на произвольный сервер, который становится координатором данной операцииКоординатор записывает данные на нужные сервераКлиент выбирает критерий успешности записиЕсли одна из реплик недоступна, запись будет завершена позже
- 12. ЧтениеКоманда на чтениеоправляется произвольному серверу в кластереСервер знает опрашивает нужные репликиКритерий успешности чтений (количество живых реплик) настраивается клиентом
- 13.
- 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. Данные внутри tabletserver’аMemtable – данные, которые были добавлены недавноMemtableдублируется commit log’ом на дискеSSTable – неизменяемая структура данных на диске с O(1) временем доступа к ключуBloomfilterдля каждой SSTableSSTable compaction – переодическийmerge маленьких SSTable
- 18.
- 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
- 25.
- 26.
- 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.
- 34. ПреимуществаБыстрый write, особеннокогда не нужна consistencyЛегкость в администрировании. Один daemon с одним конфигурационным файломВ HBase: четыре daemon’а на каждый сервер
- 35. НедостаткиПлохо реализован rangescan: кассандра не умеет передавать данные поточно.Слишком много настроек вынесено на 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 миллионов ключей