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

Научный руководитель:

Волканов Дмитрий Юрьевич

Научный консультант:

Осипов Константин Аркадьевич

Выполнил:

Шпилевой Владислав Дмитриевич

План доклада

  1. ​Введение
  2. Постановка задачи
  3. Базы данных
  4. Tarantool
  5. Протокол 2PC, оптимизации
  6. Реализация
  7. Результаты

Введение

СУБД

База

данных

API

​Задачи СУБД:

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

Two-Phase Commit

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

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

API

  1. 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

Thread

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

Finish

У

К

У

У

У

prepare

К

ok

ok

ok

not ok + abort

К

abort

Результаты

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

Планы:

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