Введение в Apache Cassandra

Введение в Apache
Cassandra

Александр Тивельков
Mirantis Cloud Service
© MIRANTIS 2013 PAGE 1

«Без умолку безумная девица
Кричала: "Ясно вижу Трою павшей в прах!"
Но ясновидцев - впрочем, как и очевидцев -
Во все века сжигали люди на кострах»
В. Высоцкий. Песня о вещей Кассандре

«...Он у Приама Кассандры, прекраснейшей дочери старца,
Гордый просил без даров, но сам совершить обещал он
Подвиг великий: из Трои изгнать меднолатных данаев.
Старец ему обещал и уже за него согласился
Выдать Кассандру,- и ратовал он, на обет положася»
Гомер. Иллиада


О чем вообще речь?

800

700

600

500

400 Объем данных в сети, ЭБ

300

200

100

0
1998 2000 2002 2004 2006 2008 2010 2012 2014


Масштабирование


Бывает и так


NoSQL

 HBase  Hypertable
 MongoDB  HyperGraphDB
 Riak  Memcached
 Voldemort  Tokyo Cabinet
 Neo4J  Redis
Cassandra
CouchDB




CAP-теорема Брюера


NoSQLBigData

 HBase  Hypertable
 MongoDB  HyperGraphDB
 Riak  Memcached
 Voldemort  Tokyo Cabinet
 Neo4J  Redis
Cassandra
CouchDB




Amazon Dynamo + Google BigTable = ???

Из Amazon Dynamo возьмем
инфраструктуру:
 Согласованное хэширование
PK
 Шардирование
...а из Google BigTable оставим
Репликацию по кольцу
схему данных:


Роутинг за О(1)
Схему данных, состоящую из


«семейств колонок»
In-memory хранение данных в
Memtable
On-disk хранение данных в
SSTables


Amazon Dynamo + Google BigTable = Apache Cassandra

 Разрабатывалась в Facebook до 2008го года
 Выпущена в свободное open-source плавание на
GoogleCode в июле 2008 года
 С марта 2009 года — в инкубаторе проектов Apache
Software Foundation
 Выделение в полноценный продукт — 17 февраля 2010
 6 основных релизов с тех пор...

Последний активный релиз — 2 января 2013 года, версия 1.2


Apache Cassandra – это...
Распределенное,
отказоустойчивое,
масштабируемое,
колонко-ориентированное,
управляемо-согласованное

хранилище данных.


Топология Token Ring

 Кластер из проивольного количества узлов (ну, от 1 до 2127-1 :))

 Каждому узлу сопоставляется токен в некоем пространстве
значений

 Хэш-ключ записи лежит в том же пространстве значений
токенов

 Запись направляется на ноду с ближайшим к этому значению
токеном

 Последующая репликация поддается настройке и учитывает
сетевую топологию кластера


Топология Token Ring


Отказоустойчивость

 Все узлы равны — нету «главной
ноды», «управляющей ноды», «мастер-узла» и
прочих Single-point-of-failure

 При выбывании ноды перебалансировка кольца
происходит так, чтобы минимизировать
перемещение данных

 Функция Read-Repair позволяет восстановить
устаревшие данные после возвращения ноды в
строй при наличии достаточного количества реплик


Мсштабируем

• Горизонтально
• Легко и просто
• Автоматизированно


Модель данных
 Нет фиксированной схемы
 ALTER TABLE? Забудьте как страшный сон
 Разреженные (sparse) таблицы — у каждой строки
свой набор колонок
 Имена колонок — любого типа данных, в том числе
композитные
 Всѐ что нужно выбрать — порядок сортировки
колонок в «таблице»



 Keyspace

 ColumnFamily
 Row
 Ключ
 Колонка
 Имя
 Значение
 Колонка
…
… © MIRANTIS 2013 PAGE 23


• Ячейка



• Ячейка

• Строка



• Ячейка

• Строка

• Column Family


Запись данных

• Данные сохраняются в in-memory структуру данных —
memtable — и в commit log на диск

• Периодически memtable сохраняется на диск в SSTable файл
(SortedStringsTable). Commit log при этом очищается.

• SSTable — immutable, т. е. каждая операция flush создает
новый файл


Запись данных


Чтение данных

 Данные читаются и из memtable (из памяти), и с диска (из
SSTable-файлов)

 Так как SSTable-файл являются immutable, то различные
колонки одной строки могут находиться в разных файлах

 Существуют несколько механизмов кэширования и
дополнительной индексации


Чтение данных


Совсем без "С" – плохо


Eventual Consistency
Невозможно гарантировать, что непосредственно после
завершения обновления данных операция чтения вернѐт
обновленное значение.
Гарантируется, что при отсутствии повторных обновлений через
некоторое время данный станут доступны.
Окно несогласованности(inconsistency window) -
время, проходящее между операцией обновления и
доступностью обновленных данных для чтения.

Задача: минимизировать окно несогласованности при
минимальных жертвах со стороны доступности и устойчивости к
потере связи между сегментами сети.


Управляемая согласованность

 Replication Factor (N) - количество узлов
хранящих реплики данных
 Read Consistency Level (R) — количество

(идентичных) реплик данных, которых
необходимо получить для того, чтобы операция
чтения считалась успешной
 Write Consistency Level (W) — количество

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


Управляемая согласованность

R + W >N


Реализация в Cassandra

 Replication Factor (N) задается на уровне
конфигурации

 Consistency Level можно установить
отдельно для каждой операции



Запись Чтение
Уровень Значение Уровень Значение
Zero Пустил-и-забыл One Чтение одной реплики
Any Доставка на кластер Quorum Чтение N/2+1реплик
One Коммит на одну ноду All Чтение всех реплик
Quorum Коммит на N/2+1 нод
All Коммит на все ноды




Слабая согласованность




Сильная согласованность


Использование

• Низкий уровень
• Thrift – интерфейсный протокол низкого уровня
• CQL и cqlsh – язык запросов и shell для их выполнения
• Cassandra-cli – простая утилита для простых запросов
• Высокий уровень
• Десятки разных клиентов для разных платформ:
• http://wiki.apache.org/cassandra/ClientOptions
• MirantisCassandrom – в следующей части


Спасибо за внимание
Вопросы?


Введение в Apache Cassandra

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Введение в Apache Cassandra

Similar to Введение в Apache Cassandra (20)

Введение в Apache Cassandra