СУБД 2013 Лекция №10 "Нереляционное решение в области баз...

СУБД

Лекция 10

Станислав Ступников

Почему NoSQL?

20 лет успешного существования на рынке!

• Персистентное хранение данных• Конкурентный доступ• Shared database integration• Стандартная (практически) модель

А что там с РСУБД?

Почему NoSQL?

А что там с РСУБД?

Почему NoSQL?

Impedance Mismatch

Почему NoSQL?

80ые: Мейнфреймы

Приложение

БД

БД

Почему NoSQL?

90ые: Shared database

ПриложениеПриложение Приложение

Почему NoSQL?

2000ые: Web applications

БД

ПриложениеПриложениеПриложение

БД БД

Почему NoSQL?

Данных стало больше

Почему NoSQL?

Данные стали сложнее

Почему NoSQL?

Attack of the Clusters

Почему NoSQL?

Производительность РСУБД

NoSQL Rising

NoSQL

• Не используют реляционную модель• Хорошо подходят для развертывания на кластере• Open-source

• Schemaless

Общие характеристика NoSQL БД:

NoSQL

Aggregate orientation

• навеяны Dynamo DB от Amazon

• модель данных: множество пар ключ-значение• для БД содержание значение непрозрачно (просто какой-то BLOB)

Примеры:• Voldemort• Redis• Riak

Виды NoSQL БД

Key-Value Store

Виды NoSQL БД

Document-oriented store

• навеяны Lotus Notes от IBM

• модель данных: множество множеств ключ-значение• для БД содержание значение прозрачно

Примеры:• CouchDB• MongoDB

Виды NoSQL БД

Column-oriented store

• навеяны BigTable от Google• похожи на column-oriented реляционные БД, но с особенностями• модель данных: ключ строки –> семейство колонок –> колонка –>значение

Примеры:• HBase• Cassandra• Hypertable

Column-oriented store

Виды NoSQL БД

Виды NoSQL БД

Graph database

• навеяны теорией графов G=(V, E) от математиков 18го века• хорошо моделируют сложные данные• модель данных: узлы, ребра и их атрибуты

Примеры:• Neo4j• AllegroGraph

Теоретические основы NoSQL

CAP Theorem

CAP Theorem


• MapReduce: Simplified Data Processing on Large Clusters.

Jeffrey Dean and Sanjay Ghemawat• Вычисления простые, но данных очень много• Не надо связывать самому с распределенными вычислениями• Просто определить две функции:

• map (k1, v1) → k2,v2

• reduce (k2, list(v2)) → v3

• За распределение данных, обработку отказов, планирование

и запуск параллельных задач отвечает сам фреймворк

MapReduce



MapReduce


Anti-Entropy Protocols, Gossips

• Поддержание консистентности (eventual consistency) и

синхронизация состояния кластера

• проблему можно решить за счет глобального координатора

• Каждый узел по расписанию выбирает другой случайный узел

и обменивается информацией• тут возможно 3 стратегии


Anti-Entropy Protocols, Gossips

• Read-Write consistency – минимизировать время сходимости

реплик

• Read-after-write consistency

• Read-after-read consistency

• Write-Write consistency – обработка конкурентной записи

• Atomic Writes – пишем «самое новое» значение

(Cassandra)

• Atomic Read-modify-write

• Conflict prevention - distributed locking или

консенсус-протоколы, как PAXOS (РСУБД,

HBase, MongoDB)

• Conflict detection – в случае конфликта

откатываемся или храним историю, пока не

разрешим (Riak, Voldemort, CouchDB)


Сonsistency


Сonsistency


Eventual Сonsistency

• vector clock – список пар (узел, счетчик)

• Один вектор на каждую версию каждого объекта

• Конфликт улаживает клиент

• Устойчивая к отлючениям электричества миграция (напр.,

расширение кластера)

• MongoDB и Redis Cluster


Rebalancing


Partitioning and replication

• NodeID = hash(key) % TotalNodes

- плохая идея, если вы планируете

добавлять и убирать узлы

• Consistent hashing – хорошая идея

• Автоматическая адаптация – tradeoff

между временем опредления отказа и вероятностью ложной тревоги• Гибкость – не только «жив», «мертв» (разные состояния, как в MapReduce)• Масштабируемость• Phi Accrual Failure Detector -

Cassandra


Failure Detection

• Выбор лидера среди реплик

• Bully algorithm • MongoDB


Coordinator Election

Недостатки NoSQL решений

• 3 config сервера – узкое место при шардинге

• MapReduce – однопоточный, read\write locks, на JS O_o

• Молодой продукт, в нем встречаются баги (бывает

Segmentation fault, core dumped, socket exception 9001 (?!) ) –

используйте 2.2 и выше

• По-умолчанию максимальный размер объекта — 4

мегабайта.

• На 32-битных машинах, максимальный размер одной базы

данных — 2 гигабайта


• Все должно помещаться в RAM (есть VirtualMemory, но все

ключи все равно в RAM!). Количетсво требуемой памяти

пропорционально размеру dataset’у

• Персистентность либо снепшотная, либо append-only с

помощью fsync. Требуется очень много I/O ресурсов.

• Операция сохранения требует доп. памяти (до 2х максимум)

для успешного завершения, иногда асинхронные сохранения

могут заблокировать сервер на время


• Архитектура подразумевает tradeoff памяти на скорость. Для

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

количество байт переданное на хранение и количество

памяти, используемое Redis

• Поиск только по ключам

• Один инстанс не масштабируем (одно ядро, один поток).

Нужно запускать несколько и на стороне приложения

заниматься шардингом и балансировкой


• Все на одной машине

• Бесплатно: GPLv3 AGPL

• Коммерческое использование: 6-24k $ в год


• Особенности консистентности

• Нет индексов

• Нет аd-hoc querying (создаете БД под запросы)

• Может быть высокая read/write latency на больших нагрузках

за счет Java Garbage Collection

Сравнение NoSQL решений

Масштабируемость

• HBase, Hypertable – много данных, не нужны произвольные

запросы и транзакции

• Cassandra, Riak – при высокой нагрузке на запись и если

подходит слабая консистентность

• MongoDB, Redis – «быстрые» данные (клики, биржа)


Транзакционность

• Может лучше РСУБД?

• HBase, Hypertable – атомарность на уровне строк,

консистентность за счет Paxos

• Cassandra, Riak – слабоконсистентны

• MongoDB, Redis – атомарность на уровне документа\записи


YCSB. 50/50 Read and Update


YCSB. 95/5 Read and Update


YCSB. Short scans


YCSB. Read performance as cluster size increases

Tarantool - расширяемая, транзакционная высокопроизводительная СУБД

для хранения наиболее запрашиваемых и часто меняющихся данных.

• Индексы: простые, составные, уникальные, неуникальные

• Операции: INSERT/UPDATE/SELEC/REPLACE/DELETE

• Поддерживает простой SQL

Обзор архитектуры и особенности

• Все данные в RAM

• + на диске за счет write-ahead log (WAL)

• WAL растет → делаем снепшоты c copy-on-write

• lock-free - кооперативная многозадачность (coroutines,

fibers). Типичная нагрузка на ЦПУ < 10%

• Асинхронная репликация

• Хранимые процедуры на Lua

• Фоновые процедуры

Use case

One database to rule them all

Silver Bullet

No Silver Bullet

Для каждого типа данных следует

использовать хранилище наиболее

для него подходящее

Спасибо за вниманиеСтанислав Ступников

[email protected]

СУБД 2013 Лекция №10 "Нереляционное решение в области баз...

Education

Transcript of СУБД 2013 Лекция №10 "Нереляционное решение в области баз...