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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного

образовательного учреждения высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

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

по направлению подготовки 09.03.04 Программная инженерия

образовательная программа «Программная инженерия»

Гильман Максим

Пермь, 2020 год



Аннотация

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

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

Работа включает 97страниц основного текста, 21 иллюстрацию, 6 таблиц, 10 приложений. Библиографический список - 16 наименований.

2020 г. Кафедра информационных технологий в бизнесе.



Оглавление

• Введение
• Глава 1. Анализ предметной области. Задача обработки данных об адресах
• 1.1 Виды хранилищ для работы с адресными данными
• 1.2 Требования к хранилищу и моделирование системы в UML
• 1.3 Описание формата хранения данных в реестре ФИАС
• 1.4 Описание подходов к обработке адресов. Реляционный подход
• 1.4.1 Реляционная модель. Обработка транзакций OLTP
• 1.4.2 Реляционная модель. Аналитическая обработка OLAP
• 1.5 Описание подходов к обработке адресов. Не реляционные подходы
• 1.6 Отбор подходящих решений
• 1.7 Существующие реализации в рамках ГАС ПС - НСИ
• 1.8 Выбор реализации столбчатой (колоночной) СУБД
• Глава 2. Проектирование хранилища адресов
• 2.1 Проектирование колоночного хранилища ФИАС и логики первоначального заполнения
• 2.2 Проектирование работы сервиса обновления по расписанию
• 2.3 Проектирование диаграмм классов для сервисов доступа к данным
• 2.4 Проектирование общей архитектуры встраиваемого модуля для хранения данных из ФИАС
• 2.5 Технико-экономическое обоснование
• 2.6 Результаты этапа проектирования системы
• Глава 3. Реализация колоночного хранилища адресов и сервисов для манипуляции данными
• 3.1 Реализация хранилища
• 3.2 Реализация сервиса загрузки данных
• 3.3 Реализация сервиса для доступа к данным и модификации
• 3.4 Результаты этапа реализации и запуск запросов в среде iQraphQL
• Глава 4. Тестирование приложения и проведение замеров производительности
• 4.1 Тестирование сервиса загрузки данных ФИАС
• 4.2 Тестирование сервиса для доступа к данным из ClickHouse
• 4.3 Тесты производительности и сравнение полученного решения54
• Заключение
• Библиографический список
• Приложение A.состав элементов таблиц выгрузки файлов БД ФИАС виде файлов (таблиц) DBF
• Приложение B.описание прецедентов
• Приложение C.полный атрибутивный состав таблиц справочника ФИАС НСИ
• Приложение D.техническое задание
• Приложение E.технико-экономическое обоснование
• Приложение F.руководство программиста
• Приложение G. листинг UpdateFIASChangeTracker
• Приложение H. листинг FiasResolver
• Приложение I. модель данных ФИАС
• ПриложениеJ. акто внедрении


Введение

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

С развитием вычислительной мощности техники появляется возможность автоматизировано обрабатывать большие массивы данных. За последние десять лет на рынке появилось множество хранилищ данных- СУБД как с закрытым, так и открытым кодом, а также с различным подходом к обработке данных: аналитический и транзакционный, табличный и не табличный (т. н. NoSQL).

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

Государственная автоматизированная система Российской Федерации «Правосудие» (ГАС Правосудие, ГАС ПС) -- информационная система, предоставляющая свободную информацию о судебном делопроизводстве в России. В рамках реализации описанной системы возникла потребность во взаимодействии с Федеральной информационной адресной системой (ФИАС).

Использующиеся в проекте программные продукты (Redis, OracleDBMS, MongoDB и д.р.) были опробованы для решения поставленной задачи, однако результаты их работы не подходят под требования времени выполнения и затрат на вычисления. Обычные табличные решения работают слишком медленно и плохо масштабируются; in-memory словари, использующиеся для кэширования данных, требуют множество ресурсов для поддержания, а NoSQL СУБД не встраиваются в текущую экосистему приложений. Поэтому было принято решение опробовать новый подход к организации хранилища - колоночные СУБД.

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

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

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

Объектом работы является хранение адресной информации. Предметом - использование колоночных баз данных для решения задачи о хранении адресов недвижимости из реестра ФИАС.

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

В соответствии с целью были сформулированы следующие задачи:

1.Проанализировать существующие технологии хранения больших массивов информации об адресах:

