Разработка и реализация сервиса и хранилища для ускорения доступа к данным федеральной адресной системы (ФИАС)

Всего мутации имеют 6 видов операций:

- Create - создание объекта,

- Modify - изменение полей объекта,

- Move - перенос элемента в иерархии (для отображения и логики вложенности некоторых элементов),

- Remove - удаление элемента,

- Close - закрытие элемента, указание на завершение текущей версии,

- Update - закрытие элемента (мутация Close) и создание новой версии элемента,

- Copy - создание новой версии элемента и копирование всех данных из старой версии в новую.

Иерархия сервисов по отслеживанию элементовпредставлена на диаграмме классов на рис. 2.3.4. Для данных из ФИАС ожидается 3 операции: создание, модификация и удаление, таким образом необходимо реализовать наследников для 3 листовых классов на диаграмме (помечены серым).

Рисунок 2.3.4 - Диаграмма классов для сервисов манипуляции данными



2.4 Проектирование общей архитектуры встраиваемого модуля для хранения данных из ФИАС

При проектировании системы были выделены следующие функциональные блоки:

1. Непосредственно, хранилище данных из ФИАС и его реплики,

2. Сервис загрузки и обновления данных ФИАС из реестра,

3. Сервис доступа и модификации данных ФИАС пользователями,

4. Сервис авторизации через Диспетчер Информационной Безопасности (ДИБ). Реализован в отдельном решении и не требует доработок,

5. Основное хранилище НСИ с данными,

6. Сервис доступа и модификации данных НСИ.

Архитектура разрабатываемого модуля и смежных элементов системы представлена на рис. 2.5.1. в виде диаграммы компонентов.

Рисунок 2.4.1 - Схема архитектуры модуля



2.5 Технико-экономическое обоснование

Стоимость разработки системы для хранения и обработки данных ФИАС составит 112 560 рублей. Расчет стоимости приведен в приложении Е.

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

Поскольку необходимо рассчитать разработку части системы работа над которым ведется небольшим количеством сотрудников, данный способ расчета не требует сильных затрат.

2.6 Результаты этапа проектирования системы

На этапе проектирования была создана архитектура встраиваемого в существующую систему модуля для хранения и обработки данных ФИАС, который позволит решить задачу, поставленную ранее и удовлетворить выдвинутые требования.

Были выделены сервисы для загрузки и обновления по расписанию, также был описан сервис для доступа к данным со стороны системы, а также выделены классы, которые необходимы для работы или с которыми взаимодействует модуль для его полноценной работы.

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



Глава 3. Реализация колоночного хранилища адресов и сервисов для манипуляции данными

Документация по архитектуре и требуемым инструментам на проекте «Ведение НСИ и метаданных» подразумевает:

1. В качестве клиент-серверной использование трёхзвенной архитектуры,

2. Microsoft .Net как основное средство разработки,

3. В качестве языка запросов манипулирования данными с пользовательского интерфейса должен использоваться язык с открытым исходным кодом GraphQL

4. Исходные коды модуля должны храниться в распределённой системе управления версиями - Git

Исходя из требований к проекту все сервисы реализованы с использованиемплатформы .NetCore 2.2. Данная платформа выбрана поскольку она позволяет реализовывать кроссплатформенные приложения, и поддерживает высокую скорость выполнения. Версия выбрана исходя из наиболее полных доступных возможностей и длительности поддержки (LTS).

Все программные модули бэкенд сектора (пункты 3.2 и 3.3.) реализованы в виде API - сервисов для повышения гибкости и уменьшения связности модулей.

Все сервисы публикуются на виртуальные сервера с ОС WindowsServer2012 R, однако в последствии планируется переезд на LinuxОС для ускорения работы. Хранилище непосредственно располагается на машине с ОС LinuxUbuntu, поскольку ClickHouseне поддерживает работу на системах отличных от семейства Unix



3.1 Реализация хранилища

Для создания хранилища был подготовлен скрипт на создание базы данных, таблиц и полей, описанных в пункте 2.2.Скрипт представлен на след. странице на рис. 3.1.1. и полностью повторяет структуру БД, описанную на этапе проектирования. Аналогичным образом создаются все остальные таблицы.

Система типов в ClickHouseпохожа на смесь типов Oracleи ООП -языка программирования. По умолчанию все поля не могут равняться null, исключения обрамлены в тег Nullable [6].

