View
456
Download
1
Category
Preview:
DESCRIPTION
Синхронизация
Citation preview
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
Recommended