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

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

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

Рисунок 4 — схема словосочетания От сюда можно выделить следующие сущности в модели данных.

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

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

Такая структура хранения позволяет экономить 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.

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

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

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

Listen — 52.

это 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 — архитектура системы с учетом отказоустойчивости.