Рисунок 3.1.1 - Скрипт для создания таблицы ClickHouse



Как можно заметить, в скрипте фигурирует указание движка (engine) - MergeTree. Движок (илитип) таблицывClickHouseопределяет как и где хранятся данные, логику многопоточности и индексации.

Существует четыре семейства движков в ClickHouse[11]:

1. MergeTree - наиболее универсальные и функциональные движки таблиц для задач с высокой загрузкой, поддерживающие фоновую вставку,

2. Log -движки с минимальной функциональностью, которые наиболее эффективны, когда требуется записать много небольших таблиц (до 1 миллиона строк) и прочитать их позже целиком,

3. Integrating для интеграции с драйверамиODBC/JDBCили другими БД,

4. Special- для повторения структуры данных, например, «множества» или «словарь», а также для оперативного хранения определенных типов. Например, URL или файлы.

Поскольку не реализовано нативного хранилища для данных в форматах GraphQLбыло принято решение использовать MergeTreeдвижок, так как он является наиболее универсальным решением для задач, не подходящих под остальные более типизированные движки.

Для реализации минимально возможного хранилища с использованием СУБД CLickHouse, отвечающего требованиям надежности, доступности и скорости обработки необходимо порядка 5 серверов [10].Для корректной работы реплик (хранение копий данных, метаданных и мониторинг действий) требуется Apache ZooKeeper [5].

В текущем решении данные были распределены на 2 кластера, каждый из которых делится на 2 части. Каждая часть хранится на серверах в двух экземплярах. Например, сервер 1.2 содержит копию информации, с сервера 1.1. [13]

Сервер-балансировщик обеспечивает обработку данных и распараллеливание задач, реализуемый силамиApacheZookeeperи ClickHouse. На самом сервере данные не хранятся, на нем формируется ответ на запрос, исходя из присланных репликами данных.

Сервера, находящиеся в паре, с индексами 1-2 хранят одинаковые данные и периодически синхронизируются, образуя шарды, всего составляя 2 шарда.

На рисунке 3.1.2. представлена топология кластеров с использованием СУБД ClickHouse.

Рисунок 3.1.2 - Топология кластеров ClickHouse

3.2 Реализация сервиса загрузки данных

Для запуска приложения по загрузке данных по расписанию используется Jenkins. Данный способ запуска задач по расписанию выигрывает у сторонних библиотек, таких как Quartz.NETили NCronи Windows Task Scheduler, поскольку не запускает сторонних процессов для мониторинга времени выполнения на самой машине (как делают библиотеки), а также не подвержен сбоям времени при перезагрузках компьютера (как планировщик задач Windows).

При запуске работы в Jenkinsна виртуальной машине идет запрос на скачивание дельта файлов для базы данных и их распаковка. Затем запускается сервис по преобразованию XMLфайлов в структуры, которые в последствии через клиент к ClickHouseдобавляются в базу данных. На данном этапе не используется GraphQLAPI для манипуляции данными, поскольку вставки через клиент к БД быстреемутаций и не требуют обновления кэша при загрузке дельта-данных.

Для считывания файлов используется класс XMLParser<T>. В решении хранятся структуры (struct), описывающие параметры и реализующие IXMLParserable. Указание интерфейса для структуры сделано для введения абстракции, а также для ограничения упаковки (boxing) при проверке типов.

В парсере основным методом преобразования является метод SetAllValues, который с помощью рефлексии получает поля структур и запрашивает типы, которые ожидаются в XMLдокументе с помощью SetValueFromName.

public T SetAllValues(XmlReader xmlreader, T itemForParse)

{

foreach(var item in itemForParse.GetType()

.GetFields

(BindingFlags.NonPublic | BindingFlags.Instance))

{

var fieldName = item.Name;

var fieldValue = xmlreader.GetAttribute(fieldName);

SetValueFromName(fieldName, fieldValue, itemForParse);

}

return itemForParse;

}

С помощью XmlReader - потока для чтения XMLитеративно, получается доступ до дельта-файлов и затем программа проходит по всем элементам иерархии XML, сохраняет данные в структуру и вставляет данные в БД.

