Download - Базы данных. Cassandra

CassandraКурс «Базы данных»

Цесько Вадим Александровичhttp://incubos.org

@incubos

Computer Science Center

30 сентября 2013 г.

Цесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 1 / 67

Содержание

1 Введение

2 Модель данных

3 Архитектура

4 Детали реализации

5 Заключение

6 Домашнее заданиеЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 2 / 67

Введение History

History

July 2008 — open-sourced by Facebook1

March 2010 — graduated from the Apache IncubatorInfluenced by Amazon DynamoCommitters: Rackspace, Digg, Twitter, Amazon,Microsoft

1Facebook. Cassandra — A Decentralized Structured Storage System:http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdfЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 3 / 67

http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf

http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf

Введение Features

Features

Decentralized — no SPoF, every node is identicalMulti data center replicationElastic ScalabilityHigh Availability and Fault ToleranceTunable consistencyCQL


Введение Data Model

Data Model

Based on Google BigtableHybrid: Key-value + Column-orientedКаждая строка содержит множество колонокКолонка (ячейка): имя + значениеРазные строки могут иметь разный набор колонокГруппировка колонок в семейства исуперсемейства

TableA distributed multi dimensional map indexed by a key


Введение ACID

ACID

Никаких JOIN-ов и внешних ключейАтомарность на уровне строк, нет rollbackМожно получить ошибку при записи, но записьсостоитсяОтметки времени от клиента при конфликтахНастраиваемая консистентность (количествореплик)Изоляция на уровне строкDurability : commit log + replication


Введение CAP

CAP

Tunable ConsistencyTunable AvailabilityPartition Tolerance


Введение Пользователи

ПользователиСамое популярное колоночное хранилище2:

CiscoCERNDiggFacebookIBMNetflixRedditSoundCloudTwitterOdnoklassnikiYandex

2http://db-engines.com/en/ranking/wide+column+storeЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 8 / 67

http://db-engines.com/en/ranking/wide+column+store

Введение Мотивация

Мотивация

If I had asked people whatthey wanted, they wouldhave said faster horses.

Henry Ford

Что не так с RDBMS?Очень рекомендую Chapter 1. "What’s Wrong withRelational Databases?"in "Cassandra: The DefiniteveGuide"a

aEben Hewitt. Cassandra: The Definitive Guide. 2010. ISBN1449390412.



У нас есть сервис на RDBMSВсё работает?Не трогай!

С чем могут быть проблемы:(Distributed) Transactions3

(Distributed) JOINs(Distributed) Schema evolutionSharding4

Functional segmentationKey-based shardingLookup table

3Gregor Hohpe. Starbucks Does Not Use Two-Phase Commit:http://www.eaipatterns.com/ramblings/18_starbucks.html

4Michael Stonebraker. The Case for Shared Nothing. 1986Цесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 10 / 67

http://www.eaipatterns.com/ramblings/18_starbucks.html


Use Case: RDBMS Scaling

LiveJournalBrad Fitzpatrick. LiveJournal’s Backend: A history ofscalinga. August 2005.

ahttp://www.danga.com/words/2005_oscon/oscon-2005.pdf


http://www.danga.com/words/2005_oscon/oscon-2005.pdf


Web Scale

IDC. The Expanding Digital Universe5. March 2007:YouTube: 2007 — 100 M videos/day, 2008 — 1 Bvideos/dayChevron: 2 TB/dayInternet: 2006 — 166 EB, 2010 — 1 ZBWall-Mart: 2000 — 110 TB, 2004 — 0.5 PBEmail: 1998 — 253 M accounts, 2010 — 2 B accountsetc.6

5http://www.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf

6http://highscalability.com/Цесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 12 / 67

http://www.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf

http://www.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf

http://highscalability.com/

Модель данных

Модель данных

Cassandra — партиционированное хранилищерядовИсходим из запросов, а не из сущностей и связейТаблица — коллекция упорядоченных колонокKeyspace — группа таблиц (обычно per application)


