СУБДЛекция 10

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

2

3

4

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

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

• Персистентное хранение данных

• Конкурентный доступ

• Shared database integration

• Стандартная (практически) модель

Почему NoSQL?

5

Impedance Mismatch

Почему NoSQL?

6

Приложение

БД

Почему NoSQL?

7

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

90ые: Shared database

БД

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

Почему NoSQL?

8

2000ые: Web applications

БД

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

БД БД

Почему NoSQL?

9

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

Почему NoSQL?

10

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

Почему NoSQL?

11

Attack of the Clusters

Почему NoSQL?

12

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

Почему NoSQL?

13

NoSQL Rising

14

Общие характеристика NoSQL БД:• Не используют реляционную модель

• Хорошо подходят для развертывания на кластере

• Open-source

• Schemaless

NoSQL

15

Aggregate orientation

NoSQL

16

Aggregate orientation

NoSQL

17

Aggregate orientation

NoSQL

18

Aggregate orientation

NoSQL

19

20

NoSQL

21

Key-Value Store

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

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

• для БД содержание значение непрозрачно (просто какой-то BLOB)

Примеры:• Voldemort

• Redis

• Riak

Виды NoSQL БД

22

Document-oriented store

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

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

• для БД содержание значение прозрачно

Примеры:• CouchDB

• MongoDB

Виды NoSQL БД

23

Column-oriented store

• навеяны BigTable от Google

• похожи на column-oriented реляционные БД, но с особенностями

• модель данных: ключ строки –> семейство колонок –> колонка –> значение

Примеры:• HBase

• Cassandra

• Hypertable

Виды NoSQL БД

24

Column-oriented store

Виды NoSQL БД

25

Graph database

• навеяны теорией графов G=(V, E) от математиков 18го века

• хорошо моделируют сложные данные

• модель данных: узлы, ребра и их атрибуты

Примеры:• Neo4j

• AllegroGraph

Виды NoSQL БД

26

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

27

CAP Theorem

CAP Theorem

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

28

MapReduce

• MapReduce: Simplified Data Processing on Large Clusters. Jeffrey Dean and Sanjay Ghemawat

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

• map (k1, v1) → k2,v2• reduce (k2, list(v2)) → v3

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

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

29

MapReduce

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

30

MapReduce

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

31

Anti-Entropy Protocols, Gossips

• Поддержание консистентности (eventual consistency) и синхронизация состояния кластера• проблему можно решить за счет глобального

координатора

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

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

32

Anti-Entropy Protocols, Gossips

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

33

Сonsistency

• 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

34

Сonsistency

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

35

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

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

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

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

36

Eventual Сonsistency

Rebalancing

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

• MongoDB и Redis Cluster

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

37

• NodeID = hash(key) % TotalNodes - плохая идея, если вы планируете добавлять и убирать узлы

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

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

38

Partitioning and replication

• Автоматическая адаптация ― tradeoff между временем опредления отказа и вероятностью ложной тревоги

• Гибкость ― не только «жив», «мертв» (разные состояния, как в MapReduce)

• Масштабируемость• Phi Accrual Failure Detector -

Cassandra

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

39

Failure Detection

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

• Bully algorithm

• MongoDB 

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

40

Coordinator Election

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

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

• Молодой продукт, в нем встречаются баги (бывает Segmentation fault, core dumped, socket exception 9001 (?!) ) – используйте 2.2 и выше

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

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

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

41

• Все должно помещаться в RAM (есть VirtualMemory, но все ключи все равно в RAM!). Количетсво требуемой памяти пропорционально размеру dataset’у

• Персистентность либо снепшотная, либо append-only с помощью fsync. Требуется очень много I/O ресурсов.

• Операция сохранения требует доп. памяти (до 2х максимум) для успешного завершения, иногда асинхронные сохранения могут заблокировать сервер на время

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

42

• Архитектура подразумевает tradeoff памяти на скорость. Для определенных нагрузок в разы может отличаться количество байт переданное на хранение и количество памяти, используемое Redis

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

• Один инстанс не масштабируем (одно ядро, один поток). Нужно запускать несколько и на стороне приложения заниматься шардингом и балансировкой

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

43

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

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

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

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

44

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

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

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

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

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

45

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

• HBase, Hypertable ― много данных, не нужны произвольные запросы и транзакции

• Cassandra, Riak ― при высокой нагрузке на запись и если подходит слабая консистентность

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

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

46

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

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

• HBase, Hypertable ― атомарность на уровне строк, консистентность за счет Paxos

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

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

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

47

YCSB. 50/50 Read and Update

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

48

YCSB. 95/5 Read and Update

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

49

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

50

YCSB. Short scans

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

51

YCSB. Read performance as cluster size increases

Tarantool ― расширяемая, транзакционная высокопроизводительная СУБД для хранения наиболее запрашиваемых и часто меняющихся данных.

52

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

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

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

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

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

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

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

• lock-free - кооперативная многозадачность (coroutines, fibers). Типичная нагрузка на ЦПУ < 10%

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

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

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

54

Use case

55

Use case

56

Use case

57

58

One database to rule them all

59

Silver Bullet

60

No Silver Bullet

61

62

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

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

s.stupnikov@corp.mail.ru