Дляскачивания дельта- файлов ФИАС используется метод Net.WebClient.DownloadFileAsync. Он позволяет напрямую скачивать большие файлы. Для первоначальной выгрузки используется WebRequest, поскольку он позволяет скачивать и записывать файл по кускам, не нагружая ОЗУ и процессор. Для скачивания 35 GBархивов ФИАС WebClientне подходит.

Первоначальная загрузка производилась в начале года и более не запускалась, однако дельта-файлы загружаются еженедельно. Дляформирования файла используется базовый адрес реестра ФИАС и хеш файла с последними сохранениями, получение которого реализует APIФИАС.

Ниже представлен листинг загрузчика дельта-файлов. В нем происходит скачивание данных исходя из переменных конфигурационного файла configuration. Внемсодержатся путь до файлов ФИАС в реестре, а также пути до целевой директории, куда необходимо загрузить файл. Послезагрузки файлы разархивируются при помощи командной строки. При возникновении ошибки выбрасывается исключение.

Помимо этого для отслеживания запросов используется трассировщик Jaeger-его логика описана в строках, содержащих _tracer.BuildSpan().Если на каком-то из этапов возникнет исключение, это будет отображено в трассировщике.

using (varscope = _tracer.BuildSpan("СкачиваниефайлаФИАС").StartActive(true))

{

var fiasAdress = new Uri(configuration.GetValue<string>("fiasBaseDownloadUri"));

var fiasFileHash = _fiasHashTracker.GetLastXMLFiasHash();

var fileName = configuration.GetValue<string>("fiasTargetFile");

WebClient fiasWebClient = new WebClient();

fiasWebClient.DownloadFileAsync(fiasAdress+fiasFileHash, fileName);

}

using (var scope = _tracer.BuildSpan("Разархивация справочников").StartActive(true))

{

using (var cmd = new Process())

{

var rarPath = Path.Combine(_contentRarPath, "Rar.exe");

cmd.StartInfo.FileName = "cmd";

cmd.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;

cmd.StartInfo.RedirectStandardOutput = true;

cmd.StartInfo.RedirectStandardError = true;

cmd.StartInfo.CreateNoWindow = true;

cmd.StartInfo.Arguments = $"/C {rarPath} {_fiasLocation} {_reRarCommand}";

cmd.Start();

var output = await cmd.StandardOutput.ReadToEndAsync();

var error = await cmd.StandardError.ReadToEndAsync();

if (output.Contains("ERROR") || (!string.IsNullOrEmpty(error)))

throw new FiasRarException ($"При разархивации произошла ошибка: {error}");

isSuccess = cmd.ExitCode == 0;

}

}

Конфигурационный файл для сервиса загрузки представлен ниже:

{

"FiasTargetFile": "..\\fias.rar",

"ReRarCommand": " ad ilog fias.log e",

"TokenKey": "TokenTokenKey123",

"FiasBaseDownloadUri" : "https://fias-file.nalog.ru/ExportDownloads?file=",

"ContentRarPath" : "C:\\Program Files\\WinRAR",

"PortNumber": "55450",

"CheckAuth": false,

"Tracing": {

"Enable": false,

"ServiceName": "nsi-fias-dev",

"AgentHost": "jaeger.k8s.nsi.local",

"AgentPort": 6831,

"SamplerType": "const"

}

}

3.3 Реализация сервиса для доступа к данным и модификации

Для манипуляций данными GraphQLв НСИ предусмотрено отдельное решение, которое хранит в себе динамически изменяемую схему типов, резолверов и мутаций для всех случаев. Загрузка данных из источников реализуется классами от интерфейса IDataLoader, который отвечает за синхронное и асинхронное получение данных из хранилищ Oracle, Redis, Mongoи ФИАС.

По сути, абстракция IDataLoaderдля логики получения данных скрывает реализацию и фактический источник данных, сервисы не знают откуда получают данные.

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

Аналогичным ранее имеющимся хранилищам образом был реализован загрузчик для ФИАС, визуальное представление интерфейса и его реализаций представлено на рис 3.3.1.

Рисунок 3.3.1 - Интерфейс клиента к данным с точки зрения back-end сервисов

Для получения данных из ФИАС используются объекты Query, которые исходя из типа запрашиваемого объекта подбирают требуемый резолвер для поля. Непосредственно сами резолверы формируют запросы к базе через интерфейсы репозитория и формируют экземпляры объектов.