Модель данных Если глубже

Если глубже


Модель данных Интерфейсы

Интерфейсы

Thrift APIИсторически первыйНизкоуровневыйДовольно многословный

CQL (текущая версия 3.1)SQL-подобный(Почти насколько же) выразительныйРазвивается


Модель данных CQL

Пример

1 CREATE TABLE songs (2 id uuid PRIMARY KEY,3 title text,4 album text,5 artist text,6 data blob7 );

1 CREATE TABLE playlists (2 id uuid,3 song_order int,4 song_id uuid,5 title text,6 album text,7 artist text,8 PRIMARY KEY (id, song_order));


Модель данных CQL

Особенности

Compound keys (clustering)IndexesCollection types7: set, list, mapINSERT = UPDATE = UPSERTDELETE для строки или набора ячеекTTLCountersСм. спеку8

7http://www.datastax.com/dev/blog/cql3_collections8http:

//www.datastax.com/documentation/cql/3.1/webhelp/index.htmlЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 17 / 67

http://www.datastax.com/dev/blog/cql3_collections

http://www.datastax.com/documentation/cql/3.1/webhelp/index.html

http://www.datastax.com/documentation/cql/3.1/webhelp/index.html

Архитектура Компоненты

Компоненты

Consistent Hashing + VNodes (см. лекцию 1)Gossip — состав и состояние узловPartitioner — данные по узламReplica placement strategy — реплики поузламSnitch — топология (ДЦ и стойки)



Virtual Nodes



GossipУзлы периодически обмениваются информацией осебе и других узлахКаждую секунду не больше чем с тремя узламиВсе узлы быстро узнают информацио обо всехузлахСообщения имеют версию — устаревшаяинформация затираетсяSeed nodes во избежания партиционированияGossip-информация хранится на каждой нодеперсистентноОбнаружение сбоев узлов (+ dynamic snitch)9

9Naohiro Hayashibara, Xavier Defago, Rami Yared and Takuya Katayama.The φ Accrual Failure Detector. 2008Цесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 20 / 67


Partitioner

Consistent Hashing10

Новый Murmur3Partitioner (−263 to +263) истарый RandomPartitioner (0 to 2127 − 1)ByteOrderedPartitioner

Лексикографически по байтам ключаСложная балансировка нагрузки (расчёт диапазоновпартиций вручную)Неравномерная балансировка для разных таблицПоследовательная запись упирается в один узел

10http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/architecture/architectureDataDistributeAbout_c.htmlЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 21 / 67

http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/architecture/architectureDataDistributeAbout_c.html

http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/architecture/architectureDataDistributeAbout_c.html


Replica Placement Strategy

Replication Factor — количество реплик на кластерКаждая реплика на отдельном узлеВсе реплики равноправныSimpleStrategy:

1 ДЦ (если планируете расширяться, не используйте)Первая реплика на узел от PartitionerОстальные — по часовой стрелке по кольцу

NetworkTopologyStrategy:Определяет количество реплик в каждом ДЦУзлы для реплик — идём по кольцу до следующейстойкиЧасто стойки вырубаются целиком (питание,охлаждение, сеть, ...)



NetworkTopologyStrategy

ФакторыЖелательно чтение внутри ДЦУчитываем типичные сбои

По 2 реплики в каждом ДЦСбой одного узла — ConsistencyLevel.ONE

По 3 реплики в каждом ДЦСбой одного узла —ConsistencyLevel.LOCAL_QUORUMСбой двух узлов — ConsistencyLevel.ONE



SnitchОдинаковая конфигурация на узлахDynamic snitching wrapper11

По умолчанию и только на чтениеДанные с самой быстрой реплики, с остальных —контрольные суммыСтатистика Read Latency и текущие задачи узлов

SimpleSnitch: никаких ДЦ и стоекRackInferringSnitch: (110.dc.rack.node)PropertyFileSnitch: адреса в ДЦ/стойки вфайлеGossipingPropertyFileSnitch: локальный ДЦ истойка в файле на каждом узле + Gossip

