СУБД осень 2012 лекция 11

СУБДЛекция 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


NoSQL

17


NoSQL

18


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


28

MapReduce

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

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

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

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


29

MapReduce


30

MapReduce


31

Anti-Entropy Protocols, Gossips

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

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

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


32

Anti-Entropy Protocols, Gossips


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)


34

Сonsistency


35

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

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

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


36

Eventual Сonsistency

Rebalancing

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

• MongoDB и Redis Cluster


37

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

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


38

Partitioning and replication

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

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

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

Cassandra


39

Failure Detection

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

• Bully algorithm

• MongoDB


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х максимум) для успешного завершения, иногда асинхронные сохранения могут заблокировать сервер на время


42

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

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

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


43

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

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

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


44

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

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

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

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


45

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

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

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

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

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

46

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

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

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

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

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


47

YCSB. 50/50 Read and Update


48

YCSB. 95/5 Read and Update


49


50

YCSB. Short scans


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

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

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

[email protected]

Documents

СУБД осень 2012 лекция 11