Какие существуют особенности репликации данных из распределенных БД
Репликация нужна когда, компания имеет сложную распределенную структуру, но всем филиалам необходимо работать в едином информационном пространстве. Дает надежность - в случае поломки канала связи, филиалы имеют возможность продолжения независимой работы.
Вопрос читателя журнала «Современные технологии делопроизводства и документооборота»: "Какие существуют особенности репликации данных из распределенных БД?"
Начнем с определения понятия «репликация». Репликация — это процесс, под которым понимается копирование данных (например, содержимого базы данных – БД) из одного источника в другой. При репликации изменения, сделанные в одной копии объекта, могут быть распространены в другие копии. Таким образом, происходит синхронизация содержимого нескольких копий. Это нужно в тех случаях, когда, компания имеет сложную распределенную структуру, но всем филиалам необходимо работать в едином информационном пространстве. Это дает надежность – в случае поломки канала связи филиалы имеют возможность продолжения работы независимо. Это дает экономию – меньше требований к каналам связи между филиалами.
Различают два вида репликации: онлайн и офлайн (еще их называют синхронная и асинхронная).
Первый тип настраивается для тех баз данных, которые соединены между собой каналами связи с хорошей пропускной способностью. И все изменения в этих БД происходят в реальном времени: как только произошло изменение информации в одной БД, оно синхронизируется (копируется) в другую базу. Например, документ отредактировали и сохранили в одном из филиалов компании, а в результате измененный документ будут иметь все филиалы.
В этом случае нужно учитывать:
1. Время выполнения операции будет увеличено из-за того, что в момент сохранения данных, они реплицируются на другие базы данных.
2. Характерны проблемы, связанные с доступностью данных.
3. Данный вид репликации возможен только для каналов связи с высокой пропускную способностью.
Если базы данных соединены каналами с низкой пропускной способностью, настраивается офлайн репликация, то есть копирование данных происходит через заданный промежуток времени. Это значит, что все изменения в базах данных копятся до определенного времени, а потом передаются все вместе в другую базу данных пакетом. Такой вариант решает недостатки первого, но увеличивается время между периодами синхронизации.
Для репликации характерны следующие особенности:
1. Для однозначного определения записи в распределенных базах данных должны иметь уникальный идентификатор в рамках нескольких БД.
2. Необходима одинаковая структура хранения данных в БД.
3. Необходимо учитывать репликацию связанных записей справочников. Например, при заведении нового контрагента в справочнике «Организации» мы создаем еще и новую запись в справочнике «Города». При репликации новой записи справочника Организации также должна быть передана и запись справочника «Города» (если ранее ее не было в целевой БД) для обеспечения корректности реплицируемых данных.
4. При репликации БД могут возникать конфликты данных
● удаление используемой записи;
● удаление изменяемой записи;
● изменение измененной записи;
● изменение несуществующей записи;
● неуникальность кода или наименования записи справочника;
● отсутствие записи справочника;
● отсутствие прав на выполнение действия.
Но надо отметить, что современные системы позволяют быстро разрешать подобные конфликты, в том числе автоматически.
5. Нужно заранее продумывать ситуации возникновения дублей и стараться их предотвратить. Так как синхронизация происходит с некоторой задержкой во времени, возможна ситуация, когда в нескольких базах заведут одну и ту же запись, например, в справочнике «Организации». Еще пример дублирования: «ООО Альфа» и «Альфа ООО» – для системы это две разные записи. Избежать дублирования данных возможно, если следовать единым правилам ведения записей в базах данных и разграничением прав, то есть это решается организационными мерами.
К недостаткам репликации можно отнести то, что часть времени копии данных не идентичны базовым данным, поэтому пользователи должны учитывать, когда именно были синхронизированы эти данные.
Источник: Журнал "Современные технологии делопроизводства и документооборота"
Похожие статьи
Комментарии 18
Неправильно. Очевидно, что пакетный режим возможен только при асинхронной репликации, но это не значит, что он обязателен. Никто не мешает вам синхронизировать данные по отдельной транзакции.
Не "при репликации БД", а при "репликации БД DIRECTUM". В современном мире, как правило, приходится решать совсем другие проблемы. Например, выбирать, чем жертвовать при реализации CAP-теоремы.
Хорошая какая теорема... а я то и не знал...
По теме...
Ксения, что думаете насчет применения в ECM NoSQL баз? Документ - атрибутированная сущность. Никакие справочники нам не нужны, мы же не учетную систему делаем. А реплицировать/масштабировать NoSQL данные куда проще... никаких конфликтов, никаких проблем...
Не знаю, появится ли Максим Смирнов в комментариях, но его мнение интересно, и он его уже высказывал.
Виктор, спасибо за вопрос. Если честно, я не технический специалист и не могу оценить весь масштаб предлагаемой Вами технологии, но она безусловно интересна и мне было бы интересно обсуждение этой темы.
У каждой технологии своя область применения и свои задачи. За примером, далеко ходить не будем, NoSQL, принцип работы с данными описанный в этой парадигме - стар как мир (привет из прошлого века), однако её активное развитие началось лишь с подачи Google, после того как перед ними встала задача по обработке своих больших данных. И характер этих данных разительно отличается от того с чем работает ECM - система, да и задачи другие. Возьмем количество данных, которыми оперирует Google или Amazon за сутки и сравним с любой внедренной ECM системой - комментарии будут излишни.
У NoSQL много плюсов, но в тоже время много и минусов. Если и рассматривать её применение в ECM, то явно не из-за возможности сделать превосходную репликацию = ). Нужны другие более масштабные задачи.
Можно долго рассказывать о потенциальных возможностях NoSQL в ECM, однако это выходит за рамки проблемы этого поста = )
Я думаю, что миграция СЭД/ECM решений к нереляционным хранилищам происходить будет, но достаточно медленно. Причем дело здесь не в больших данных, а в общих данных, например упомянутом в статье справочнике городов. Зачем он нужен в СЭД если есть ФИАС. Рано или поздно у каждого населенного пункта появится свой URI, на который можно будет ссылаться. Надеюсь, то же самое случится и с внутрикорпоративными справочниками.
Я уже где-то писал, что идея документооборота должна выродиться в идею «шины документов», т.е. такой среды, в которой документы не «оборачиваются», а остаются весь жизненный цикл на своем месте. Однажды появившись, документ публикуется, приобретает неизменный адрес (URL) и начинает накапливать историю обращений и обновлений. В этом состоит изначальная идея web.
Технически реализовать это совсем не сложно, но сложно принять такую модель. Потому большинство СЭД и работает в описанной в статье парадигме и прорыва в этом сегменте, как я понимаю, не ожидается.
Дискуссия получила активное продолжение на ФБ. Идея публикации документа близка тем кто занимается системами для госов. Их документы должны быть публичными, иметь возможность доступа людям с ранзыми правами. И вот тут возникают вопросы разграничения прав, вопросы что должна хранить система, что не должна (где граница требуемых данных) и т.д.
Вот интерсный кусок высказывания Александр Кирсанов
Владение адресом не равно владению правами. В GooglDocs реализовано. Но базой данных. Нужен атрибутивный документ (неотьемлемая часть документа).
Соответствующие права:
А - автор.
В - владение.(редактирование)
Р - распоряжение. (назначение маршрута)
П - пользование. (получение маршрута с правами комментария и меток)
Ч - чтение.
Э - электронной подписи.
З - закрытие. (закрытие процесса, передача в архив, скачивание, контроль процесса).
Нужны статусы Документа:
- Создан.
- Направлен на согласование.
- Направлен на подпись.
- Подписан.
- Направлен на исполнение.
- Исполнен.
- Закрыт.
- Архивирован.
Примерная схема реализации прав.
- Инициатор. А - право создать и оставить документ в черновиках, не пуская по маршруту.
- Для инициации процесса Р добавляет маршрут.
- Пользователь принимает или отказывается от прав. Приняв (открыв) он переводит Документ в режим совместного пользования и делает невозможным удаление Документа. Права А становятся ничтожными.
- Пользователи согласовывают документ согласно прав В Р П Ч З.
- Любой Р может удалять Р В П Ч других из своего списка "равных" (замыкать Документ на себя).
- Любой Р может добавлять права Р В П Ч любому "личному" сертификату (привлекать к исполнению Документа).
- Любой Р может добавлять права любому "групповому" сертификату (пускать на дополнительный маршрут).
- Любой Р может отправить "на подпись" - Поставить статус Э, что делает ничтожным любое Владение. Документ больше не редактируется.
- Блокировка для Э может быть отменена с правами З если нет подписей.
- Подписав Документ уполномоченное лицо Э делает возможным все остальные права З.
- При отсутствии второй подписи З может отозвать Э.
- После подписания всеми сторонами Пользователи исполняют документ согласно прав Р П Ч.
- После исполнения процесса с правами З процесс закрывается. Доступ предоставляется только З и Э.
- В любой момент каждый может отказаться от прав. Документ с нулевыми правами удаляется.
https://www.facebook.com/groups/ecm.group.rus/permalink/763169947078578/
А можно уточнить какая дискуссия имеется в виду?
Я вижу две темы:
Какую из этих тем продолжает приведенный кусок? Или это так лихо дискуссия перетекла в обсуждение чего-то третьего?
Да, дискуссия пошла по третьей ветке :) Отталкиваяь от идеи Максима Смирнова "Однажды появившись, документ публикуется, приобретает неизменный адрес (URL) и начинает накапливать историю обращений и обновлений." Именно это оказалось близко госсектору и с точки зрения разработки ЕСИА (Единая система идентификации и аутентификации).
Как то я в прошлый раз упустил:
Виктор, а почему ECM/СЭД - это не учетная система? По мне так, вполне себе учетная, просто объекты учета - документы (где-то электронные, а где-то бумажные).
"Учетная" - это только часть функций ECM - смотрим Gartner.
Это я вошел в терминологию компании автора. Под учетной имеется ввиду финансово-учетная, предназначенная для работы, прежде всего, с структурированными данными.
Я вообще к чему про NoSQL сказал? Тема ведь про репликацию. Так вот к тому, что на практике главная проблема реплицировать именно реляционные данные. А в системе близкой автору реляционность есть основа хранения информации, что мне кажется не всегда оправдано, а часто просто неправильно (например: не до конца ясно, что делать при смене названия Организации, просто править запись нельзя, ведь документы созданы для "старого" названия). Хотелось бы чтобы к задаче распределенной работы и, в частности, репликации подошли не только в лоб, но и архитектурно как-то.
И какие из перечисленных там 6 функций не являются учетными?
Это вообще беда многих статей EJ (имется в виду авторские, а не перепечатка): за основу берется терминология и архитектура заложенная в одну единственную систему, но в самой статье это никак не отражается.
Так что все верно - здесь изложены принципы и проблемы репликации, реализованной в одной конкретной системе.
Исходя из изложенного мною выше, я бы на это рассчитывать особо не стал. Более того, устоявшийся формат EJ и не предполагает здесь появления сколько-нибудь серьезных технических статей, только поверхностные (ознакомительные).
А что-то радикально изменилось?
Я подводил Ксению к мысли, что описанные проблемы репликации свойственны скорее учетным системам, а в ее случае причиной есть генезис платформы. Я далек от мысли, что надо все сломать и сделать не-реляционным. Но подумать в эту сторону можно... Какие плюсы для документов? Их будет легко реплицировать, они смогут быть автономными, а значит работать "офф-лайн", карточка будет доступна в мобильных приложениях. Из тех же облачных сервисов мы без проблем будем "перетягивать" документы. Сможем, например, делать подобие OneDrive Pro. Много плюсов... И как-то на ECM больше похоже. Это же не EDI. Хотя идея что документы реплицируются, а вот метаданные сидят в облаке не лишена смысла.
Минусы тоже есть. В теории сложнее искать в некоторых сценариях. Но все эти сценарии опять же скорее из мира учетных систем. И фасетная таксономия для упорядочивания информации не единственная.