Главная » Блоги Экспертов И ИТ-Компаний » Идентификация объектов в системе ЛЕТОГРАФ
Начинаем публикацию статей о практике внедрения СЭД 2 года назад

Идентификация объектов в системе ЛЕТОГРАФ

Разработчики платформы документооборота ЛЕТОГРАФ рассказывают о том, как обеспечена уникальная идентификация объектов рамках системы и возможность их передачи во внешний мир.

При создании высоконагруженных решений, на которые в первую очередь ориентирована система ЛЕТОГРАФ, необходимо обеспечивать их высокую производительность. Говоря о высокой производительности в современных условиях важно понимать, что речь идет не только и не столько о вычислительной мощности отдельных серверов, сколько о масштабировании — увеличении количества серверов и распределении вычислительной нагрузки между ними.

В случае систем документооборота, имеющих дело с сотнями тысяч документов, распределенных по вычислительным ресурсам, одним из важнейших элементов решения задачи горизонтального масштабирования  и обеспечения работоспособности системы является идентификации объектов. Ведь система ЛЕТОГРАФ представляет собой, по сути, большое количество объектов, связанных между собой в соответствии с требованиями конкретной прикладной задачи. Поэтому ключевой для работы системы является возможность правильно и эффективно идентифицировать объекты. Фактически, решение задачи идентификации объектов и их индексации позволяет построить информационную систему любого масштаба. Решение задачи индексации рассмотрено в отдельном материале, ниже в данной статье мы расскажем об особенностях идентификации объектов в ЛЕТОГРАФ.

Как устроен идентификатор объекта

Каждый объект системы ЛЕТОГРАФ снабжается идентификатором. Эти идентификаторы бывают двух видов — “локальные” и “глобальные”. Что это такое?

“Локальный” идентификатор используется непосредственно в данной конкретной базе данных системы ЛЕТОГРАФ. Его задача — идентифицировать объект так, чтобы он отличался от всех остальных объектов, расположенных в той же системе.

Глобальный идентификатор потребуется, например, если есть две разные системы на базе ЛЕТОГРАФ (“тестовая” и “боевая” конфигурации СЭД в одной организации или СЭД в двух разных организациях) и необходимо перенести настройки или осуществить взаимодействие систем. Действительно, на уровне одной системы объект однозначно идентифицирован, но в “соседней” системе значение уникального локального идентификатора может повторяться. Чтобы получить уникальный идентификатор объекта среди двух и более систем, необходимо его дополнить неким “уникальным идентификатором системы”. Такой составной идентификатор будет уже “глобальным” и позволит однозначно идентифицировать объект при миграции, интеграции или синхронизации данных.

Глобальная идентификация объектов также требуется, если осуществляется взаимодействие с внешней системой с помощью передачи данных в формате XML. Соответственно, задача глобального уникального идентификатора — обеспечить при выгрузке объекта во “внешний мир” и в ходе любых интеграционных действий, чтобы нигде и никогда не появился объект с таким же идентификатором, созданный другой системой.

Руководствуясь этими задачами, мы разработали систему идентификации, которая позволяет уникальным образом идентифицировать любой объект и, что крайне важно, обеспечить связки между объектами. Любой идентификатор — это последовательность символов тип «строка». Первая часть локального идентификатора состоит из числового индекса, символа «@» и кода хранилища.

Важно отметить, что ЛЕТОГРАФ работает с разными группами данных, которые обрабатываются по разному. Следует различать “системные данные” (используемые при отправке уведомлений пользователям по электронной почте),  “конфигурационные” (описывающие информационную модель системы) и “пользовательские” (данные регистрационных карточек и присоединенные файлы). Некоторые данные только добавляются и остаются неизменными (например, записи в журнале действий пользователей), к некоторым обращение производится часто (оперативные документы), к некоторым редко (архивные документы).

Для того, чтобы повысить производительность системы, данные внутри одной системы разделяются по разным хранилищам (хранилища могут располагаться как на одном сервере, так и на нескольких серверах). Разделения по различным хранилищам реализовано как на системном уровне кода (уведомления и документы хранятся в разных хранилищах), так и на уровне конфигурации: предусмотрена возможность определить, в каком хранилище будут размещены документы, созданные на основе каждого шаблона. Например, более часто используемые  документы, созданные на основе шаблона “Входящий” и “Договор” размещаются в одном хранилище, а менее востребованные документы, созданные на основе шаблона “Архивный” - в другом. Третье направление - возможность внутри каждого хранилища разделить данные на независимые группы. Например, относящиеся к разным организациям (данные каждой организации хранятся в своей “группе” в хранилище). Такое разделение позволяет не только разместить данные на разных серверах, но и в ходе  работы системы обращаться только к “нужным” данным. Например, при построении отчета выборка осуществляется только в хранилище, где размещаются документы и только в подгруппе, соответствующей организации пользователя.

