Дипломная работа: Индексации хранилища текстов на основе естественно-языковой адресации

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

1.1.4 Семейство GATE

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

В продуктах GATE вся информация о документах хранится в открытых форматах XML или OWL в специальных базах данных с реализацией индексов MG4J [15]. MG4J является еще одним решением для полнотекстового поиска в больших документах с использованием методов сжатия c инвертированным индексом [12]. Основным ограничением такого подхода по-прежнему можно назвать память, необходимую для индексов, хотя в современных версиях продуктов GATE она не столь критична [15]. Тем не менее, необходимый объем памяти для реализации MG4J больше, чем гипотетический необходимый объем памяти для индексации на основе естественно-языковой адресации.

GATE Teamware (рис. Рисунок 1.2) - сетевая программная система с открытым исходным кодом для совместной работы над корпусными исследованиями. Однако параллельная работа с корпусами требует установки пользователем персонального сервера для хранения данных и дополнительного администрирования, а облачная версия используется только как сервис распределенной обработки [11].

Рисунок 1.2. GATE Teamware

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

1.1.5 Сравнение инструментов

В таблице Таблица 1.1 приведено сравнение подходов к хранению корпусов и текстов у существующих решений по ранее выделенным критериям.

Таблица 1.1. Сравнение существующих решений

Критерий

AntConc

CQPweb

Corsis

Gate

Библиотека

Программа

Возможность хранения больших объемов данных

Нет, так как не использует БД, загружает в оперативную память

Да

Является библиотекой

Нет, так как не использует БД, загружает в оперативную память

Да

Скорость доступа к данным

Высокая, так как работа происходит в оперативной памяти

Достаточно высокая за счет использования CWB

Высокая, так как работа происходит в оперативной памяти

Достаточно высокая за счет использования MG4J

Формат данных

Только txt

XML

XML

XML или OWL

Объем дополнительной памяти

Дополнительная память не нужна

Нужна дополнительная память для модели CWB

Является библиотекой

Дополнительная память не нужна

Нужна дополнительная память для индексов MG4J

Приложение CQPweb может быть использовано только для работы со встроенными, заранее обработанными корпусами, поэтому самым эффективным решением является семейство GATE. Однако и GATE, и CQPweb задействуют дополнительную память для ускорения доступа к данным.

1.2 Инструменты для решения задач хранения текстовых документов

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

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

Документо-ориентированные базы данных хранят и обрабатывают документы - иерархические самоописываемые структуры данных, обычно хранящиеся в форматах ХМL, JSON, BSON и др. Такие базы данных хранят в себе агрегаты данных, состоящих из скалярных значений, ассоциативных массивов и коллекций. Документы в таких базах данных хранятся в качестве значений, доступных по уникальному ключу, однако открытость структуры позволяет создавать запросы и к части содержимого документа, не загружая его полностью [9].

Основными представителями таких СУБД можно назвать MongoDB, OrientDB, а также предоставляемую порталом Azure CosmosDB и другие.

1.2.1 СУБД MongoDB

Одной из самых популярных документно-ориентированных СУБД является MongoDB, предоставляющая широкие возможности формирования запросов с помощью специального языка, хранения документов в формате JSON или BSON и индексацию. Данная СУБД поддерживает работу на кластерах благодаря специальному механизму асинхронной синхронизации (репликация), а так же обеспечивает масштабируемость, в том числе шардинг [9]. MongoDB является бесплатным продуктом с открытым исходным кодом, написанным на языке C++.

Для работы с базой MongoDB предоставляет специальный язык запросов, позволяющий добавлять, удалять и изменять документы, а также искать документы по некоторым условиям [9].

1.2.2 СУБД OrientDB

OrientDB - это свободно распространяемая СУБД, объединяющая в себе документо- и графо-ориентированные СУБД. OrientDB, как и любая другая документо-ориентированная СУБД, позволяет хранить и обрабатывать документы, но также OrientDB поддерживает хранение отношений между документами. Данная СУБД хранит документы в формате JSON и дает возможность проводить некоторые запросы к базе на SQL и с помощью Gremlin.

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

1.2.3 СУБД Azure Cosmos DB

