Date post: | 16-Jul-2015 |
Category: |
Education |
Upload: | technopark |
View: | 269 times |
Download: | 4 times |
СУБД
Лекция 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
Для каждого типа данных следует
использовать хранилище наиболее
для него подходящее