11http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-futureЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 24 / 67

http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future

http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future

Архитектура Клиентские запросы

Клиентские запросы

Можно обращаться к любому узлуУзел становится координатором для текущегозапросаКоординатор проксирует с учётом Partitioner иReplica Placement Strategy



Write

Запрос всем репликам независимо отConsistencyLevelConsistencyLevel определяет, сколько репликдолжно ответить для успеха



Write: Пример



MultiDC Write

Оптимизация — один координатор в каждомудалённом ДЦConsistencyLevel.ONE илиConsistencyLevel.LOCAL_QUORUM — обязаныответить только локальные узлы (география невлияет на задержку)



MultiDC Write: Пример



Write: ConsistencyLevel

ANY — всегда успех (hinted handoff)ONE — в commit-log одного узлаTWOTHREEQUORUM — inter DC + нужен запас прочностиLOCAL_QUORUM — быстрее, чем QUORUMEACH_QUORUM — выше консистентностьALL — WAT?

Не забываемДаже при ONE и LOCAL_QUORUM запись пошлют всемрепликам в т. ч. в других ДЦЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 30 / 67


Read

Read-запросы от координатора репликам:Прямой запрос на чтение (в соответствии сConsistencyLevel)

Самым «быстрым» репликамСравниваем ответыЕсли не совпадают, то самая свежая (поtimestamp) — клиенту

Фоновый read repair (всем остальным репликам)Для синхронизации «горячих» данныхread_repair_chance по умолчанию 0.1Если не совпадают хэши, то перезаписываем



Read: Пример



Read ConsistencyLevel

ONE — ближайшая реплика, возможно, устаревшиеданныеTWOTHREEQUORUM — inter DC + нужен запас прочностиLOCAL_QUORUM — быстрее, чем QUORUMEACH_QUORUM — выше консистентностьALL — WAT?

ИнтерпретацияВозвращаем самое свежее значение из требуемогомножества репликЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 33 / 67


Quorum

QuorumQuorum = bRF2 + 1c

RF = 2⇒ Quorum = 2 — нет запасаRF = 3⇒ Quorum = 2 — в запасе 1 узелRF = 4⇒ Quorum = 3 — в запасе 1 узелRF = 5⇒ Quorum = 3 — в запасе 2 узла

ConsistencyR +W > RF

R = 2+W = 2 > RF = 3 — в запасе 1 узел



Клиентские запросы

ПроблемаУзел сбойнул: железо или (чаще) сетьА мы хотим на него записатьЧто делать?

Hinted HandoffПусть известно (Gossip), что узел лежит, или узелне отвечаетКоординатор запоминает hint локальноКогда обнаружится, что узел поднялся (Gossip),ему перешлют накопленные hints



Hint

СодержимоеКому предназначаетсяЗначение ключаДанные

ВниманиеHints хранятся ограниченное время (поумолчанию 3 часа)Официально рекомендуется периодический запускrepair



Ограничения

Hint засчитывается не на всех уровняхконсистентности12: 2 узла (1 мёртв) + RF=1 +ConsistencyLevel.ONEНо всегда работает, если не выключенConsistencyLevel.ANY — extreme write availabilityЕсли умрёт машина с hints, то мы их потеряем

12http://www.datastax.com/dev/blog/modern-hinted-handoffЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 37 / 67

http://www.datastax.com/dev/blog/modern-hinted-handoff


Anti-entropy

ПроблемаУзел умер — пропустил удаление данныхВернулся к жизни — данные возродились

Anti-entropyИнициируем с помощью nodetool repairЗапускаем readonly major compactionСтроим Merkle Treea

Обмениваемся деревьями и ищем отличияОбмениваемся отличающимися сегментами

ahttp://en.wikipedia.org/wiki/Merkle_tree


http://en.wikipedia.org/wiki/Merkle_tree

Детали реализации Хранение данных

Write Path



Пояснения

