Разработка распределенного алгоритма двухфазной синхронизации на основе архитектуры базы данных 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 транзакций в секунду;
  • Проведено функциональное тестирование;

Планы:

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

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

By Vladislav Shpilevoy

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

  • 1,558

More from Vladislav Shpilevoy