Для определения типа для каждого справочника используется класс IMultiAttrElement, который сопоставляет элементы схемы типов с нужными резолверами по ключу справочника. В НСИ все справочники имеют уникальный идентификатор. У ФИАС справочника идентификатор равен - t_600000146.

Изначально все типы имеют обязательные поля: PrimaryKey, ChangedUser, ChangeDate, UniqueId. Если справочник версионный еще и поле Version. В остальных случаях, если необходимо в IMultiAttrElement добавляются нужные поля и их типы.

Полядобавляются по шаблону, указанному ниже. Каждоеполеиницилизируется типомFieldс обобщенными типами для бизнес-логики (FIASModel) и обработчиками этих типов в GraphQL (GraphQlFIAS).

varfield = Field<ListGraphType<GraphQlFIAS>, IEnumerable<FIASModel>>()

.Name("idHouse")

.Description("IDHOUSE")

.ResolveAsync(resolver)

.FieldType;

field.Resolver = newFiasResolver <ElementTreeNode, object>(resolver)

Аналогичным образом формируются все требуемые поля, описанные в пункте 2.1. Результаты запросов и типы описаны в пункте 4 главы 3.

Резолверы - обработчики типов для формирования запроса аналогично используются для мутаций и запросов. Большинство резолверов мутаций используют базовые методы для обработки запросов, вызывая методы классов - трекеров, которые в свою очередь описывают логику сбора и группировку нужных данных. Трекеры делятся по операциям создания, удаления, модификации и т. д. Для описанных трех операций были реализованы UpdateFIASChangeTrackerService, CreateFIASChangeTrackerService и DeleteFIASChangeTrackerService. Создание и удаление полностью покрывается методами родительских классов.Класс UpdateFIASChangeTrackerприведен в приложении G.

Резолвер типа для справочника ФИАС приведен в приложении H.

3.4 Результаты этапа реализации и запуск запросов в среде iQraphQL

В ходе реализации были созданы классы для описания бизнес-логики - модель справочника ФИАС (представлено в приложении I).Также описаны тип ФИАС для схемы типов GraphQL и резолверы для запросов и мутаций к справочникам.

Клиентом для запросов GraphQLи доступа до документации на проекте выступает iGraphQL-браузерное решение для обработки запросов.

Для демонстрации работы выбран запрос:на получение данных 2 первых домов в Пермском крае (по коду ОКАТО - 57401000000) с указанием кода города, кода ОКАТО Пермского края, номера дома и версии записи. Запрос выглядит следующим образом:

queryGetPermRegionBuildings( $Arg0: ElementFilterArgument_t_600000146,

$Arg1: pagingInfo) {

t_600000146(filter: $Arg0, paging:$Arg1) {

elements {

version

buildnum

okato

citycode

}

}

}

Variables: {

"Arg0": {

"okato": {

"condition": "equals",

"value": "57401000000"

}

},

"Arg1": {"limit": 2}

}

Запрос состоит из описания формата запроса (query), фильтра (Arg0) и настройки частичного отображения (Arg1). Таким образом запрос трактуется как «получить не более 2 элементов у которых ОКАТО равен 57401000000. Если успешно вывести поля версии, номер дома. ОКАТО и код города». Результат выполнения запроса в iGraphQLпредставлен на след. странице на рис. 3.4.1.

Запрашиваемые поля сохраняют структуру, которая передана в запросе, это одно из преимуществ GraphQL, позволяющее создавать сложные вложенные запросы к множеству различных объектов.

Как можно заметить GraphQL предоставляет также и справочную информацию о типах и их атрибутах. Так, на рис. 3.4.1. справа представлено описание полей типа FIAS_NSIили справочника t_600000146. Аналогичным образом описаны фильтры, атрибуты и связи, или обратные ссылки в терминах GraphQL, между объектами.

Рис. 3.4.1 - Результат выполнения запросов в среде iGraphQL



Глава 4. Тестирование приложения и проведение замеров производительности

В рамках главы 3 была произведена реализация хранилища и сервисов для загрузки и манипуляции данными из хранилища. За сохранность данных в СУБД ClickHouseотвечает непосредственно сама СУБД и ZooKeeper. Однако для проверки корректной работы сервисов необходимо протестировать добавляемые модули на предмет ошибок, а также произвести регрессионное тестирование перед внедрением. Помимо этого, следует замерить скорость выполнения запросов и требуемые вычислительные мощности для разработанного модуля и уже использующихся решений.