В мае 2017 года появилось новое решение Azure Cosmos DB - база данных как сервис, предоставляемая Azure для студентов бесплатно по специальной подписке, которая расширяет предыдущий проект DocumentDB. Данная СУБД поддерживает различные варианты NoSQL, в том числе и документно-ориентированный. С помощью предоставляемого API c данными в Cosmos DB можно работать как посредством SQL и LINQ, так и посредством языка MongoDB и др.

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

1.2.4 Сравнение документо-ориентированных СУБД

Так как все рассмотренные СУБД имеют все необходимые функции , то их сравнение было проведено по нефункциональным критериям:

1. Поддержка различных языков запросов.

2. Простота развертывания на сервере.

3. Цена доступа.

4. Простота взаимодействия с СУБД.

Результаты сравнения представлены в таблице Таблица 1.2.

Таблица 1.2. Сравнение документо-ориентированных СУБД

Поддержка различных языков запросов

Простота развертывания на сервере

Цена доступа

Простота взаимодействия с СУБД

MongoDB

-

-

+

-

OrientDB

±

-

+

±

Cosmos DB

+

+

±

+

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

1.3 Индексация на основе естественно-языковой адресации

Несмотря на то, что современные документо-ориентированные СУБД имеют инструменты для эффективного поиска данных, доступных по ключам, полнотекстовый поиск может иметь недостаточную производительность. Последовательное чтение текстового файла (чтобы найти конкретное ключевое слово) является медленной операцией, и каждый индексированный подход будет быстрее [5, 24].

Таким образом, применение индексации на основе естественной языковой адресации должно повысить производительность СУБД для полнотекстного поиска, однако, как и для любой индексации, это потребует дополнительных ресурсов: памяти для хранения дополнительной информации и времени на обработку. Главным преимуществом данного подхода является отсутствие необходимости хранения дополнительных индексов, так как индексами служат сами ключевые слова, то есть если стандартная схема поиска информации выглядит как «Имя-Адрес-Маршрут» (Что мы ищем? Где мы ищем? Как туда попасть?), то при использовании индексации на основе естественной языковой хранить адрес нет необходимости (так как он совпадает с именем), и схема сокращается до «Имя-Маршрут» [24].

При использовании индексации на основе естественно-языковой адресации необходима специальная модель данных, которой была выбрана многодоменная информационная модель, основанная на многоуровневых множествах. Доступ до информации, хранимой для слова “beer” представлен на рисунке Рисунок 1.3 [24].

Рисунок 1.3. Доступ к информации на основе естественно-языковой адресации

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

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

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

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

Естественно-языковая адресация применялась в графовых базах данных или RDF-репозиториях, основанных на тройках данных (объект-связь-субъект) [24].

Применение индексации в системе ICON на основе естественно-языковой адресации показало следующие преимущества:

· Линейная алгоритмическая сложность.

· Уменьшение необходимой памяти, так как нет необходимости хранить индексы отдельно [22].

1.4 Технология Windows Communication Foundation

Модуль для хранения корпусов и текстов реализован с помощью технологии Windows Communication Foundation (WCF), которая является основой для создания web_сервисов. В отличие от обычного сервиса, WCF позволяет иметь несколько точек доступа, поддерживает сессии на уровне сервиса, а не метода, позволяет использовать различные протоколы и предоставляет некоторые другие расширенные возможности. В качестве хостинга для WCF-сервиса может выступать любое приложение [27].

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

1.5 Технология Entity Framework

При работе с реляционной базой данных используется технология ORM Entity Framework, которая позволяет работать с облачной базой данных SQL Azure [17], как с локальной. Использование Entity Framework обусловлено рядом преимуществ:

1. Независимость базы данных, то есть нет необходимости писать код, специфичный для конкретной базы данных.

2. Поддержка LINQ (строгая типизация, проверка запросов на этапе компиляции).

3. Быстрота написания запросов.

4. Поддержка транзакций и параллелизма [20].

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

1.6 Требования к сервису-хранилищу текстов

На основе проведенного анализа сформированы требования к разрабатываемой программе:

1. Сервис должен быть опубликован на облачной платформе Azure.

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

3. Для индексации хранимых документов должны использоваться индексация на основе естественно-языковой адресации.

4. В качестве нереляционной СУБД должна быть использована документо-ориентированная Azure Cosmos DB.

5. В качестве нереляционной СУБД должна быть использована SQL Azure c помощью технологии Entity Framework.

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

Источник: https://otherreferats.allbest.ru/download/1017960/