Основными инструментами изучения естественного языка являются корпуса текстов, Корпус - это представительные и полные собрания текстов, отражающие заданные явления языка. Очень часто необходимо получить информацию о синтаксической сочетаемости слов в корпусе, для выделения правил анализа и синтеза текстов, генерации зависимостей с использованием методов машинного обучения, извлечения и описания различных явлений в языке. Для этого обычно используются синтаксически размеченные корпуса к примеру, СинТагРус для русского языка. СинТагРус это корпус, содержащий в себе около 100 000 предложений. Но разработка подобных корпусов требует большого количества времени, в связи с чем объем аналогичных корпусов не так велик. Так же существующий на данный момент словари глагольного управления невелики по объему и не могут использоваться для автоматической обработки текстов. Так, например, словарь "Словарь сочетаемости слов русского языка" содержит в себе лишь 2500 статей (при наличии в русском языке около 30 000 глаголов), а словарь. Словарь глагольной сочетаемости непредметных имен русского языка - около 10 000 статей. Таким образом, существующие словари требуют существенного пополнения для их внедрения в процессы автоматической обработки текстов или их внедрения в процесс изучения русского языка. работа [Денисов 2002] содержит только 2500 статей, но они весьма весомы, в их приведена не только информация о сочетании слов с другими, но и толкования слов, а также их грамматические характеристики. Объем более старых работ, которые специализированы на глагольных управлениях [Розенталь 1986, Апресян 1982] также не большой. Что бы решить перечисленные задачи необходимо привлечение существующих электронных словарей таких как Словарь "КроссЛексика" который содержит порядка 2 миллионов связей, для каждой из которых есть примеры. Менее полный, но более распространенный словарь, в который включено порядка 10000 статей, но он всё еще не может охватить большую часть лексики. Часть словарей, которые были указаны выше, вместе с информацией, можно найти в Национальном корпусе русского языка (НКРЯ), они использовались для создания электронных словарей.

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

Но невысокое качество синтаксического анализа и морфологическая неоднозначность сводили результат к тому, что на выходе был достаточно большой процент ошибок 5% - 20%, такой результат требовал ручного анализа. Большое количество выделяемых зависимостей делало работы по созданию базы данных сочетаемости слов почти невозможным, небольшое количество связей не приносило желаемого результата в сравнении с бумажными словарями. Для решения этой проблемы могут быть использованы размеченные корпуса. Сейчас НКРЯ содержит 30 миллионов предложений, в которых почти 210 миллионов словоупотреблений. Омонимия снята лишь с 516 000 предложений, содержащих почти 6 миллионов словоупотреблений.

