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

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

О чем будет идти речь?Пару слов про NoSQLAmazon DynamoGoogle Big TableCassandra снаружиCassandra кассандра изнутриНаш опыт использования

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

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

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

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

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

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

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

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

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

Тандем BigTableи Dynamo

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

Что взяли из 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Индексы!

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

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

Операции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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related Content

What's hot (20)

Viewers also liked (20)

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

More from Ontico (20)

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