Для тестирования мутаций и запросов в НСИ используются модульные тесты. На этапе функционального тестирования проводилось тестирование основных функций сервиса по методу черного ящика.

Прохождение модульных тестов является обязательным условием для публикации решения на вычислительную машину (стенд разработки) через среду интеграции программного обеспеченияJenkins.

Для измерения скорости запросов в Oracleи ClickHouseиспользовались клиенты для указанных СУБД ClickHouseConsoleClientи TOADforOracle. Для Redisконсоль сервера Redisи RedisDesktop.

Указанные инструменты позволяют замерять время выполнения запросов, а также производить трассировку или замерять пропускную способность экземпляра СУБД при указанных настройках.

4.1 Тестирование сервиса загрузки данных ФИАС

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

Таким образом работа описанной внешней системы является проверкой работоспособности и корректности работы сервиса загрузки. Данная система представляет собой модуль в Jenkins, реализующий все описанные функции.

В таблице 4.1.1. приведены обработанные ситуации и реакция системы на обнаружение внештатной ситуации.

Таблица 4.1.1 - Тестирование сервиса загрузки данных ФИАС

№	Ситуации	Реакция
1	Система запущена, сервис загрузки запущен и отработал корректно	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику об успешном завершении работы
2	Система запущена, публикация сервиса не успешна	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику с описанием ошибки публикации
3	Система запущена, публикация успешна, сервис не запущен	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику о том, что сервис не запущен
4	Система запущена, сервис загрузки запущен, доступ до реестра недоступен	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику об ошибке доступа до реестра
5	Система запущена, сервис загрузки запущен, файлы не сохранены из-за ошибки файловой системы	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику об ошибке сохранения и содержание лог-файлов
6	Система запущена, сервис загрузки запущен, файлы сохранены, база данных не доступна	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику о недоступности базы данных
7	Система запущена, сервис загрузки запущен, файлы сохранены, произошла ошибка БД	Отправка в мессенджер в указанный канал о старте работы, Отправка на почту руководителю команды и разработчику об ошибке базы данных и код ошибки
8	Система не запущена	Отсутствие сообщения о старте в обозначенное время говорит о том, что система не запущена

4.2 Тестирование сервиса для доступа к данным из ClickHouse

В таблицах ниже описаны применяемые параметры, ожидаемые значения и реальные результаты. Параметры подставляются в методы тестов с помощью атрибута [Theory] над методом. Реализация метода создания элемента представлена ниже. Остальные методы реализуются аналогично.

publicclassCreateFiasChangeTrackerServiceTests : SystemTestBase<MockStartup>

