- •2. Решение задач кластеризации с помощью сетей Кохонена.
- •3. Язык uml
- •4. Моделирование бизнес-процессов
- •5.Обратные связи
- •6. Основные организационные структуры
- •7. Интерфейс графических устройств cdi. Кисть, карандаш, примитивы.
- •8. Понятие ресурса. Ресурс меню, курсор, пиктограмма.
- •9. Модальные и не модальные панели диалога.
- •10 Формы записи алгоритмов в визуальной среде программирования.
- •11. Этапы проектирования программной системы в визуальной среде программирования.
- •12. Визуальное объектно-ориентированное программирование. Инкапсуляция, наследование, полиморфизм.
- •Инкапсуляция
- •Наследование
- •Полиморфизм
- •13. Схема работы web-приложения и web-браузера по протоколу http: бщий вид запроса и ответа http, метод, представление, заголовки запроса, ответа и представления
- •14. Методы http get и post, понятие безопасного и идемпотентного метода, заголовки запроса http: Host, Accept, User-Agent и Referer
- •15. Файловая система procfs
- •16. Средства командной строки по управлению учетными записями пользователей в Linux
- •17. Команда man Источники справочной информации
- •Страницы интерактивного руководства man
- •18. Односторонние функции. Псевдослучайные генераторы.
- •19. Умножение на основе классов вычетов
- •20. Избыточное кодирование
- •Балансировка вычислительной нагрузки Причины возникновения несбалансированной нагрузки
- •Статическая и динамическая балансировки
- •Постановка задачи динамической балансировки
- •Методология практического решения задачи балансировки
- •Оценка загрузки
- •Инициализация балансировки загрузки
- •Принятие решений в процессе балансировки
- •Перемещение объектов
- •Архитектура подсистемы балансировки
- •23. Распределенное хранение информации. Распределенные базы данных. Правила Дейта для распределенных бд. Фрагментация. Репликация. Протокол двухфазной фиксации транзакций.
- •Фрагментация
- •Репликация
- •Схемы владения данными в распределенной бд
- •24. Волновые алгоритмы распространения информации. Требования к волновому алгоритму. Алгоритм для кольцевой структуры. Алгоритм для дерева. Алгоритм голосования.
- •Initial
- •Initial
- •25. Алгоритмы выбора сайтов (координаторов). Алгоритм смещения. Выборы с помощью алгоритма для деревьев. Алгоритмы выбора для кольцевых структур (Лелана, Чанга-Робертса).
Схемы владения данными в распределенной бд
Выше, рассматривая распределенную базу данных, состоящую из локальных сайтов, мы неявно предполагали, что для каждой единицы данных существует вполне определенный единственный сайт, владеющий этими данными. Т.е. что каждый источник данных приписан одному сайту.
Однако, реальная ситуация не всегда соответствует этой схеме. Существуют мобильные пользователи (и источники данных), перемещающиеся от сайта к сайту. Отдельные данные могут передаваться с сайта на сайт в соответствии с некоторыми бизнес-процессами. При этом происходит не копирование, а именно передача, без сохранения данных на старом сайте.
В литературе рассматриваются несколько схем владения данными:
ведущий/ведомый;
рабочий поток;
симметричная репликация.
Схема "ведущий/ведомый" фактически уже была описана. Она заключается в том, что у любых данных имеется единственный владелец (ведущий), остальные пользователи этих данных (ведомые) производят изменения в своих копиях, может быть, асинхронно после изменения данных ведущим. Причем задержка в изменениях для разных пользователей может быть различной и даже, в крайнем случае, не производиться. Пример такого рода связан с использованием информации из Интернета. Полученная копия какого-либо документа с некоторого сайта используется в текущей работе, и в дальнейшем оказывается не нужна пользователю, даже если на сайте этот документ изменился.
Схема "рабочий поток" ориентирована на базы данных, обслуживающие бизнес-процессы. Бизнес-процесс может исполняться несколькими работниками организации, располагающими на различных сайтах. Комплект данных, сопровождающий бизнес-процесс, претерпевает изменения во время выполнения технологических операций процесса. Кроме этого, комплект данных передается с сайта на сайт, где и выполняются эти технологические операции. Логично признать, что при этом перемещении меняются и владельцы комплекта данных.
В схеме "рабочий поток" у любых данных, также как и в схеме "ведущий/ведомый", имеется единственный владелец. Однако в схеме "ведущий/ведомый" – это постоянное владение, а в схеме "рабочий поток" – временное владение, со сменой владельца. Но там и там в любой момент времени только один сайт имеет право менять конкретные данные, остальные могут только читать эти данные.
В схеме "симметричной репликации" все сайты, использующие копии БД, равноправны, т.е. все являются, одновременно, и владельцами и пользователями. Такая схема наиболее динамична и удобна для работников организации, выполняющих действия с одними и теми же записями в распределенной базе данных. При этом работники выступают и в качестве пользователей данных (чтение) и в качестве источников данных (запись, изменения). Каждый может изменять данные, но и каждый несет ответственность за достоверность изменений.
С точки зрения реализации схема "симметричной репликации" наиболее сложна. Она требует механизма выявления и разрешения конфликтов. Конфликты возникают при асинхронной репликации, если между двумя соседними моментами времени ti и ti+1 синхронизации копий БД пользователи, по крайней мере, на двух сайтах произвели изменения одних и тех же данных. Если, конечно, они произвели одинаковые изменения и знают об этом, то проблем нет. Но чаще изменения неодинаковы и/или без взаимного информирования (по какому-либо каналу передачи данных, не входящему в систему).
Примеры конфликтов.
На двух сайтах внесли различные записи под одним и тем же номером в структуру данных FIFO – очередь ("лист ожидания"). Кто "стоит в очереди" раньше?
В некоторое поле, предназначенное для накопления суммы, и имевшее после синхронизации значение σ на двух сайтах добавили слагаемые σ1 и σ 2, соответственно. Как провести обновление данных при очередной синхронизации копий? А если преобразование было более сложным, чем суммирование?
На двух сайтах удалили различные записи. При очередной синхронизации нужно принимать во внимание оба удаления или только одно? Если одно, то которое?
Применяются следующие механизмы разрешения:
Установление для каждого сайта приоритета. При конфликте принимаются во внимание изменения, произведенные сайтом с наиболее высоким приоритетом.
Пересчет изменений в базах. В приведенном выше примере на сайтах появились значения (σ + σ1) и (σ + σ2). При очередной синхронизации можно вычислить новое значение поля как сумму старого значения и всех приращений в копиях: σ + ((σ + σ1) – σ) + ((σ + σ2) – σ).
Экстремальное значение. Подобно предыдущему механизму, но для случая, когда в определенном поле фиксируется экстремальное (минимальное или максимальное) значение. В этом случае из всех копий при синхронизации выбирается копия с экстремальным значением и принимается за новое состояние базы данных (или фрагмента).
Самое позднее изменение копии. Изменения на разных сайтах производились в разное время, следовательно, имеют различную актуальность. Естественно выбрать наиболее актуальную копию для последующей работы.
Разумеется, это только некоторые возможные механизмы. В зависимости от вида изменений на сайтах следует использовать другие механизмы, вплоть до неавтоматизированного (ручного) сравнения изменений в копиях и принятия решения по корректировке копий при синхронизации. Последний вариант может использоваться при относительно редкой синхронизации, например, раз в сутки.