В докладе будет рассказано о том, зачем Яндексу понадобилась синхронизация данных и с чем пришлось столкнуться в процессе: Почему синхронизируем на уровне приложения. Update log против Insert log. Проблемы связанные с DB. Типы данных, отсутствие транзакций. Проблемы связанные с Django. Проблемы связанные c изменениями ниже уровня приложения. Например массовый update.

1. Эволюция системы
синхронизации
данных между
сервисами
Прокофьев Дмитрий, Яндекс

2. О чем поговорим
Зачем нам синхронизация
Как она развивалась
На какие грабли мы наступили
Какой опыт приобрели

3. Внутренние сервисы

4. Технологии
1. Python
2. Django
3. СУБД MySQL, Oracle...
4. South
5. Django-mptt

5. Архитектура

6. Данные
1. Информация о людях, офисах, оборудовании...
2. Данных не много - несколько сотен тысяч.
3. Сложные связи между сущностями.
4. Важна целостность.

7. Требования к
синхронизации

8. Требования к синхронизации
1. Получать изменения частями.
2. Возможность начать с нуля.
3. Надежность и корректные данные.
4. Исправляем ошибки.

9. Требования к синхронизации
1. Получать изменения частями.
2. Возможность начать с нуля.
3. Надежность и корректные данные.
4. Исправляем ошибки.

10. Требования к синхронизации
1. Получать изменения частями.
2. Возможность начать с нуля.
3. Надежность и корректные данные.
4. Исправляем ошибки.

11. Требования к синхронизации
1. Получать изменения частями.
2. Возможность начать с нуля.
3. Надежность и корректные данные.
4. Исправляем ошибки.

12. Лог для хранения
изменений

13. Два подхода к ведению лога
1. Передача объектов с фильтром по timestamp (Update log).
2. Хранение журнала изменений. (Insert log)

14. Update log

15. Получать изменения частями
1. Изменения на уровне БД (mptt).
– Сами создаем записи в логе.
– Регламентная процедура на клиенте.
– Логика для каждого объекта на клиенте.
2. Нужны состояния на момент создания.

16. Получать изменения частями
1. Изменения на уровне БД (mptt).
– Сами создаем записи в логе.
– Регламентная процедура на клиенте.
– Логика для каждого объекта на клиенте.
2. Нужны состояния на момент создания.

17. Возможность начать с нуля
1. Забираем весь лог полностью. Объем?

18. Надежность и корректные данные
1. Foreign key, constraints.
2. MySQL хранит время с точностью до секунды.
3. Ресурсоемкие операции.

19. Надежность и корректные данные
1. Foreign key, constraints.
2. MySQL хранит время с точностью до секунды.
3. Ресурсоемкие операции.

20. Надежность и корректные данные
1. Foreign key, constraints.
2. MySQL хранит время с точностью до секунды.
3. Ресурсоемкие операции.

21. Как исправляем ошибки
1. Пересохраняем объекты в нужном порядке.

22. Insert log

23. Получать изменения частями
1. Нужна очередь. Но что делать с пропусками?
2. Объем лога постоянно растет, но его можно обрезать.
3. В django нет сигналов на commit транзакций.

24. Получать изменения частями
1. Нужна очередь. Но что делать с пропусками?
2. Объем лога постоянно растет, но его можно обрезать.
3. В django нет сигналов на commit транзакций.

25. Получать изменения частями
1. Нужна очередь. Но что делать с пропусками?
2. Объем лога постоянно растет, но его можно обрезать.
3. В django нет сигналов на commit транзакций.

26. Возможность начать с нуля
1. Нужно готовить данные.

27. Надежность и корректные данные
1. Необходимо следить за последовательностью
сообщений на клиенте.

28. Как исправляем ошибки
1. В сообщении массив измененных объектов.

29. Что мы получили
Надежную систему синхронизации.
Push.
API.

30. Итог
Отчуждаемые приложения это удобно.
Update log проще, но менее функционален.

31. Спасибо
Прокофьев Дмитрий, Яндекс