Разработка распределенного алгоритма двухфазной синхронизации на основе архитектуры базы данных Tarantool

План доклада

Введение
Постановка задачи
Базы данных
Tarantool
Протокол 2PC, оптимизации
Реализация
Результаты

Введение

СУБД

База

данных

API

Задачи СУБД:

Постоянное хранение;
Предоставление API для пользователей;
Изоляция клиентов;
Поддержание консистентности;

Two-Phase Commit

Классический 2PC устарел:

Появление In-memory БД;
Требование быстрой записи > быстрого чтения;
Увеличение количества узлов распределенных БД;

API

Pelkonen T. et al. Gorilla: A fast, scalable, in-memory time series database //Proceedings of the VLDB Endowment. – 2015. – Т. 8. – No. 12. – Pages 1816-1827.

[1]

Постановка задачи

Реализовать и исследовать распределённый алгоритм двухфазного коммита для баз данных на основе архитектуры базы данных Tarantool.

Изучить протокол 2PC и его оптимизации;
Реализовать транзакции в Tarantool на уровне бинарного протокола;
Реализовать оптимизированный протокол двухфазного коммита на архитектуре базы данных Tarantool, позволяющий совершать не менее 100 двухфазных транзакций в секунду;
Провести исследование реализации.

Базы данных

СУБД

База

данных

База данных ≠ СУБД
СУБД обеспечивает ACID:

Atomicity Consistency Isolation Durability

Транзакции - единицы оперирования данными и гарант всех четырех свойств.

2. Ullman J. D., Garcia-Molina H., Widom J. Database Systems: The Complete Book. – 2002.

[2]

Устойчивость к ошибкам с помощью WAL -

Write Ahead Log.

BEGIN

DML операции

ROLLBACK

COMMIT

Лог

менеджер

конфликтов

ROLLBACK

Применение

OK

Распределенные базы данных

Репликация

Фрагментация

2PC Транзакции

Фаза 1: Рассылка и голосование

Фаза 2: Применение результата

Клиенты

Network

Thread

Transactions

Thread

WAL

Thread

Шина обмена сообщениями

In-memory данные

Дисковые данные

3 основных потока;
2 движка;
Lua, C/C++, Python;
OpenSource;
Виртуальные потоки - файберы;

t, время

Поток 1

Поток 2

Поток 3

Файбер 1

Файбер 2

Файбер 3

Внутри потока:

Thread

Протокол двухфазного коммита

Классический

Координатор

Участники

Log(Prepare Txn)

Send(Prepare Txn) x Nучастников

Каждый решает,

может ли сделать Commit, пишет в лог и отправляет ответ

Forced Log(Decision about Txn)

Send(Decision about Txn)

Фаза 1

Фаза 2

Есть хоть один отрицательный ответ?

Да

Нет

Forced Log(Abort Txn)

Forced Log(Commit Txn)

Send(Abort Txn) x N

Send(Commit Txn) x N

Пришел Commit?

Да

Нет

Forced Log(Commit Txn)

Apply Txn

Forced Log(Abort Txn)

Abort Txn

Ack

Оптимизации: presumed

Presumed-commit

Presumed-either

Presumed-abort

Координатор - нет информации о транзакции = был commit/abort.

Если проголосовали за оптимизированное решение, то его не форсированная запись в лог.

Не нужны подтверждения от участников в случае оптимизированного решения.

Меньше посылок по сети и форсированных логов в случае "угадывания" результата транзакции.

Выбор presumed commit или abort для каждой транзакции.

Если в начале транзакции можно записать в лог быстро (piggybacking), то PrC, иначе PrA.

Как результат, экономия форсированных логов и сетевых сообщений в большем числе исходов.

Реализация

Классический 2PC + Presumed Commit

Network Thread

Шардинг

Шард...

Шард

Хеш-таблица соединений

Connection 1

Хеш-таблица идентификаторов транзакций

. . .

TX Thread

Хеш-таблица восстанавливаемых транзакций и TX менеджер

Transaction 1

is_2PC: bool;

is_prepared: bool;

coordinator_id: int;

memory_allocator: allocator;

. . .

Transaction K

Connection N

WAL Thread

Прием сообщений из очереди и запись в лог

WAL Request M

rows: forward_list;

rows[i]: {

type: Abort/Commit/Prepare,

data: encoded_binary

};

. . .

WAL Request 1

Шина обмена сообщениями

. . .

Реализация: оптимизации

Форсированные логи не блокируют работу

Не нужно Abort участникам, ответившим "нет" на Prepare - они откатываются сразу

2PC Txn1

Single node Txn2

Forced Log

Wait finish...

Commit and forced log

Wait finish...

Finish

У

К

У

prepare

К

ok

not ok + abort

К

abort

Результаты

Реализованы транзакции на уровне бинарного протокола;
Реализован оптимизированный протокол 2PC на архитектуре БД Tarantool, позволяющий совершать не менее 100 транзакций в секунду;
Проведено функциональное тестирование;

Планы:

Реализованное решение верное, но можно значительно ускорить. Нужны скорости порядка тысяч транзакций.

Разработка распределенного алгоритма двухфазной синхронизации на основе архитектуры базы данных Tarantool

Разработка распределенного алгоритма двухфазной синхронизации на основе архитектуры базы данных Tarantool

More from Vladislav Shpilevoy