СУБД осень 2012 лекция 11
TRANSCRIPT
СУБДЛекция 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
Для каждого типа данных следует использовать хранилище наиболее для него подходящее
Спасибо за вниманиеСтанислав Ступников