Memtables and SSTables per tableMemtable — отсортированаSSTable — неизменяемая отсортированнаяассоциативная таблицаОбычно строка распределена по несколькимSSTable



Пример

Команды:write (k1, c1:v1)write (k2, c1:v1 c2:v2)write (k1, c1:v4 c3:v3 c2:v2)

Commit-log:k1 , c1:v1k2 , c1:v1 c2:v2k1 , c1:v4 c3:v3 c2:v2

Memtable/SSTable:k1 c1:v4 c2:v2 c3:v3k2 c1:v1 c2:v2



Flush



Update Path



Delete

SSTable неизменяемаDelete — tombstone markerРеальное удаление по истеченииgc_grace_seconds во время compactionУдалённые данные могут возродиться (см.Anti-entropy)



Compaction

Объединяет SSTable-файлыФрагменты строкПротухшие tombstonesПерестраивает индексы

SSTable отсортирована ⇒ последовательныйпроходSizeTieredCompactionStrategy иLeveledCompactionStrategy1314

13http://www.datastax.com/dev/blog/when-to-use-leveled-compaction

14http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandraЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 45 / 67

http://www.datastax.com/dev/blog/when-to-use-leveled-compaction

http://www.datastax.com/dev/blog/when-to-use-leveled-compaction

http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra

http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra


Read



Комментарии

Каждая SSTable имеет Bloom filter15 —вероятность нахождения ключа в файлеЕсли вероятность отлична от 0, идём в partitionkey cacheЕсли нашли ключ в кэше, идём по смещению,находим сжатый блок и достаём данныеЕсли не нашли ключ в кэше:

В partition summary примерно находим смещение надискеЧитаем последовательно блок с дискаИз compression offset map вынимаем индекс блокаЧитаем сжатые данные и возвращаем клиенту

15http://en.wikipedia.org/wiki/Bloom_filterЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 47 / 67

http://en.wikipedia.org/wiki/Bloom_filter


Дополнительные структуры

Bloom filter — 1-2 ГБ / млрд. ключейPartition summary — по умолчанию шаг 128Compression offset map — 1-3 ГБ / 1 ТБ сжатыхданных



Read Path



Write-through Row Cache



Key Cache + Row Cache

См. подробности16.16http://www.datastax.com/docs/1.1/operations/tuning


http://www.datastax.com/docs/1.1/operations/tuning

Детали реализации CQL и колонки

CQL

1 CREATE TABLE comments (2 article_id uuid,3 posted_at timestamp,4 author text,5 karma int,6 content text,7 PRIMARY KEY (article_id, posted_at))



Колонки

См. подробности17.17http://www.datastax.com/dev/blog/thrift-to-cql3


http://www.datastax.com/dev/blog/thrift-to-cql3


Wide vs Skinny Rows

Wide Rows(+) Колонки отсортированы — возможны трюки18

(+/-) Атомарность(-) Row cache (скорее всего) не работает

Skinny Rows(+) Row cache(+/-) Неатомарно, но меньше contention(-) Больше записей — больше индексы, хужеработает Bloom Filter

18Класс!ная Cassandra: http://javapoint.ru/talks/15/Цесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 54 / 67

http://javapoint.ru/talks/15/

Заключение Опыт использования

Опыт использования

Из Hadoop можно «положить» кластер — ждёмCqlOutputFormatДовольно много «ручек» для подкручиванияВнимание к GCРазвитые средства мониторингаПериодический nodetool repair


Заключение Осталось за кадром

Осталось за кадром

SEDA19

Эксплуатация и тюнинг (JMX, nodetool)Масштабные примеры использования20

См. блог разработчиков21

19http://en.wikipedia.org/wiki/Staged_event-driven_architecture

20http://www.planetcassandra.org/blog/post/slideshare-presentations---cassandra-summit-2013

21http://www.datastax.com/dev/blogЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 56 / 67

http://en.wikipedia.org/wiki/Staged_event-driven_architecture

