Синхронизация данных peer-to-peer

NoSQL P2P DB на коленке

Часть 2: СинхронизацияГлеб Лебедев, Netvox Lab 2013

для MongoDB UG

Алгоритм 1. GIT

GIT

Так как мы строим Peer-2-Peer систему, то для начала стоит рассмотреть существующие решения.

GIT обладает всеми нужными нам свойствами.

GIT

GIT хранит все данные в виде объектов с ключами

Ничего не напоминает? :)

Key - Value

GIT

Репозиторий GIT:

…

SHA1(Содержимое)

Содержимое

SHA1(Содержимое)

Содержимое

SHA1(Содержимое)

Содержимое

GIT

Контент это:

● Тип (blob, tree, commit, …)● Пробел● Длина файла● 0 (ноль)● Содержимое файла

Работает даже для пустых файлов!

GIT: Структура истории

Допустим у нас есть файл. Вот его содержимое:

Но где его имя?

SHA1(Содержимое)

Содержимое

GIT: Структура истории

Добавляем дерево:

Но как понять, какое дерево корневое?

SHA1(Содержимое)

blobСодержимое

SHA1(Дерево)

TreeДерево

file.txt

GIT: Структура истории

Добавляем коммит:

Но как понять, какой коммит последний?

SHA1(Содержимое)

blobСодержимое

SHA1(Дерево)

TreeДерево

file.txtSHA1(Commit)

Commit

GIT: Структура истории

SHA1(Содержимое)

blobСодержимое

SHA1(Дерево)

TreeДерево

file.txtSHA1(Commit)

Commit

HEAD

Добавим ещё один файл

GIT: Структура истории

GIT: Структура истории

SHA1(Содержимое)

blobСодержимое

SHA1(Дерево 2)

TreeДерево

file.txt

SHA1(Commit 2)

Commit 2

HEAD

SHA1(Содержимое)

blobСодержимое

SHA1(Дерево)

TreeДерево

file.txtSHA1(Commit)

Commit

file2.txt

GIT как хранилище документа

Возьмём для примера текстовый документ, похожий на docx или odt.

Оригинальное содержимоеTree 1

content

Commit 1

HEAD

GIT как хранилище документа

Добавим в него изображение

Содержимое с картинкой

Tree 2

content

Commit 2

HEAD

Оригинальное содержимоеTree 1

content

Commit 1

Картинка1.png

GIT как хранилище документа

Исправим текст

Содержимое с картинкой

Tree 2

content

Commit 2

HEAD

Оригинальное содержимоеTree 1

content

Commit 1

Картинка1.png

Новое содержимое с картинкойTree 3 contentCommit 3

GIT

Можно использовать GIT:

● Документ должен быть разбит на мелкие, атомарные, несвязанные блоки разумного размера.

● Изменения каждого блока могут быть смешаны (merge) независимо.

GIT

Например слайд презентации - отличный претендент на элемент репозитория.

GIT в общей схеме БД

Serializer

Key → Value

Document Converter

Lucene

Repository

Поисковые запросы

λ

GITПреобразование GIT в объект и

наоборот

GIT в общей схеме БД

Document Converter

Lucene

Repository

Поисковые запросы

λ

GITПреобразование GIT в объект и

наоборот

Можно реализовать схему, в которой каждый объект в GIT будет являться отдельной записью в репозитории.

Большой минус - изменения в деревьях, общие для всей системы.

Может быть это можно обойти?

GIT

Чему нас учит GIT?

● Хеш-функции можно доверять● Хешировать можно хеши (tree)● Можно быстро искать изменения по

контрольным суммам● Можно хранить всё● Смешивание с использованием трёх

версий

GIT

Кстати о 3-х стороннем смешивании

Branch Content

Branch Tree

Origin Content

Origin Tree

Remote Content

Remote Tree

GIT

Я добавил элемент!

Branch Content

Branch Tree Origin Tree Remote Tree

GIT

Кто-то добавил элемент:

Branch Tree Origin Tree

Remote Content

Remote Tree

GIT

Кто-то удалил элемент

Branch Tree

Origin Content

Origin Tree Remote Tree

GIT

Я удалил элемент!

Branch Tree

Origin Content

Origin Tree Remote Tree

GIT

Я и кто-то другой вместе удалили элемент

Branch Tree

Origin Content

Origin Tree Remote Tree

GIT

Я и кто-то другой вместе добавили один и тот-же элемент

Content

Branch Tree Origin Tree Remote Tree

GIT

… Или заменили старый на одинаковый новый