{

[Theory]

[InlineData({{"ID", 1}, {"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1} })]

[InlineData({{"ID", 2}, {"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1} })]

[InlineData({{"ID", -1}, {"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1 })]

[InlineData({{"ID", 1}, {"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2020"}})]

[InlineData({{"ID", 1}, {"IN_DATE", "05-04-2021" }, {"OUT_DATE", "05-05-2020"}})]

[InlineData({{"ID", 1}, {"IN_DATE", "06-04-2020" }, {"OUT_DATE", "05-04-2020"}

publicasync Task PrepareElements(IEnumerable<KeyValuePair<string, object>> fields)

{

var key = "key";

var nameExpected = "test";

var element = new Dictionary<string, object>

{

{"name", nameExpected}

}.AddRange(fields);

var system = configure();

var dependencyResolver = (IDependencyResolver)system.Services.

GetService(typeof(IDependencyResolver));

var desc = (await dependencyResolver.GetNsiRepository()

.GetDictionaryDescriptionsAsync(x => x.PrimaryKey ==

Consts.FiasDescSprID)).FirstOrDefault();

IChangeTrackerService cs = new CreateService(desc, dependencyResolver);

var context = new ResolveFieldContext<object>

{

Arguments = new Dictionary<string, object>

(

new Dictionary<string, object>

{

{"key", key},

{"element", element}

}

)

};

var result = await cs.TrackElementsAsync(context);

Assert.NotEmpty(result);

var factElement = result[0].Element;

var nameFact = factElement.Name;

Assert.Equal(nameExpected, nameFact);

var isHasVersion = factElement.IsHasVersions;

Assert.False(isHasVersion);

}

}

Результаты тестирования добавления экземпляра ФИАС представлены в таблице 4.2.1.

Таблица 4.2.1 -Тестирование создания элемента

№	Входные данные	Ожидаемый результат	Реальный результат
1	null	Ошибка «Обязательный параметр ID не может быть null»	Ошибка «Обязательный параметр ID не может быть null»
2	{"ID", 1}, {"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	В базу данных добавлена информация с указанными обязательными полями, остальные инициализированы базовыми значениями	В базу данных добавлена информация с указанными обязательными полями, остальные инициализированы базовыми значениями
3	{"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	В базу данных добавлена информация с указанными обязательными полями, ID инициализируется авто инкрементом, остальные инициализированы базовыми значениями	В базу данных добавлена информация с указанными обязательными полями, ID инициализируется авто инкрементом, остальные инициализированы базовыми значениями
4	{"ID", 1}, {"VERSION_ID", -1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	Не найдено элементов с указанной версией	Не найдено элементов с указанной версией
5	{"ID", -1}, {"VERSION_ID", -1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	Неверный ключ элемента	Неверный ключ элемента
6	{{"ID", 1}, {"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2020"}	Не указана версия элемента	Не указана версия элемента
7	{{"ID", 1}, {"VERSION_ID", 1},{"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2020"}	В базу данных добавлена информация с указанными обязательными полями, остальные инициализированы базовыми значениями	В базу данных добавлена информация с указанными обязательными полями, остальные инициализированы базовыми значениями
8	{{"ID", 1}, {"VERSION_ID", -},{"IN_DATE", "05-04-2021" }, {"OUT_DATE", "05-05-2020"}	Дата начала не может быть больше даты окончания	Дата начала не может быть больше даты окончания
9	{{"ID", 1}, {"VERSION_ID", 1},{"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2019"}	Дата окончания не может быть меньше даты начала	Дата окончания не может быть меньше даты начала

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

Параметры тестирования модификации элементов ФИАС приведено в таблице 4.2.2.

Таблица 4.2.2 -Тестирование модификации элемента

№	Входные данные	Ожидаемый результат	Реальный результат
1	null	Ошибка на уровне GraphQL	Ошибка на уровне GraphQL
2	{"ID", 1}, {"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	В БД изменена информация с указанными обязательными полями	В БД изменена информация с указанными обязательными полями
3	{"VERSION_ID", 1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	Ошибка «не указан обязательный ключ PrimaryKey»	Ошибка «не указан обязательный ключ PrimaryKey»
4	{"ID", 1}, {"VERSION_ID", -1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	Не найдено элементов с указанной версией	Не найдено элементов с указанной версией
5	{"ID", -1}, {"VERSION_ID", -1}, {"IN_DATE", 1}, {"OUT_DATE", 1}	Не найдено элементов с указанным ключом ID	Не найдено элементов с указанным ключом ID
6	{{"ID", 1}, {"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2020"}	Не указана версия элемента	Не указана версия элемента
7	{{"ID", 1}, {"VERSION_ID", -1},{"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2020"}, params [{key:value}]	В БД обновлена информация с указанными обязательными полями, остальные инициализированы из коллекции params	В БД обновлена информация с указанными обязательными полями, остальные инициализированы из коллекции params
8	{{"ID", 1}, {"VERSION_ID", -1},{"IN_DATE", "05-04-2021" }, {"OUT_DATE", "05-05-2020"}	Дата начала не может быть больше даты окончания	Дата начала не может быть больше даты окончания
9	{{"ID", 1}, {"VERSION_ID", -1},{"IN_DATE", "05-04-2020" }, {"OUT_DATE", "05-05-2019"}	Дата окончания не может быть меньше даты начала	Дата окончания не может быть меньше даты начала

4.3 Тесты производительности и сравнение полученного решения

В качестве задачи было составлено три запроса на выборку данныхк таблице, количество элементов в которой составляло 8 746 420.

Первый запрос, запрос недвижимости, сгруппированный по субъектам ОКТМО (общероссийский классификатор территорий муниципальных образований). Запрашиваемые поля: почтовый индекс, классификаторы муниципальных образований - ОКАТО, ОКТМО, Номер дома и строения, дата внесения изменений.

SELECT HOUSENUMFULL, OKATO, OKTMO, HOUSENUM, BUILDNUM, INDATE

FROM FIAS_NSI

GROUP BY OKTMO,HOUSENUMFULL, OKATO, OKTMO, HOUSENUM, BUILDNUM, INDATE

ORDER BY OKTMO,HOUSENUM, INDATE;

Второй запрос - запрос данных о состоянии зданий Пермского края (OKTMO =57000000), с указанием ключа физического лица- владельца строения, а также номер дома и строения, дата внесения изменений.

SELECT STATSTATUS, OKTMO, COUNT(), IFNSFL, HOUSENUM, BUILDNUM, UPDATEDATE,

FROM data

WHERE OKTMO = 57000000

GROUP BY CREATED_TS, STATSTATUS,

ORDERBYSTATSTATUS, UPDATEDATE;

Третий запрос - аналогичный первому, однако, данные в нем сгруппированы по дате добавления в реестр (год и месяц добавления)

SELECT HOUSENUMFULL, OKATO, OKTMO, HOUSENUM, BUILDNUM, INDATE

FROM FIAS_NSI

GROUP BY OKTMO,HOUSENUMFULL, OKATO, OKTMO, HOUSENUM, BUILDNUM, INDATE

ORDER BY OKTMO,HOUSENUM, ToDate(INDATE).Year;

В таблице 4.3.1 приведены результаты выполнения запросов к СУБД Oracle и ClickHouse.

Однако для ускорения доступа до данных из Oracleприменяется Redis, представляющий надстройку и хранящий некоторые записи в памяти. Те же запросы исполнились для системы Oracle+Redisс учетом сохраненного кэша (hotcache), результат составил 0,07; 1,26и0,59для запросов соответственно.

Таблица 4.3.1 - Сравнение времени выполнения запросов

Запрос	Oracle (сек)	ClickHouse (сек)	Oracle + Redis (сек)
Запрос элементов ОКТМО	6,1	0,636	0,07
Запрос элементов с ОКТМО - Пермский край	7,8	0,758	0,126
Запрос элементов ОКТМО с датой добавления в реестр	6,75	0,589	0,059

Сравнение времени выполнения запросов приведено графически на рис 4.3.1.

Как можно заметить, ClickHouse проигрывает по скорости запросов InMemoryСУБД Redis, однако проигрывает незначительно и позволяет избежать необходимости разделять на шарды и хранить порядка 300 GBданных в оперативной памяти. Помимо этого, в запросах фигурирует только одна таблица. Поэтому при обращении к другим таблицам или операциям группировки (join) у Redisдополнительно возрастет время на обращение ко внешним сетевым ресурсам или шардам, в то время как ClickHouseпозволяет хранить все данные на одном устройстве как обычная реляционная СУБД.

Рисунок 4.3.1 - Сравнение времени выполнения запросов на одной таблице

В среднем исходя из логированных файлов Redisследует что среднее время выполнения запроса на одном шарде без обращения к внешним составляет 0,2 секунды, а при обращении к 1-3 внешним узлам время вырастает до 0,5 секунд. ClickHouseже работает стабильно на уровне 0,5-0,7 секунд на запрос с большой выборкой данных (больше 50 MB в поле запросов).

Таким образом ClickHouseпозволяет ускорить доступ к данным в более чем 10 раз по сравнению с реляционной СУБДOracle и выполнять запросысо скоростью близкой к базам данных, работающим в оперативной памяти. При этом появляется возможность снизить требования к хранилищу и вычислительным ресурсам до требований к типовым реляционным СУБД.



Заключение

Итогом данной работы стало колоночное хранилище ФИАС на проекте НСИ, а также .Netсервисы для загрузки и получения доступа к данным, реализованные на языке C#. Хранилище и сервисы является частью системы НСИ для предоставления справочной информации в системе ГАС ПС.

Были выполнены задачи данной работы: проанализированы существующие решения, и на основе анализа решений и требований к системе НСИ сформированы требования для разработанного модуля. Было спроектировано и разработано хранилище данных ФИАС, а также сервисы для загрузки и манипуляции данными в хранилище. При разработке использовались контракты, существующие в рамках проекта, а все разработанные модули прошли функциональное и интеграционное тестирование. Выполнение всех поставленных задач обеспечило достижение поставленной цели.

Колоночная СУБД ClickHouseпозволила ускорить доступ к данным, не меняя существующую архитектуру приложений и избежать проблем, которые возникали при ранних решениях. Далее благодаря сервисному подходу, были интегрированы модули для автономной и периодической актуализации данных в хранилище, а также предоставлена возможность доступа к данным с учетом текущего протокола сетевого взаимодействия - GraphQL.

Созданное приложение позволяет хранить информацию об элементах БД ФИАС - адресообразующих объектах и данных о недвижимости Российской Федерации, а также различную информацию для поддержки бизнес-логики - версионирование и метаданные. Поиск по объектам был реализован с помощью древовидного MergeTree индекса, что позволяет быстро обрабатывать данные в больших объемах. Данная индексация показала преимущество перед типовым реляционным поиском с полным последовательным перебором.

Актуальность разработанной системы подтверждена актом о внедрении системы в компанию и приведено в приложении J.

Возможной дальнейшей работой является внедрения Docker- образа хранилища, для абстрагирования от вычислительного узла, упрощения развертывания и поддержки.



Библиографический список

1. Нереляционные данные и базы данных NoSQL, документация Microsoft[Электронный ресурс]. - Режим доступа: https://docs.microsoft.com/ru-ru/azure/architecture/data-guide/big-data/non-relational-data, свободный. - (дата обращения: 20.03.2020).

2. Дейт К. Дж. Введение в системы баз данных - Introduction to Database Systems. -- 8-е изд. -- М.: Вильямс, 2005. -- 1328 с. -- ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.).

3. Сведения о составе информации Государственного адресного реестра федеральной информационной адресной системы от 09.06.2016 [Электронный ресурс]. - Режим доступа: https://fias.nalog.ru/, свободный. -(дата обращения: 20.03.2020).

4. Сведения о составе информации Государственного адресного реестра федеральной информационной адресной системы от 09.06.2016 [Электронный ресурс]. - Режим доступа: https://fias.nalog.ru/Docs/Описание службы получения обновлений.doc, свободный. - (дата обращения: 20.03.2020).

5. Руководство Apache ZooKeeper. Официальный сайт. [Электронный ресурс]. - Режим доступа: https://zookeeper.apache.org/doc/r3.5.2-alpha, свободный. -(дата обращения: 12.03.2020).

6. Руководство Yandex ClickHouse. Официальный сайт. [Электронный ресурс]. - Режим доступа: https://clickhouse.yandex/reference_ru.html, свободный. - (дата обращения: 12.03.2020)

7. КорнушкоВ., ДударевВ. Software development for distributed system of Russian databases for electronics materials // Information Theories & Applications 2006№ 13, C. 121-126.

8. МонируззаманА., ХуссейнС. NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison // International Journal of Database Theory and Application.2013 В. 6. №. 4, С. 1-15.

9. Ланей, Д., ДжейнА. 100 Data and Analytics Predictions Through // Gartner Inc, 2017.

10. КальоноваО.,АкпаралиевН., ПерлИ. Design Of Specialized Storage for Heterogeneous Project Data» // Сборник23 конференции Open Innovations Associate. СПБ. 2015.

11. ПаскулаМ. "Persisting Objects in Redis Key-Value Database" [Электронныйресурс]. - Режимдоступа: https://www.cs.helsinki.fi/u/paksula/misc/redis.pdf, свободный. - (датаобращения: 21.04.2020).

12. ВазилеМ.,АволиоГ., И. СоловьевEvaluating InfluxDB and ClickHouse database technologies for improvements of the ATLAS operational monitoring data // The ATLAS collaboration, CERN, 2019. С. 5.

13. Method for routing data packets using an IP address based in GEO position: патСША №69 805 662 B2Б // Д. Мелик, В.М. Шнайдер, Л.Д., опубл. 03 Марта 2001.

14. ЮдаЮ. Business intelligence and NoSql databases //Information Systems in Management. 2012. В. 1 .С. 25-37.

15. ЭрикхХ., Сернадас, СAbstract object types for databases // Сборникмеждународнойконференции «International Workshop on Object-Oriented Database Systems». 2005. С. 144-149.

16. JunqueiraF., Reed B. ZooKeeper Distributed Process Coordination // O'Reilly Media. 2014. С. 246.

Размещено на Allbest.ru

...