СУБД 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

NoSQL

Aggregate orientation

NoSQL

Aggregate orientation

NoSQL

Aggregate orientation

NoSQL

• навеяны 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

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

• MapReduce: Simplified Data Processing on Large Clusters.

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

• map (k1, v1) → k2,v2

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

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

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

MapReduce

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

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

MapReduce

MapReduce

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

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

Anti-Entropy Protocols, Gossips

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

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

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

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

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

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

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)

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

Сonsistency

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

Сonsistency

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

Eventual Сonsistency

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

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

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

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

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

• MongoDB и Redis Cluster

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

Rebalancing

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

Partitioning and replication

• NodeID = hash(key) % TotalNodes

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

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

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

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

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

Cassandra

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

Failure Detection

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

• Bully algorithm • MongoDB

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

Coordinator Election

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

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

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

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

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

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

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

мегабайта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

за счет Java Garbage Collection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

YCSB. 50/50 Read and Update

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

YCSB. 95/5 Read and Update

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

YCSB. Short scans

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

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

Use case

Use case

One database to rule them all

Silver Bullet

No Silver Bullet

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

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

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

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

s.stupnikov@corp.mail.ru