Давайте обсудим эти три способа подробнее.

Разделение по видам данных

Опыт выполнения крупных территориально-распределенных проектов позволяет нам определить, какие данные необходимо “разделять” по разным хранилищам. В разных хранилищах размещаются, например системные объекты (которые предназначены для описания системных настроек, информационных моделей и прикладных задач), каталоги пользователей (объекты, которые предназначены для идентификации пользователей и присвоения им пользовательских атрибутов, таких как права доступа) и журналы (объекты, которые обеспечивают протоколирование действий пользователей, выполненных в рамках системы). Разделение по видам данных настраивается в зависимости от потребностей заказчика и масштаба системы. Можно хранить журналы действий пользователей на одном сервере, типы данных — на другом сервере, типы пользователей — отдельно от них, и т.д. Это приведет к более равномерному использованию вычислительных мощностей и повысит отклик системы.

Разделение на уровне шаблонов объектов

Шаблоны в системе ЛЕТОГРАФ служат для описания информационной модели — набора объектов, их реквизитов и связей между ними. Раздельное хранение объектов в зависимости от их шаблонов дает возможность серьезно снизить нагрузку на каждую единицу вычислительных мощностей. В процессе настройки шаблонов определяется то, в каких хранилищах будет находиться объекты тех или иных шаблонов. В ходе эксплуатации системы все эти настройки можно модифицировать, вводя новые хранилища для шаблона объектов — в этом случае все ранее созданные объекты останутся в прежнем хранилище, а вновь созданные объекты будут появляться уже в новом хранилище. Последний факт крайне важен при создании решений, обеспечивающих хранение больших объемов данных. Например, в одном из наших проектов размер хранилища с документами пользователей превысил 15тб. Время на восстановление данных из полной резервной копии превышало любые регламентные значения. После того, как мы разделили данные на несколько хранилищ (данные размещались в хранилищах, упорядоченные по дате создания), основная работа велась только с “последним” хранилищем (данные в прочих хранилищах практически не менялись). В случае необходимости резервная копия в первую очередь восстанавливалась для “последнего хранилища”. 

Шардинг

В общем случае шардингом называют разделение базы данных на отдельные части с тем, чтобы каждую из них можно было вынести на отдельный сервер. В отличие от первых двух видов разделений, описанных выше, шардинг позволяет разделять базу данных на отдельные части по любым признакам, не относящимся к типам данных и шаблонам. Это могут быть любые параметры, которые мы считаем важными для данной системы. Например, в рамках холдинга может быть принято решение о хранении объектов, созданных или принадлежащих каждой отдельной организации холдинга, на выделенном сервере — при этом в рамках всего холдинга обеспечивается единое информационное пространство, единая система идентификации и поиска для всего множества объектов холдинга.

Технологии разделения данных

Система идентификации учитывает структуру хранения данных. Гибкие механизмы организации хранения в свою очередь позволяют “выровнять” вычислительную нагрузку в рамках решения, обеспечивать горизонтальное масштабирование базы данных и поддержку раздельного хранения логических множеств. Это значит — равномерно распределить хранение данных внутри каждого сервера по разным физическим дискам, а внутри кластера серверов — по различным серверам баз данных. Система ЛЕТОГРАФ делает это тремя способами — по видам данных, на уровне шаблонов объектов и на уровне значений объектов. Наш опыт показывает, что этих трех видов разделения баз данных достаточно для того, чтобы эффективно их сбалансировать, и добиться оптимальной производительности системы.

Важно понимать, что горизонтальное масштабирование и снижение нагрузок на дисковые подсистемы путем разделения объектов по хранилищам основаны на функциональности платформы InterSystems Caché, на ее технологиях мэппинга. Технологии мэппинга, которыми мы активно пользуемся, позволяют определять алгоритм разнесения данных, находящихся логически в единой базе данных, по физическим базам, размещенных на различных серверах. Когда мы в рамках очередного проекта создаем хранилище, необходимое для решения той или иной прикладной задачи, мы пользуемся возможностями самой СУБД InterSystems Caché, которая позволяет хранить данные на различных дисковых системах.

Таким образом, пользователь системы ЛЕТОГРАФ имеет возможность в зависимости от требований прикладной задачи варьировать параметры использования хранилищ — как на этапе проектирования, так и на этапе эксплуатации. Каждое хранилище имеет свой уникальный идентификатор, и этом дает нам возможность использовать локальные идентификаторы, как уникальные в рамках прикладной системы и однозначно идентифицировать любой объект — что, собственно, и требуется от системы идентификации.

Перенос объектов и глобальные идентификаторы

В крупных проектах, как правило, используется три версии системы: версия для разработки, версия для тестирования и “боевая” версия, с которой работают пользователи. Версии обычно расположены на разных серверах (или кластерах серверов).