1.1.Рассмотреть способы передачи, подходы к поиску и индексации в базах данных недвижимости.

1.2.Сформулировать требования для разрабатываемой системы.

1.3.Согласовать требования со стороной компании - работодателя.

1.4.Подготовить документацию по внедрению компонента в существующую систему приложений.

2.Произвести проектирование хранилища для хранения адресов:

2.1.Произвести проектирование колоночного хранилища, как представления над реляционной СУБД.

2.2.Спроектировать схему для GraphQL для запросов к базе данных.

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

3.Реализовать хранилище адресов:

3.1.Реализовать поиск для элементов хранилища.

3.2.Реализовать обновление хранилища по расписанию.

3.3.Реализовать интерфейс для чтения данных в виде сервиса для GraphQL.

4.Протестировать и оценить работоспособность системы:

4.1.Провести модульное и интеграционное тестирование перед публикацией разработанного решения.

4.2.Провести нагрузочное и регрессионное тестирование для проверки адекватности внедрения колоночного подхода.

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

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

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

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



Глава 1. Анализ предметной области. Задача обработки данных об адресах

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

В рамках реализации проекта «Государственная Автоматизированная Система Правовой Статистики - ГАС ПС» возникла необходимость хранить данные об адресных объектах Российской Федерации. Данная задача реализовывалась на базе решения проекта НСИ - Нормативно - Справочная Информация. В НСИ хранятся все справочники и метаданные системы ГАС ПС. Данная часть системы является высоконагруженной и требуется во многих частях ГАС ПС.

Требование хранить адресную информацию происходит от того, что система является распределенной по всем субъектам РФ и необходимо привязывать адресные элементы к различным объектам системы, например подразделение, место оформления уголовного дела и так далее.

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

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

1.1 Виды хранилищ для работы с адресными данными

Само по себе хранилище данных (Data Warehouse) [2] определяется как предметно-ориентированный, интегрированный, зависимый от времени набор данных, предназначенный для поддержки принятия решений различными группами пользователей. [7]. В хранилище могут храниться как базовые данные, которые впоследствии объединяют внешние механизмы в зависимости от запроса, либо же наоборот, само хранилище может содержать агрегированные данные и в некоторых случаях производить их группировку самостоятельно.

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

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

До недавнего времени практически единственным способом для хранения и обработки данных являлись реляционные СУБД. Однако с развитием технологий, увеличивались и области, в которых не хватало функциональности обычного табличного хранилища. Направление NoSQL (NotonlySQL-не только SQL) сформировалось в качестве попытки найти решения в реализации СУБД, которые имели бы существенные отличия от моделей реляционных баз данных.

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

Фирма Microsoft предлагает следующее разделение [1]:

1. Реляционные хранилища,

2. Не реляционные или NoSQLхранилища[12]:

2.1. Документо-ориентированные хранилища,

2.2. Столбчатые хранилища,

2.3. Словари пар «ключ - значение»,

2.4. Хранилища данных графов,

2.5. Хранилища временных рядов,

2.6. Хранилища данных объектов,

2.7. Хранилища данных внешних индексов.

Более подробное описание подходов к решению конкретной задачи - хранение и обработки данных из ФИАС представлены в (Главе 2). Однако прежде всего, необходимо рассмотреть формат данных, которые необходимо хранить и обрабатывать, а также требуемые способы взаимодействия с хранилищем, чтобы корректно выбрать инструмент для решения поставленной задачи

1.2 Требования к хранилищу и моделирование системы вUML

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

В результате анализа требований сформирована диаграмма использований, которая представлена на рис 1.2.1. полное описание прецедентов представлено в приложении B.

Хранилище должно быть заполнено данными, импортируемыми из таблиц реестра ФИАС: ADDROBJ и HOUSE.

Обновление справочника должно выполняться пользователем (администратором) НСИ по мере размещения на сайте ФНС России актуальных файлов с дельта данными, не реже чем один раз в неделю. Загрузка и обработка файлов с дельта-данными БД ФИАС должна выполняться последовательно, от самого позднего по дате, необработанного архивного файла, до актуального.

Сведения об актуальных файлах с дельта-данными и файле VerDate.txt, в котором хранится дата, за которую была сделана актуальная выгрузка БД ФИАС расположены на сайте ФНС России по адресу [3]. После проведения операции обновления справочника ФИАС из дельта-данных БД ФИАС должен быть сформирован лог-файл, содержащий информацию о выполненной операции, сформирован статус выполнения операции: «выполнена успешно», «выполнена с ошибками».