http://en.wikipedia.org/wiki/Staged_event-driven_architecture

http://www.planetcassandra.org/blog/post/slideshare-presentations---cassandra-summit-2013

http://www.planetcassandra.org/blog/post/slideshare-presentations---cassandra-summit-2013

http://www.datastax.com/dev/blog

Заключение Следующая лекция

Следующая лекция

MongoDB (приглашённый доклад)


Домашнее задание Требования (ещё раз)

Требования (ещё раз)

Проект на http://bitbucket.org (Hg) /http://github.com (Git) + Issue Tracking

Открытый проект — ссылку мне на почтуЗакрытый проект — мне админские права (incubos)

Обязательно: Scala/Java + ScalaTest/JUnit +Maven/SBTОбязательно: README + INSTALLКоманда 1-3 человека


http://bitbucket.org

http://github.com

Домашнее задание На текущий момент

Feature Request 0

«Телефонная книга» (см. лекцию 01-intro22

слайд #26)ОбязательныйВыдан 2013-09-16Сгорает сегодня

22http://incubos.org/2013/edu/db/01-intro.pdfЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 59 / 67

http://incubos.org/2013/edu/db/01-intro.pdf


Зачёт хотят

https://github.com/Elizaveta239/Storage_system_cschttps://github.com/Feodorov/DBhttps://github.com/medvector/cscenter-databases13https://github.com/Noxoomo/DBCSC

WAT?!


https://github.com/Elizaveta239/Storage_system_csc

https://github.com/Elizaveta239/Storage_system_csc

https://github.com/Feodorov/DB

https://github.com/medvector/cscenter-databases13

https://github.com/medvector/cscenter-databases13

https://github.com/Noxoomo/DBCSC


Feature Request 1

«Big data» per node (см. лекцию 04-commit23

слайд #64)Выдан 2013-09-23Сгорает 2013-10-14

23http://incubos.org/2013/edu/db/04-commit.pdfЦесько В. А. (CompSciCenter) Cassandra 30 сентября 2013 г. 61 / 67

http://incubos.org/2013/edu/db/04-commit.pdf


Кто всё-таки хочет участвовать

FR1 заменяет FR0Становится обязательнымНе засчитывается как дополнительный (неприносит балла)Всё так же сгорает 2013-10-14

Не забывайтеМожно участвовать командой до 3 человек


Домашнее задание Система оценивания

Система оценивания

Будет выдано не меньше 6 Feature Requests (FR)Для каждого FR — жёсткий срок (но не меньше 2недель)За каждый FR — 0, 1 или 2 балла (за особоемастерство и креативность)Для зачёта нужно FR0/FR1 + 4 балла + отчётПроверяю каждые выходные (по возможностичаще)Ценю равномерный прогрессВедите стабильную и нестабильную веткиОбратная связь в виде issuesНе все issues закрыты — не зачтено


Домашнее задание Feature Requests

FR2: Static Sharding

Равноправные узлыДанные распределены по кластеруСтатическая конфигурация (узлы и диапазоныключей)Клиент знает конфигурацию и куда ходитьТесты + TestabilityСгорает — 2013-10-14



FR3: Master-Slave Replication

Commit-log от master к slavesСтатическая конфигурацияКлиент знает конфигурацию — пишет в master,читает из slavesТесты + TestabilityСгорает — 2013-10-21



FR4: Scalability

Динамическая конфигурация (добавляем иудаляем ноды на лету)В простейшем случае 2PC новой конфигурацииGraceful DegradationConsistent HashingМиграция партиций при добавлении/удаленииузловТесты + TestabilityСгорает — 2013-10-28


Вопросы?

Вопросы?

http://incubos.org/contacts/Общие вопросы — в Twitter: @incubosВопросы по лекциям — в комментариях:http://incubos.org/blog/Частные вопросы — в почту[email protected]


http://incubos.org/contacts/

https://twitter.com/incubos

http://incubos.org/blog/

mailto:[email protected]