Какие существуют особенности репликации данных из распределенных БД
Вопрос читателя журнала «Современные технологии делопроизводства и документооборота»: "Какие существуют особенности репликации данных из распределенных БД?"
Начнем с определения понятия «репликация». Репликация — это процесс, под которым понимается копирование данных (например, содержимого базы данных – БД) из одного источника в другой. При репликации изменения, сделанные в одной копии объекта, могут быть распространены в другие копии. Таким образом, происходит синхронизация содержимого нескольких копий. Это нужно в тех случаях, когда, компания имеет сложную распределенную структуру, но всем филиалам необходимо работать в едином информационном пространстве. Это дает надежность – в случае поломки канала связи филиалы имеют возможность продолжения работы независимо. Это дает экономию – меньше требований к каналам связи между филиалами.
Различают два вида репликации: онлайн и офлайн (еще их называют синхронная и асинхронная).
Первый тип настраивается для тех баз данных, которые соединены между собой каналами связи с хорошей пропускной способностью. И все изменения в этих БД происходят в реальном времени: как только произошло изменение информации в одной БД, оно синхронизируется (копируется) в другую базу. Например, документ отредактировали и сохранили в одном из филиалов компании, а в результате измененный документ будут иметь все филиалы.
В этом случае нужно учитывать:
1. Время выполнения операции будет увеличено из-за того, что в момент сохранения данных, они реплицируются на другие базы данных.
2. Характерны проблемы, связанные с доступностью данных.
3. Данный вид репликации возможен только для каналов связи с высокой пропускную способностью.
Если базы данных соединены каналами с низкой пропускной способностью, настраивается офлайн репликация, то есть копирование данных происходит через заданный промежуток времени. Это значит, что все изменения в базах данных копятся до определенного времени, а потом передаются все вместе в другую базу данных пакетом. Такой вариант решает недостатки первого, но увеличивается время между периодами синхронизации.
Для репликации характерны следующие особенности:
1. Для однозначного определения записи в распределенных базах данных должны иметь уникальный идентификатор в рамках нескольких БД.
2. Необходима одинаковая структура хранения данных в БД.
3. Необходимо учитывать репликацию связанных записей справочников. Например, при заведении нового контрагента в справочнике «Организации» мы создаем еще и новую запись в справочнике «Города». При репликации новой записи справочника Организации также должна быть передана и запись справочника «Города» (если ранее ее не было в целевой БД) для обеспечения корректности реплицируемых данных.
4. При репликации БД могут возникать конфликты данных
● удаление используемой записи;
● удаление изменяемой записи;
● изменение измененной записи;
● изменение несуществующей записи;
● неуникальность кода или наименования записи справочника;
● отсутствие записи справочника;
● отсутствие прав на выполнение действия.
Но надо отметить, что современные системы позволяют быстро разрешать подобные конфликты, в том числе автоматически.
5. Нужно заранее продумывать ситуации возникновения дублей и стараться их предотвратить. Так как синхронизация происходит с некоторой задержкой во времени, возможна ситуация, когда в нескольких базах заведут одну и ту же запись, например, в справочнике «Организации». Еще пример дублирования: «ООО Альфа» и «Альфа ООО» – для системы это две разные записи. Избежать дублирования данных возможно, если следовать единым правилам ведения записей в базах данных и разграничением прав, то есть это решается организационными мерами.
К недостаткам репликации можно отнести то, что часть времени копии данных не идентичны базовым данным, поэтому пользователи должны учитывать, когда именно были синхронизированы эти данные.
Источник: Журнал "Современные технологии делопроизводства и документооборота"
Неправильно. Очевидно, что пакетный режим возможен только при асинхронной репликации, но это не значит, что он обязателен. Никто не мешает вам синхронизировать данные по отдельной транзакции.
Не "при репликации БД", а при "репликации БД 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. Хотя идея что документы реплицируются, а вот метаданные сидят в облаке не лишена смысла.
Минусы тоже есть. В теории сложнее искать в некоторых сценариях. Но все эти сценарии опять же скорее из мира учетных систем. И фасетная таксономия для упорядочивания информации не единственная.