Добавление новых функциональных возможностей (или внесение изменений в действующие функциональные возможности) производится сначала на версии для разработки, затем изменения переносятся на версию для тестирования и только затем на боевую версию. Изменения между версиями переносятся в автоматическом режиме.  Именно для обеспечения такого технологического цикла и нужны в первую очередь системы глобальных уникальных идентификаторов.

В основе глобального идентификатора лежит уникальный числовой код, который формируется по специальному алгоритму. При переносе множества объектов используется формат XML. Объекты, которые выгружаются во внешний мир из системы (это могут быть и системные и прикладные объекты) преобразуются в так называемые “пакеты переноса”. Каждый пакет переноса получает свой глобальный уникальный идентификатор, поэтому в каждой системе, которая породила эти объекты, существует однозначная связь между локальным идентификатором и глобальным уникальным идентификатором. При повторном переносе объектов из одной системы в другую вносятся изменения в значения атрибутов тех объектов, которые совпадают по глобальному уникальному идентификатору.

Важно, что подобный подход позволяет однозначно идентифицировать “одинаковые объекты” в разных системах. Для конкретного проекта это означает, что если на версии для разработки в шаблон входящего документа добавили дополнительный реквизит, то не надо его добавлять вручную сначала на тестовую версию, а потом на боевую. Будет сформирован пакет переноса, в котором будет указан глобальный идентификатор объекта и сведения о его изменениях. В соответствии с этой информацией в системе-приемнике будет найден необходимый объект и произведены операции по его изменению.

Описанные механизмы обеспечивают корректный перенос данных из системы в систему и сохранение ссылочной целостность.

Резюме

Мы не зря уделяем задаче идентификации объектов столь пристальное внимание. Высоконагруженные системы, на разработке которых мы специализируемся, требуют особого внимания как к решению задач горизонтального и вертикального масштабирования, так и к решению собственно прикладных задач.

Сегодня ни одна из систем электронного документооборота, имеющихся на рынке, не обладает похожими возможностями: не существует развернутых решений, которые обеспечивали бы возможность горизонтального масштабирования на уровне баз данных и на уровне серверов приложений с уникальной идентификацией всех объектов.

Все классические примеры основаны на использовании стандартных технологий баз данных и серверов приложений, поэтому и проблемы у них классические. Если некая платформа строится на базе традиционной SQL-базы данных с учетом определенной прикладной области, у нее нет проблем с описанием этой предметной области, шаблонов и т.п., но возникает необходимость трансформировать данные из сложной информационной модели, постоянно обрабатывать метаинформацию и «раскладывать» по неким универсальным табличным структурам как саму эту информацию, так и создаваемые объекты. При этом на базу данных ложится огромная нагрузка по формированию индексов, и задачи их горизонтального масштабирования решаются очень сложно.

Система ЛЕТОГРАФ справляется с этими проблемами, поскольку она не предъявляет никаких требований к табличному предоставлению настроек, метаинформации и самих данных. Глубоко понимая требования и возможности технологической платформы InterSystems Caché, мы знаем, как нам организовать сложные деревья данных и максимально эффективно и быстро работать с ними.


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
+7 (495) 741-48-08
---

О компании

Компания ЛЕТОГРАФ занимается разработкой и внедрением одноименной системы управления документами, автоматизации бизнес-процессов и интеграции приложений. Основные направления деятельности - развитие платформы ЛЕТОГРАФ и реализация масштабных проектов внедрения.

Компания основана в 2003 и за время своего существования прошла путь от небольших проектов на 5-10 рабочих мест, позволяющих осуществлять регистрацию и поиск документов, до масштабных решений, в которых несколько тысяч пользователей в десятках и сотнях территориально-распределенных подразделений выполняют все операции по работе с документами.

О платформе ЛЕТОГРАФ

ЛЕТОГРАФ – готовое централизованное расширяемое решение для автоматизации документооборота и архива территориально-распределенных организаций. С помощью платформы ЛЕТОГРАФ могут быть решены все задачи по управлению документами: от «классического» документооборота и архива до управления корпоративным контентом (ЕСМ).

Масштабируемые отказоустойчивые решения на базе платформы ЛЕТОГРАФ устанавливаются централизованно на кластере серверов и реализуют на практике концепцию управления «большими данными». Пользователи работают с системой в интерфейсе веб-браузера и получают доступ к информации в режиме он-лайн со стационарных или мобильных устройств.

 

Система ЛЕТОГРАФ унифицирует работу со всеми электронными и бумажными документами организации (входящими, исходящими, внутренними, кадровыми, архивными, договорами, счетами, заявками и пр.), а также может быть интегрирована с корпоративными и внешними системами.

Адрес: Россия, 105066, г. Москва, ул. Бауманская, д. 6 

Контактное лицо: Александр Иванов, специалист по маркетингу


Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>