Content

Branch Tree

Origin Content

Origin Tree Remote Tree

GIT

Конфликт! Кто-то одновременно со мной поменял элемент!

Branch Content

Branch Tree

Origin Content

Origin Tree

Remote Content

Remote Tree

GIT

Конфликт! Я удалил элемент, а его кто-то оменял!

Branch Tree

Origin Content

Origin Tree

Remote Content

Remote Tree

GIT

… Или я поменял, а кто-то удалил. Конфликт!

Branch Content

Branch Tree

Origin Content

Origin Tree Remote Tree

GIT

И так далее, включая случаи, которые лучше избегать.

GIT

Паника! Я поменял файл, который кто-то заменил на папку с тем же именем!

Branch Content

Branch Tree

Origin Content

Origin Tree Remote Tree

Remote SubTree

Алгоритм 2. Часы Лампорта

Справочники

● Небольшие объекты, не имеющие сложной структуры.

● Их изменения не обязательно смешивать.

Справочники

Представим справочник в виде цепочки событий:

Запись 1

Значение А

Запись 2

Значение Б

Запись 1

Значение В

Запись 2

Значение удалено

1:A 1:В2:Б

1:A2:Б

1:В

Часы Лампорта

Часы Лампорта (Лэсли Лэмпорт, 1978)

● Синхронизировать все узлы полностью невозможно.

● Часы Лэмпорта присваивают каждому событию единственное число, монотонно увеличивая счётчик.

Часы Лампорта

● счётчик увеличивается перед каждым внутренним событием процесса;

● при отправке сообщения значение счётчика прикрепляется к сообщению;

● при получении сообщения значение счётчика процесса-получателя выставляется в максимум текущего и полученного значения и увеличивается на 1.

Векторные часы

Векторные часы — алгоритм получения частичного упорядочения событий в распределённой системе и обнаружения нарушений причинно-следственных связей.

Векторные часы

● изначально все значения часов равны 0;

● в случае внутреннего события счётчик текущего процесса увеличивается на 1;

● перед отправкой сообщения внутренний счётчик, соответствующий текущему процессу, увеличивается на 1, и вектор целиком прикрепляется к сообщению;

● при получении сообщения счётчик текущего процесса увеличивается на 1, далее значения в текущем векторе выставляются в максимум от текущего и полученного.

Справочники

Но это к нам не имеет (почти) никакого отношения.

Допустим мы создали значение на узле 1:

Запись 1.Источник 1.Версия 1.Значение: А

1

Справочники

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 2.Версия 2.Значение: Б

23

21

Справочники

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 2.Версия 2.Значение: Б

3

Запись 1.Источник 1.Версия 1.Значение: А

21

Справочники

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 2.Версия 2.Значение: Б

3

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 3.Версия 2.Значение: В

Запись 1.Источник 2.Версия 3.Значение: В

Запись 1.Источник 2.Версия 2.Значение: Б

21

Справочники

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 2.Версия 2.Значение: Б

3

Запись 1.Источник 1.Версия 1.Значение: А

Запись 1.Источник 3.Версия 2.Значение: В

Запись 1.Источник 2.Версия 3.Значение: В

Запись 1.Источник 2.Версия 2.Значение: Б

Запись 1.Источник 3.Версия 2.Значение: В

Запись 1.Источник 2.Версия 3.Значение: В

Справочники

Что делать если версии совпали?

Выбираем по одинковому признаку (например по номеру источника)

Запись 1.Источник 2.Версия 2.Значение: Б

Запись 1.Источник 3.Версия 2.Значение: В

Алгоритм 3. Кольцевой хеш

Кольцевой хеш

Позволяет найти положение участка известных данных в произвольном блоке данных за один проход.

Используется в rsync

Кольцевой хеш

Можно использовать для оптимизации блоков передаваемых данных (rsync):

Принимающий компьютер разделяет свою копию файла на неперекрывающиеся куски фиксированного размера S, и вычисляет контрольную сумму для каждого куска: MD4-хеш и более слабый rolling checksum, и отправляет их серверу, с которым синхронизируется.

Cервер, с которым синхронизируются, вычисляет контрольные суммы для каждого кусочка размера S в своей версии файла, в том числе перекрывающиеся куски.

Кольцевой хеш

Можно попробовать оптимизировать синхронизацию журналов изменений справочников.

Наибольшая общая подпоследовательность

Путь копания в алгоритмах может привести вас к очень интересным проблемам.

Но на сегодня, наверное, хватит.

Вопросы?(c)

2013