Рисунок 1.2.1 - Диаграмма использований для хранилища ФИАС в рамках проекта ГАС ПС НСИ

Справочник ФИАС должен быть добавлен в компонент «Ведение справочников НСИ и метаданных» и доступен для отображения пользователю в разделе справочников. Пример отображения данных ФИАС на веб-стороне представлен в виде макета на рис 1.2.2.



Рисунок 1.2.2 - Макет "Список субъектов РФ"в ФИАС

Помимо отображения необходимо реализовать поиск по данным:

1. Поиск по уровням подчиненности адресных объектов,

2. Поиск по кодам административно-территориального или муниципального деления (ОКАТО, ОКТМО),

3. Выборка данных для фильтрации на веб-странице.

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

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

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

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

1.3 Описание формата хранения данных в реестре ФИАС

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

Сведения о составе информации в реестре ФИАС строго формализованы и документированы. В реестре существует разделение на адресообразующие элементы (страну, субъект РФ, населенный пункт и т. д.) и объекты адресации, т. е. непосредственно объекты недвижимости.

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

В ФИАС необходимые данные представлены в виде нескольких таблиц:

- Таблица ADDROBJ (Object) содержит коды, наименования и типы адресообразующих элементов (регионы; округа; районы города, поселки городского типа, сельские населенные пункты; элементы планировочной структуры, элементы улично-дорожной сети.

- Таблица STEAD (Stead) содержит коды, кадастровые номера земельных участков.

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

- Таблица ROOM (Room) содержит записи с номерами помещений, квартир, офисов, комнат, а также их кадастровые номера.

Полный перечень полей в таблицах представлен в приложении A.

Из документации по ФИАС следует, что требуемые данные предоставляются в табличном виде, более того, они уже разделены на таблицы. Таким образом естественным первым шагом является попытка использовать наименее затратный способ хранения табличных данных - реляционные СУБД[9].

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

1.4 Описание подходов к обработке данных об адресах. Реляционный подход

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

1.4.1 Реляционная модель. Обработка транзакций OLTP

Реляционная модель данных подразумевает разделение информации на таблицы, взаимодействие которых определяется отношениями или связами (дословно с англ. relation- отношение) [10]. Частой задачей при работе с табличными СУБД является сбор данных (из одного или нескольких источников) определенного формата и перенос информации в другое хранилище (или несколько хранилищ).

Управление данными в рамках обработки небольших пакетов - транзакций, называется оперативной обработкой транзакций (OLTP). Бизнес-транзакцией является любая информация, связанная с деятельностью организации: информация о статусе или номере заказа, о самом пользователе, запись о конкретном доме в реестре адресов.

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

OLTP - подход накладывает ряд требований и ограничений (рис. 1.4.1.) к организации хранилища: прежде всего, это табличная, реляционная модель,

Рисунок 1.4.1 - Требования к транзакционной модели данных

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

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

1.4.2 Реляционная модель. Аналитическая обработка OLAP

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

Существует два основных типа моделирования аналитических хранилищ:

- Многомерная.

В данном случае используется конструкции моделирования кубы, измерения и меры.

- Табличная

Для этой модели характерны реляционные конструкции - модели, таблицы и столбцы.

Аналитическая обработка зачастую формирует следующие требования (рис. 1.4.2.):



Рисунок 1.4.2 - Требования к аналитической модели данных

Поскольку ожидается редкая запись в хранилище ФИАС (система обновляется раз в неделю), а также частые запросы, преимущества OLAPподхода могут быть использованы при построении хранилища ФИАС. Ввиду сложной структуры OLAP, вставка и обновление в таких СУБД продолжительна и затратна по ресурсам, но, поскольку загрузка выполняется по расписанию (в ночное время) это никак не скажется на нагрузке вычислительного узла.

1.5 Описание подходов к обработке данных. Не реляционные подходы

Не реляционные хранилища - системы для хранения данных, формат обработки которых отличен от табличного, где записью является строка в таблице. Выделяют несколько типов NoSQLхранилищ:

1. Документоориентированные,

2. Столбчатые,

3. Хранилища пар «ключ-значение»,

4. Графовые хранилища

5. Базы данных временных рядов,

6. Хранилища объектов,

7. Хранилища внешних индексов.

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

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

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

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

Таким образом из подходящих СУБД к рассмотрению предложены реляционные (OLAPи OLTP), столбчатые, хранилища - кэш-словари и NoSQLхранилища структуры XML или ключ - значение.

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

1.5.1 Документо -ориентированные хранилища

Документо- ориентированные СУБД, как и объектно-ориентированные СУБД позволяют отражать сущности предметных областей на базу данных без использования узкого круга элементов, предоставляемых реляционной СУБД. Таким образом не нужно создавать вырожденные таблицы - связки, а также появляется возможность хранить данные разного типа в качестве значения [15].

Рисунок 1.5.1 - Пример хранения документо- ориентированной СУБД

Как правило под документами в ДОСУБД подразумеваются все данные об одной сущности, причем хранящиеся в свободной форме (рис. 1.5.1). Документ хранится в виде JSONили XML, каждый элемент может иметь как скалярное значение, так и коллекцию типа «родитель - потомок».

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

Чаще всего, ДО база данных при изменении перезаписывает весь документ, но некоторые базы данных поддерживают обновления «на месте», изменяя значения только запрашиваемых полей.

Таким образом для данных из ФИАС, например, документом может являться муниципальный округ с ключом ОКАТО (идентификатор края или области), а значением - всеми его параметрами в виде JSON/BSONили XML/

1.5.2Реляционный подход. Колоночная или столбчатая СУБД

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

Подобный формат хранения можно представить следующим образом:

[A1, B1, C1] - [A2, B2, C2] - [A3, B3, C3],

где A,B,C -- это столбцы или поля, а числа - номера строк (записей).

Преимущества данного подхода описаны выше в пункте 1.2.1. Однако с течением времени с развитием аналитических информационных систем и хранилищ данных обнаружилось, что для транзакционных систем свойственно мелкие операции с изменением всех полей записи, а для аналитических - работа крупными блоками, но с запросом нескольких (в среднем 7-8) полей в одном запросе. Таким образом совместить скорость обработки и выборку только некоторых элементов в каждом из подходов невозможно.

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

Решение данной проблемы предлагается колоночными СУБД, которые совмещают в себе плюсы OLAPи OLTPподходов. С точки зрения клиента - данные представлены в виде таблиц, можно использовать SQL- синтаксис, но физически таблицы являются группировкой столбцов, каждая из которых представляет собой колонку - мини-таблицу из одного поля (рис. 1.5.2).

В сравнение с моделью строчного хранения в строках поля хранятся на диске последовательно друг за другом:

[A1, A2, A3] - [B1, B2, B3] -[C1, C2, C3].

Такая организация позволяет «из коробки», т. е. нативными средствами СУБД запрашивать и исполнять только нужные поля из всех. Что снижает нагрузку на каналы ввода вывода примерно в N/Mраз, где N- количество полей в таблицу, M -количество запрашиваемых полей.

Рисунок 1.5.2 - Форматы строчного и столбчатого хранилищ

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

1.5.3 Хранилища пар «ключ- значение»

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

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

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

1.6 Отбор подходящих решений

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

Таблица 1.6.1 - Сравнение типов СУБД для хранения данных адресов РФ

Параметр	Реляционная (строковая) СУБД	Реляционная Столбчатая СУБД	Кэш-словарь	NoSQL ДО СУБД
Элемент хранения	Строка	Столбец	Пара ключ-значение	Документ
Нормализация	Требуется для поддержки корректной работы	Ввиду OLAP обработки данные денормализуются	Не требуется	Не требуется
Первичный ключ	Любой набор полей	Любой набор полей, но обязательноTimestamp с датой создания/изменения	Ключ записи	Ключ записи
Индексация	Любой набор полей	Любой набор полей, обязательно ключ партиции, если есть	По ключу	По ключу
Хранилище	Все данные внутри схемы в дисковой памяти вычислительного узла	Данные могут быть распределены по дискам различных узлов. Маршрутизацию реализует сама СУБД	Данные хранятся в RAM, периодически сохраняясь на диск	Данные хранятся на диске в виде коллекции документов в одном месте
Скорость запроса всех данных	Быстрая	Средняя	Средняя	Медленная
Скорость запроса части данных без Join	Средняя	Быстрая	Очень быстрая	Средняя
Скорость группировки (join)	Быстрая	Быстрая	Быстрая	Недоступно, данные в одной коллекции
Скорость фильтрации	Средняя	Очень быстрая	Не доступно	Медленная
Отказоустойчивость	Средняя	Высокая	Низкая	Средняя
Схема	Схемы заранее определены	Схемы заранее определены	Динамическая схема	Динамическая схема
Масштабирование	Вертикальное	Горизонтальное	Горизонтальное	Горизонтальное
Транзакции	Поддерживается	Поддерживается	Поддерживается	Поддерживается
Использование в приложениях	Подходит для интенсивной среды запросов, где данные структурированы	Для табличных данных, при редких операциях вставки, но частых и не полных запросах	Для надстройки над другой СУБДускорения доступа данным	Для неструктурированных данных



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

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

Документоориентированные СУБД подходят для хранения данных ФИАС, однако плохо работают с кэш-словарями, поскольку данные в ФИАС табличные - и структура NoSQLхранилищ не принесет прироста к скорости обработки.

Реляционные СУБД лучше всего подходят для хранения табличных данных, а исходя из требований к хранилищу (частые запросы на чтение, редкая вставка и запросы не по всем полям) OLAPподход, предлагаемый колоночными СУБД, может лучше всего подойти для решения данной задачи.

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

Изначально, реляционной СУБД для хранения большей части информации в проектах компании, была выбрана OracleСУБД. Помимоэтого, для ускорения доступа до данных с веб-части системы используется несколько словарей кэширования разного уровня (RedisиWeb-cacheProxy. Также, в процессе перехода на open-sourceПО в компании была предпринята попытка перенести часть данных из хранилища в NoSQLхранилище -MongoDB.

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

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

1.7 Существующие реализации в рамках ГАС ПС - НСИ

Основное реляционное хранилище - Oracleотлично подходит для хранения табличных данных. Проверка показала, что данные ФИАС занимают в этой СУБД примерно 35 GBпамяти.

Все таблицы организованы в одну схему -FIASи представлены в таблице 1.7.1. Для получения списка таблиц выполняется запрос:

SELECTrownum, table_name

FROMall_tables

WHEREowner ='FIAS'

Таблица 1.7.1 - Созданные таблицы в СУБД Oracle

Номер строки	Имя таблицы
1	FIAS_STATUS
2	FIAS_GUIDS
3	FIAS_HOUSESTATESTATUS
4	FIAS_IDS
5	FIAS_LOADS
6	FIAS_NSI_GEO
7	FIAS_NSI_GEO_CLOB
8	FIAS_HOUSE_BUF
9	FIAS_HSTSTAT_BUF
10	FIAS_NDOCTYPE_BUF
11	FIAS_OPERSTAT_BUF
12	FIAS_ROOMTYPE_BUF
13	FIAS_SOCRBASE_BUF
14	FIAS_STEAD_BUF
15	FIAS_STRSTAT_BUF
16	FIAS_ACTUALSTATUS
17	FIAS_ADDRESSOBJECTTYPE
18	FIAS_ACTSTAT_BUF
19	FIAS_ADDROBJ_BUF

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

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

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

Таким образом для реализации хранилища ФИАС в текущем формате с помощью Oracleи Redis необходимо либо неадекватно большое количество оперативной памяти, либо добавление новых вычислительных узлов, либо замена Redisна СУБД, схожую по скорости, но менее требовательную по памяти.

Также для хранения адресов можно использовать MongoDB, данная СУБД использует множества типа ключ-значение и имеет динамическую схему, которая лучше всего подходит для неструктурированных данных.

Были произведены замеры скорости обработки запросов на примере таблицы HOUSE из ФИАС в MongoDBи системе Redis + Oracle. Замеры производились на вычислительных машинах с ОС WindowsServer 12 R2, 2 CPUна 4 ядра, 8 GBRAM, 256 SSDдискового пространства.

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

ДляСУБДOracleзапрос выглядел следующим образом:

SELECT STATSTATUS,

OKTMO, COUNT (*),

IFNSFL, HOUSENUM,

BUILDNUM, UPDATEDATE,

FROM fias.HOUSE

WHERE OKTMO = 57000000

GROUP BY STATSTATUS,

ORDER BY STATSTATUS, UPDATEDATE;

В Redisдоступ до запрошенных данных осуществляется аналогично запросу значения по ключу из словаря:

_redisDict[okatoDictKey]

ДляMongoDBзапрос выглядитследующим образом:

db.fias.find({OKATO: 57000000}).

group({key:{STATSTATUS: true}, initial: {total : 0},

reduce : function (curr, res){res.total += 1}})

.sort({UPDATEDATE:1})

По мере измерения изменялся параметр - количество параллельно запущенных потоков на обработку - от 1 до 256 единоразово. Наибольший прирост в скорости был обнаружен при 128 потоков (порядка 27 000 и 7500 операций в секунду для Oracleи Mongoсоответственно), см. рис 1.7.1.

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



Рисунок1.7.1 - Сравнение производительности запроса на выборку для таблицы HOUSEв различных СУБД

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

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

В описанных выше решениях, применяемых на проекте не рассмотрен колоночный тип СУБД. Колоночные хранилища используются в компании, но их не применяли в рамках НСИ и для решения задачи о хранении адресов.

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

1.8Выбор реализации столбчатой (колоночной) СУБД

Исследуя опыт Питера Бонца в [4] можно указать 4 основных решения на рынке колоночных СУБД - Vertica, ClickHouseи InfiniDBи Hive (с надстройкой колоночных СУБД). Для выбора наилучшего решения были произведены замеры скорости выполнения на 10 млн тестовых записей из реестра ФИАСтаблицы House.

Данные замеры выполнялись на второй раз запуска, чтобы избежать некоренных замеров при старте или инициализации хранилищ, давая возможность СУБД закэшировать часть структуры (избегая coldcache запросов).Фактические настройки сервера с данными: 8GB RAM, 2 CPU, 8 GP SWAP, Ubuntu 19 x64.Результаты приведены в таблице 1.8.1. Поскольку имя таблицы во всех СУБД одинаковое - часть запроса «FROMHOUSE» опущена.

Таблица 1.8.1 - Сравнение времени выполнения запросов в столбчатых БД

Запрос	ClickHouse (v. 1.1.53960)	Vertica (v 7.1.1.)	InfiniDB EE (v 3.6.23)	Hive (v 0.11)
SELECT count ()	0,011	0,033	0,34	105,13
SELECT count () where id =:id	0,009	0,044	0,3	36,43
SELECT uniq (IFNSFL)	0,065	0,167	1,23	35,14
SELECT uniq(okato)	0,009	0,083	28,07	51,26
SELECT min (CreateDate), max (CreateDate)	0,047	0,061	1,04	34,13
SELECT okato, count () group by okato	0,427	1,837	4,54	85,06
SELECT ifnsul, uniq(strstatus) group by ifnsul	0,508	4,314	8,18	102,87



На рис 1.8.1 представлено графическое представление суммарного времени выполнения. Так ClickHouseв 6, 40 и 418 раз быстрее обрабатывает запросы с данными из ФИАС, чем Vertica, InfiniDBи Hiveсоответственно.

В рамках ниши OLAP обработки, занимаемой ClickHouse, альтернатив по скорости и устойчивости нет. В рамках же выполнения более широкого спектра задач, данная СУБД может оказаться выгоднее других с точки зрения простоты поддержки, скорости обработки запросов и эффективного использования ресурсов.

Рис 1.8.1 - Сравнение скорости выполнения запроса

Помимо скорости, ClickHouseхарактеризуется следующими преимуществами:

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

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

- В ClickHouse многопоточность реализована из коробки, то есть обработка распараллеливания запросов реализуется естественным образом механизмами самой СУБД

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

Таким образом принято решение реализовать хранилище ФИАС для проекта ГАС ПС НСИ при помощи ClickHouseСУБД.



Глава 2. Проектирование хранилища адресов

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

2.1 Проектирование колоночного хранилища ФИАС и логики первоначального заполнения

Несмотря на то, что ClickHouseзачастую используется для OLAPобработки, подразумевая денормализованные архитектуры типа «звезда» или «снежинка», данную СУБД можно использовать и с нормализованными данными.

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

Объектами справочника должны являться взаимосвязанные таблицы: основная таблица с данными, таблицы справочных сведений и метаданных, служебные таблицы [8].

С целью упрощения доступа к элементам справочника из компонентов НСИ основной таблице FIAS_NSI следует содержать атрибутивную информацию двух таблиц БД ФИАС: с адресными сведениями (ADDROBJ) и сведениями о номерах домов (HOUSE).

Для обеспечения связанности информации об адресной подчиненности домов (строений) вышестоящим адресным объектам, атрибут PARENTAO_NSI основной таблицы FIAS_NSI должен соответствовать атрибуту PARENTGUID таблицы ADDROBJ и атрибуту AOGUID таблицы House.

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

Схематично справочник представлен на рисунке 2.2.1. Полный атрибутивный состав таблиц справочника приведен в приложенииC.

Рисунок 2.1.1 - Поля таблицы для хранения данных ФИАС

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

Для первоначальной загрузки данные выгружаются в виде XMLс портала ФИАС. Скачанные XML - схемы необходимо обрабатывать в сервисе загрузки с помощью инструмента System.Xml. Данный фреймворк для чтения XMLявляется встроенным модулем для С# решений и при этом поддерживает итеративный обход XMLдокументов.

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

Данные с помощью класса для маппирования (соотносящего данные из XML с полями экземпляра класса) через клиент к СУБД вставляются в хранилище.

2.2 Проектирование работы сервиса обновления по расписанию

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

Диаграмма последовательности действий при загрузки новых данных из ФИАС в локальные сервисы и хранилища представлена на рис. 2.2.1.



Рисунок 2.2.1 - Последовательность действия при обновлении ФИАС

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

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

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



2.3 Проектирование диаграмм классов для сервисов доступа к данным

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

Поскольку логика доступа до данных, их модификации и загрузки должна быть реализована с помощью сервисов на языке C#, было произведено проектирование классов для данных сервисов с помощью диаграмм классов.

В результате проектирования были выделены 3 сервиса: сервис загрузки и обновления, сервисы модификации и запросов к данным, так называемые сервисы - распознаватели(Resolver) для формирования GraphQL запросов.

Сервис загрузки и обновления содержит в себе сущности: модель DTO (datatransferobject), класс для формирования (QueryCreator) и исполнения (QueryExecutor) запросов к базе данных ClickHouse, класс для создания HTTPзапросов к внешнему хранилищу ФИАС (загрузке файла через интернет) - TargetLoaderиосновной класс DataLoaderдля управления загрузкой и обновлением данных из ФИАС в локальное хранилище.

Диаграмма классов для сервиса загрузки представлена на рис. 2.3.1.



Рисунок 2.3.1 - Диаграмма классов для сервиса загрузки данных

Параметры подключения, таймауты загрузок, а также ссылки до необходимых сервисов НСИ рекомендуется вынести в файл конфигурации, например appsettings.jsonв случае с версией .NetCore. Данное вынесение следует сделать для всех сервисов, описанных в этой главе, поскольку таким образом повышается гибкость и облегчается настройка и развертывание сервисов.

Для доступа к данным, их чтения и модификации при работе с GraphQLиспользуются запросы (query) и мутации (mutation). Данное разделение позволяет реализовать принцип CQRS (command-queryresponsibilitysegregation). Таким образом код реализует контракт, при котором действие может быть либо командой, выполняющей действие, либо запросом, возвращающим данные, но не одновременно.

Для описания работы логики данных в GraphQLсуществуют классы Resolver'ы -- это контейнер для поля и сигнатуры логики.Резолвер определяет каким образом работать с тем или иным типом данных в схеме GraphQL.

На верхнем уровне каждого сервера GraphQL находится тип, который представляет все возможные точки входа в API GraphQL, его часто называют корневым типом или типом запроса (Query).Резолвер для всех типов в НСИ наследуется от абстрактного базового резолвера с одним методом ResolveAsyncкоторый и определяет логику резолвера. Диаграмма классов для сервиса запроса к данным представлена на рис. 2.3.2.

Рисунок 2.3.2 - Диаграмма классов резолвера GraphQL

Для модификацииэлементов: создания, изменения, удаления, закрытия (смена версии) и т. д. используются мутации. Примеры запроса для GraphQLпредставлены в главе 3.

Мутации - это соглашение, аналог Putи Postв HTTP, о том, что данные изменяются, а не запрашиваются, а не наоборот, как в Query.

Все мутации в решениях в НСИ наследуются от BaseMutationResolver. Иерархия классов по операциям, существующая в текущем решении на проекте НСИ представлена на рис. 2.3.3.

Рисунок 2.3.3 - Диаграмма классов для резолвера мутаций

Как можно заметить в классе ElementMutationResolverобъявлен классреализующий интерфейс IChangeTrackerService. Данный интерфейс описывает метод TrackElementsAsync который позволяет иерархически собирать элементы проходя по запросу (дереву запросов).

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

...