Самый крупный на данный момент, синтаксически размеченный корпус СинТагРус по состоянию на данный момент содержит порядка 100 000 синтаксически размеченных предложений. По оценкам для того чтобы составить словарь глагольного управления для 25 000 - 30 000 глаголов требуется корпус примерно в 6 миллионов синтаксически размеченных предложений, таким образом объем существующих корпусов всё еще недостаточно. Поиск примеров сочетаемости слов может производиться при помощи широко используемых Национального корпуса русского языка (НКРЯ) или системы Sketch Engine (http://sketchengine. co. uk

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

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

На базе Sketch Engine существует (от англ. soil - почва), состоит из 2537 научных статей 2000-2015 годов издания. Корпус состоит из 45424906 словоформ или 25545924 слов (лексем).

недостатки

ограниченная доступность для людей, косвенно относящихся к лингвистике тоже самое можно сказать и о Sketch Sketch

отсутствие метаданных: кроме названия оригинального файла

RNC Sketches.

Национальный Корпус Русского создал свой сервис скетчей по биграммам: RNC Sketches.

характеристики:

Синтаксические отношения размечены автоматически с использованием парсера зависимостей Russian MaltParser и морфологического анализатора с автоматическим снятием неоднозначности [2]. Использован инвентарь синтаксических отношений корпуса СинТагРус [3]. Предложное СинтО разбито на подклассы по предлогам и падежу пост предложного слова, союзное СинтО - по союзам. Синтаксические отношения приведены в порядке уменьшения частотности.

ПЛЮСЫ:

Удобно пользоваться, широкий ряд синтаксических отношений

Результаты поиска можно экспортировать в формате csv

Можно экспортировать все биграммы а в формате json!

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

Все слова в примерах имеют ссылки для перехода

Высокая производительность

МИНУСЫ:

Омонимия мешает получить достоверные данные, могут смешаться картины омонимов разный частей речи (например, "холодно" как предикатив и как наречие).

Маленький объем около 200 млн слов - некоторые слова не попали в этот объем.

Из основного НКРЯ не унаследованы мета текстовые признаки: жанр, тематика, год написания и т.д.

Нельзя получить контексты

2.3 Исследование проектных решений

Модель данных

Входные данные это тестовые файлы с словосочетаниями в специально заданном формате похожем на csv. Словосочетания в русском языке могут быть как с предлогами, так и без. На рисунке 4 схематично изображено возможные варианты словосочетаний.

Рисунок 4 - схема словосочетания

От сюда можно выделить следующие сущности в модели данных

Проектирование структуры данных

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

Так как вариантов словосочетаний по частям речи, в русском языке, создается структура, содержащая в себе варианты словосочетаний

Такая структура хранения позволяет экономить 2,92 раза дисковое пространство.

Сравнение структур данных

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

· Хранение в исходном виде

Один из вариантов хранить данные в исходном виде. Исходный вид - это запись словосочетания в виде строки разделенной символом точка с запятой ";".

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

Недостатки хранения в данных в исходном виде.

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

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

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

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

· Хранение в json

Один из вариантов хранить данные в исходном виде json. - текстовый формат обмена данными, основанный на JavaScript. Как другие текстовые форматы, JSON прост в чтении для человека. Формат считается независимым от языка. Существует множество библиотек для работы на любом языке программирования. Для многих языков существует готовый код для создания и обработки данных в формате JSON.

Достоинства.

В отличии от исходных данных в JSON в есть возможность задать ключ и доступ к данным становится быстрее

Недостатки

Формат избыточен

Данные в формате json возможно хранить не во всех типах хранилищ

· Хранение в xml

Один из вариантов хранить данные в исходном виде xml

Достоинства

Распространённый формат

Есть поддержки во многих языках программирования

Недостатки

Очень избыточный формат данных так как на каждое значение необходимо наличие пары тегов

Отсутствие ключа для поиска

Данные в формате xml возможно хранить не во всех типах хранилищ

· Хранение в предлагаемой структуре данных

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

Достоинства

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

Возможность построения индекса по любому из полей.

Недостатки

Для хранения необходима СУБД или иное хранилище данных

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

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

Чтобы сделать систему максимально гибкой и масштабируемой следует разбить ее на модули. Так как не требуется разработать отдельный клиент или браузер для работы системы можно сразу перейти к проектированию модулей серверной части.

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

· Клиентская часть - часть которая непосредственно отвечает за взаимодействие с клиентом

· Часть логики приложения - часть в которой реализованы почти все функции системы

· Хранилище - часть системы, отвечающая за хранение данных

Клиентская часть

Для работы интерфейса необходим веб сервер таким образом клиентская часть системы это web сервер. На данный момент существует два популярных веб сервера это nginx и Apache. Оба распространяются бесплатно. Совместно эти серверы обрабатывают 50% трафика во всем интернете. Проведем сравнительный анализ двух серверов

Таблица 2 - сравнение серверов

Таблица 3 - Доступные платформы

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

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

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

Рисунок 5 - Паттерн lazy - load

Таблица 4 - Сравнение серверов на паттерне lazy - load

Как видно из таблицы 4 nginx значительно быстрее имея такой же набор функций, как и apache.

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

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

Рисунок 6 - сервер приложения

Описание пакетов

Configure - 52

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

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

Таблица 5 - форматы конфигураций

Как видно из таблицы самый мощный и удобный формат это TOML

Listen - 52

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

это TCP сервер, который обрабатывает http запросы.

Рисунок 7 - listen пакет

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

Sender пакет отправляющий данные в модуль который осуществляет работу с хранилищем

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

Таблица 6 - Syslog сервер

В таблица 5 приведены самые популярные syslog сервера, но в системе будет

использоваться syslog ng, так как все модули системы могут работать как на Linux, так и windows.

Модуль работы с хранилищем

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

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

Описание взаимодействия модулей

Все модули системы имеют интерфейсы для взаимодействия

Система состоит из

Клиентского модуля

Сервер приложения

Сервис журналирования

Модуль взаимодействия с хранилищем

Рисунок 8 - схема модулей системы

Таким образом работа взаимодействие модулей происходит следующим образом nginx, как входящая точка для всей системы отображает интерфейс пользователю и через ajax передает на сервер приложения по протоколу http запрос на сервер приложения. Сервер приложения исходя из полученных данных формирует запрос к хранилищу.

Основным требованием к интерфейсам является его простота и удобство в использовании. В пользовательском интерфейсе необходимы следующие элементы:

· Главная страница

· Страница авторизации

· Страница регистрации

· Персональная страница пользователя

· Личный кабинет

· Страница для поиска

· Справка

Главная страница система должна содержать текстовую и графическую информацию для пользователя, элементы управления и ссылки для перехода к другим элементам системы

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

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

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

Личный кабинет пользователя - это страница на которой пользователь может установить персональные настройки, поменять пароль и почтовый адрес

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

Страница справки должна содержать данные о системе и контакты администратора системы

Для разработки интерфейса построим граф диалога.

Рисунок 9 - граф диалогов

Проектирование архитектуры системы

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

Рисунок 10 - работа протокола TCP

TCP (transmission control protocol) - протокол передачи данных интернета шестого уровня модели OSI, создан для управления передачей данных. Сети и подсети, в которых совместно используются протоколы TCP и IP называются сетями TCP/IP.

В стеке протоколов IP TCP является протоколом транспортного уровня модели OSI.

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

Реализации TCP обычно встроены в ядра ОС. Существуют реализации TCP, работающие в пространстве пользователя.

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, "протокол передачи гипертекста". В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616. Но работа над разработкой HTTP 2.0 активно ведутся. HTTP открытый протокол и не использует шифрование данных, но есть модифицированная версия HTTP - HTTPS. В HTTPS используется TLS

TLS - безопасный транспортный уровень (Transport Layer Security). SSL - уровень защищённых сокетов (Secure Sockets Layer). Это криптографические протоколы, которые обеспечивают защиту передачи данных между узлами в сети Интернет.

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

TLS протокол довольно часто применяется в приложениях, работающих в Интернете: браузеры, клиенты электронной почтой, мессенджеры и IP-телефония (VoIP). Данный протокол базируется на спецификации SSL 3.0, созданной компанией Netscape Communications. На данный момент разработкой стандарта TLS занимается IETF. Принцип работы HTTPS c использованием TLS показан на рисунке 11.

Рисунок 11 - HTTPS

Рисунок 12 - Архитектура системы

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

Архитектура резервирования

Так как система должна иметь резервирование необходимо спроектировать механизмы резервирования. Для этого необходимо выявить узкие места платформы. Так как изначально все запросы попадают на firewall и в случае выхода его из строя система не сможет обрабатывать запрос. От сюда следует что необходимо резервировать firewall

Рисунок 13 - Резервирование Firewall

Технология с использованием virtual ip простая, но очень эффективная. Принцип работы virtual ip следующий, на нескольких сервисах устанавливается ПО - будем называть его HA от английского high available которое устанавливает между собой согласование, кто из серверов главный - Активный, все остальные остаются пассивными. После этого По запускается все необходимые ресурсы (сервисы, приложения базы данных и другие ресурсы), после чего HA поднимает сетевой интерфейс. Принцип работы, когда HA не видят активный сервер, они начинают опять искать главного, но уже без учета ноды которая недоступна.

Архитектура системы с учетом отказоустойчивости показана на рисунке 14

Рисунок 14 - архитектура системы с учетом отказоустойчивости

3. Разработка системы

3.1 Выбор хранилища данных