2015-12-05 Дмитрий Еманов - Многоверсионная архитектура...

Версионная архитектура данных:аспирин или головная боль

Дмитрий Емановdimitr@firebirdsql.org

Firebird Projectwww.firebirdsql.org

Разнообразный мир СУБД

Firebird

Что у них общего Кеши разного уровня Журналы изменений 100500 прочих разделяемых структур ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ

Разнообразный мир СУБД

Что у них общего Кеши разного уровня Журналы изменений 100500 прочих разделяемых структур ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ

Данные бывают разные Но какая-то их часть нужна нескольким пользователям При этом какая-то часть может параллельно изменяться И это надо как-то синхронизировать

Разнообразный мир СУБД

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

Данные

USER 1 USER 2 USER N...

Гранулярность доступа Единицей является запись (строка, кортеж) Зачастую она также является единицей хранения

Виды доступа Чтение Запись (изменение)

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

Решение в лоб, аналог мьютекса Только один субъект может работать с записью Писатели захватывают мьютекс на время модификации Читатели захватывают мьютекс на время чтения

Что это дает Безопасная многопользовательская работа Почему-то очень медленно Все ждут друг друга

Взаимно эксклюзивный доступ

RW-блокировки Два вида блокировок – shared / exclusive Писатели требуют EX блокировку Читатели требуют SH блокировку

Что это дает Множество читателей может работать параллельно Читатели ждут писателя, писатель ждет читателей Честность обслуживания Мы получили принцип работы т.н. блокировочников

Разделяемые блокировки

Когда приходит беда Большое число одновременных пользователей Пересекающиеся данные Длительные транзакции

Что происходит Растет таблица блокировок Увеличивается время проверки доступности Все начинает тормозить

А теперь увеличим нагрузку

Как выходить из ситуации Уменьшать число блокировок за счет расширения диапазона Уровень записи → блок данных Блок данных → диапазон блоков Диапазон блоков → таблица

Что при этом происходит Проблемы временно отступают С ростом нагрузки наблюдается лавинный эффект

Эскалация блокировок

Каждый должен работать со своей копией данных Для писателей это чревато потерей целостности данных Но для читателей возможно

Концепция Каждое изменение порождает новую “версию” записи (COW) Две активные (неподтвержденные) версии недопустимы Читатели видят подтвержденные версии Допускается одновременное существование множества

подтвержденных записей

Версионность: идея

Как все начиналось Диссертация Рида в MIT в 1978 Работа Бернштейна/Гудмана от 1981 DEC Rdb/ELN в 1984 InterBase в 1985 Известна как MVCC / MGA

Версионность: история

10 лет назад InterBase, Firebird PostgreSQL MySQL/InnoDB Oracle

Версионность: вчера и сегодня

Сейчас InterBase, Firebird, PostgreSQL, MySQL/InnoDB, Oracle + MS SQL Server MariaDB SAP HANA Cassandra, MemSQL, RethinkDB, CouchDB, NuoDB, ...

Версионность: вчера и сегодня

Что именно версионируем Блоки данных (счетчик изменений aka SCN) Записи (номер транзакции)

Где храним версии В блоках данных В отдельном хранилище

Как храним версии Запись целиком Дельта или вектор изменений

Версионность: особенности

Как создается версия INSERT → новая запись UPDATE → новая версия записи DELETE → пометка существующей версии или создание новой

Ссылки на версии Из других версий Из индексов

Можно копировать не все Например, блобы

Версионность: особенности

Снапшот Слепок состояния БД на момент времени Каждый читатель работает со своим снапшотом

Уровни видимости Снапшот создается при старте транзакции (repeatable read) Снапшот создается при старте SQL-запроса (read committed)

Видимость данных

Видимость данных

Version A

Version B

Version С

Txn 1

Txn 2

Txn 3

Txn 4

Txn 5

Txn 6

Это версии, которые никому не нужны Устаревшие и/или никому не видимые версии Они занимают место на диске,

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

Что такое «мусор»

Что такое «мусор»

Version A

Version B

Version С

Txn 1

Txn 2

Txn 3

Txn 4

Txn 5

Txn 6

Что такое «мусор»

Version A

Version B

Version С

Txn 2

Txn 3

Txn 4

Txn 5

Txn 6

Что такое «мусор»

Version A

Version B

Version С Txn 4

Txn 5

Txn 6

Что такое «мусор»

Version A

Version B

Version С

Txn 5

Txn 6

Отслеживать необходимость Трекинг старейших транзакций Фоновая сборка мусора (разные стратегии) Кооперативная сборка мусора Принудительная сборка мусора

Циклично удалять Кольцевой буфер Мусор или не мусор – это проблема индейцев

Когда и как чистить мусор

Как сделано Версионность на уровне записей Версии хранятся в блоках данных Разные стратегии сборки мусора

Особенности Новые версии замещают старые Старые версии хранятся в виде компактных дельт Индексы ссылаются на пакет версий Нет ограничений на число версий

Реализация в InterBase и Firebird

Как сделано Версионность на уровне записей Версии хранятся в блоках данных Разные стратегии сборки мусора

Особенности Новые версии размещаются на свободном месте Старые версии хранятся целиком Индексы ссылаются на конкретные версии Нет ограничений на число версий

Реализация в PostgreSQL

Как сделано Версионность на уровне записей Версии хранятся в tempdb Фоновая сборка мусора

Особенности Новые версии замещают старые Старые версии хранятся целиком Индексы ссылаются на конкретные версии Размер хранилища версий можно ограничить

Реализация в MS SQL Server

Как сделано Версионность на уровне записей Версии хранятся в журнале отката Сборка мусора только для удаленных записей,

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

Особенности Новые версии замещают старые Старые версии хранятся целиком Размер журнала отката не ограничен

Реализация в MySQL/InnoDB

Как сделано Версионность на уровне блоков данных Версии хранятся в журнале отката Журнал отката повторно используется

Особенности Новые версии замещают старые Изменения хранятся в виде дельт Размер журнала отката ограничен

Реализация в Oracle

Проблематика

Долгоиграющие транзакции Трудоемкость реконструкции старых версий Переполнение журнала/сегментов отката Влияние на производительность в целом

Сборка мусора Фрагментация данных Дополнительная нагрузка

Проблематика

Стоимость отката изменений Либо медленно, но навсегда Либо быстро, но с последствиями Еще можно побалансировать между крайностями

Версионность индексов Содержат привязку или нет Размер индекса против index-only scans

Проблематика

Инженерам браво! Множество разных подходов к решению единой проблемы Все варианты в большинстве случаев масштабируются лучше

блокировочников

Серебряной пули нет Каждое решение имеет свои достоинства и свои недостатки На разных видах нагрузки они могут вести себя по разному Пользователи приветствуют наличие выбора и здоровую

конкуренцию :-)

Послесловие

Вопросы?

Дмитрий Емановdimitr@firebirdsql.org