Дипломная работа «Реляционное и нереляционное моделирование для портала электрофизиологических экспериментов»
1 Западночешский университет в Пльзене, Факультет прикладных наук, Отделение информатики и компьютерных технологий Дипломная работа Реляционное и нереляционное моделирование для портала электрофизиологических экспериментов Пльзень, 2014 г. Мартин Биджовски
3 Декларация Заявляю, что подготовил дипломную работу самостоятельно и исключительно с использованием цитируемых источников. В Пльзене на Мартина Быджовского
4 Благодарности Я хотел бы поблагодарить Якуба Йиндру за помощь в установке базы данных Elasticsearch, Лукаша Дрбала за консультации по оптимизации запросов Elasticsearch и, что не менее важно, мою семью и Еву Яноушкову за их большую моральную поддержку. .
5 Резюме Целью данной работы является анализ текущей ситуации с базами данных NoSQL с упором на гибкую схему хранения данных и полнотекстовый поиск. Уровень данных портала EEG/ERP должен быть оценен, а ключевые части определены как подходящие кандидаты для хранения в одном из нереляционных механизмов хранения. В диссертации сравниваются несколько баз данных NoSQL с точки зрения потребностей портала. После того, как конкретная база данных выбрана, она будет подробно описана от установки до настройки и окончательной интеграции с текущим приложением. Другой целью является поиск полнофункциональной замены реляционной базе данных Oracle, поскольку условия лицензирования перестают удовлетворять потребности Портала. Производится быстрое сравнение реляционных баз данных и выбирается наиболее подходящая. Наконец, все (реляционные) данные переносятся в эту базу данных. Аннотация Целью данной работы является анализ текущего предложения баз данных NoSQL с упором на гибкую структуру хранимых данных и на полнотекстовый поиск. Слой данных EEG/ERP Портала отображен, гдеони определяют ключевые сущности, которые целесообразно переместить в одно из нереляционных хранилищ данных. В этой работе сравниваются несколько баз данных NoSQL для нужд портала. Наконец, наиболее подходящая система подробно описана, от установки до настройки и интеграции с существующим приложением. Другая цель – найти замену существующей реляционной базе данных Oracle, которая из-за своей лицензии больше не подходит для нужд Портала. Наиболее подходящая база данных будет выбрана на основе сравнения существующих реляционных баз данных, куда будут перемещены все существующие реляционные данные.
6 Содержание 1. Введение Текущее состояние Описание приложения Эксперименты по измерению Архитектура Уровень данных Объекты POJO DAO Фасад службы Важные объекты и ссылки Эксперимент Файл данных Сценарий и схема сценария Сопоставление уровня данных Изменения и версии функциональности портала Перемещение части данных в NoSQL Замена базы данных Oracle Изменение конфигурации Hibernate База данных NoSQL SQL vs. NoSQL Использование NoSQL Разделение баз данных NoSQL Требования к порталу Разделение данных на портале Используемые базы данных MongoDB Elasticsearch Solr Выбор базы данных NoSQL Lucene и инвертированный индекс Теоретическое сравнение Сравнение производительности Субъективный взгляд. 29
7 Выбор базы данных Elasticsearch Основные понятия Процесс индексирования Структура хранения данных Определение анализатора Токенизатор Фильтры токенов Конфигурация сопоставления Автоматическое сопоставление Сопоставление вручную Вложенное сопоставление Создание запросов Интеграция в существующую систему Spring Data Elasticsearch Создание объектов Elasticsearch Редактирование перехватчика POJO Редактирование эксперимента DAO Автоматические тесты Резюме Реляционные изменить базу данных Подходящие кандидаты MySQL SQLite MariaDB PostgreSQL Выбор Подготовка миграции Редактирование отображения Hibernate Переход на аннотации Длинные строки Бинарные данные Миграция данных Заключение Список используемых сокращений Литература. 58
8 Приложение A) Установка базы данныхПриложение Elasticsearch B) Установка PostgreSQL. 62
10 1. Введение Необходимость эффективного хранения цифровых данных существует с момента создания первого компьютера. Со временем из этого вопроса выросла целая технологическая индустрия. В 1970 году Эдгар Ф. Кодд определил термин «реляционная база данных». Эти базы данных должны хранить данные независимо от используемого языка приложения и даже от того, как данные хранятся физически. В 1980-х IBM придумала язык SQL и были созданы первые базы данных: Oracle или IBM со своей DB2. В последнее время концепция базы данных NoSQL, в которой данные хранятся иначе, чем в этих традиционных базах данных, становится очень популярной. Часто это специально ориентированные, оптимизированные хранилища ключей и значений, где значением может быть любой объект, содержащий ряд неопределенных атрибутов (мы говорим о базах данных без схемы). Еще одним преимуществом этих систем является простое (в основном неявно поддерживаемое) вертикальное масштабирование. Использование этих систем подходит в области так называемых Big Data 1 или, например, в полнотекстовых поисках. Основной целью данной работы является обзор текущего предложения баз данных NoSQL для нужд портала EEG/ERP. Последняя сталкивается с проблемой необходимости гибкого хранения данных, поскольку область хранимых данных широка, и разные лаборатории хранят разные метаданные для своих экспериментов. Для этого будет проведен анализ существующей модели данных портала ЭЭГ/ERP и будут определены наиболее важные объекты и их связи с другими частями системы. Далее будут определены данные, подходящие кандидаты для перемещения в базу данных NoSQL. Еще одна ключевая особенность, почему необходимо реализовать базу данных NoSQL, — это требование полнотекстового поиска по метаданным. После выбора наиболее подходящего решения выбранные данные перемещаются в это новое хранилище. Будетнеобходимо выполнить установку, соответствующую настройку и задать параметры индексации, чтобы поиск давал релевантные результаты для нужд портала ЭЭГ/ERP. Интеграция в существующее приложение должна происходить только на уровне данных, чтобы затрагивалось как можно меньше уровней. С точки зрения трехуровневой архитектуры это изменение никак не должно повлиять на более высокие уровни. 1 Большие данные: в основном рассматриваются данные об объемах в порядке от ТБ до ПБ. 1
11 Еще одним пунктом этой работы является изменение реляционного хранилища данных, поскольку существующая база данных Oracle больше не подходит по причинам лицензирования. Необходимо найти систему баз данных, которая по своим функциональным возможностям будет максимально похожа на исходную базу данных Oracle, и перенести все реляционные данные в эту базу данных. И последнее, но не менее важное: эта работа посвящена общему рефакторингу двух слоев данных приложения. В проекте есть несколько узких мест, которые со временем увеличились, так как над приложением работало много разных студентов, а код становится загроможденным и плохо поддерживаемым в будущем. Поэтому часть работы посвящена попыткам исправить эти проблемы. В следующей главе работа посвящена описанию текущего состояния Портала и отображению его архитектуры. Третья глава посвящена общему сравнению ключевых возможностей и сопоставлению преимуществ и недостатков баз данных SQL и NoSQL. Далее представляются кандидаты на реализацию гибкой модели данных и производится их сравнение. Сущности портала, которые будут перемещены в нереляционную базу данных, также четко определены. В четвертой главе подробно анализируется база данных Elasticsearch, которая оказалась наиболее подходящей из предыдущего сравнения. Описана вся процедура развертывания этой базы данных, от установки и настройки до внедрения и интеграции в существующее приложение. Последняя, шестая глава посвящена передачереляционных данных из базы данных Oracle в другую реляционную базу данных, где база данных PostgreSQL была выбрана как наиболее подходящая. 2 Рефакторинг: изменение кода для большей ясности и упрощения расширения при сохранении той же функциональности. 2
12 2. Текущее состояние 2.1. Описание приложения Портал EEG 3 /ERP 4 (далее Портал) представляет собой веб-приложение, разработанное на кафедре информатики и компьютерных технологий Западночешского университета в Пльзене, которое служит центральным местом для исследователей, выполняющих , обрабатывать или анализировать результаты измерений ЭЭГ/ВП. Это позволяет зарегистрированным пользователям загружать эти измеренные эксперименты, добавлять метаинформацию о данном измерении, классифицировать их и, что не менее важно, искать их по различным критериям. Он содержит сложную систему пользовательских ролей и разрешений, группирует отдельных пользователей в так называемые исследовательские группы (Research Groups), внутри которых они могут делиться отдельными экспериментами. Кроме того, приложение служит агрегатором научных статей, связанных с исследованием проблемы измерения ERP. Полная функциональность Портала заключается в следующем [1]: Создание и управление учетными записями пользователей. Создание исследовательских групп и управление ими. Хранение, анализ и обработка данных эксперимента и метаданных. Создание и управление лицензиями, а затем их назначение экспериментам. Обмен данными и метаданными между пользователями и исследовательскими группами. Добавление статей и комментирование их для пользователей и групп. Поиск в базе данных ЭЭГ. Войдите на Портал, используя социальные сети Facebook и LinkedIn. В настоящее время порталом в основном пользуются люди из Университета Западной Чехии, но он также может хорошо послужить, например, в лабораториях, занимающихся исследованиями ERP. Отсюда 3 Электроэнцефалограмма (сокращенно ЭЭГ) представляет собой запись временного изменения электрического потенциала, вызванногоактивность мозга. Эта запись производится с помощью электроэнцефалографа. 4 Потенциал, связанный с событием (ERP, вызванный потенциал) — это измеряемая реакция мозга на конкретное вызванное событие или стимул. 3
По 13 причинам на портал добавлены функции, которые позволяют лицензировать измеренные эксперименты и их последующее предоставление другим пользователям портала. Так, с одной стороны, могут быть научно-исследовательские институты, которые проводят измерения и публикуют полученные данные, с другой стороны, затем компании, которые проводят анализ этих данных и будут платить за опубликованные эксперименты. Это приложение призвано стать централизованным местом для профессионального сообщества людей (как академических, так и коммерческих), которые активно интересуются этой областью. Предварительный просмотр портала показан на следующем изображении: 2.2. Измерение экспериментов Рисунок 1: Пример портала ЭЭГ/ERP Главной особенностью Портала является хранение экспериментов из области измерения вызванных потенциалов. Результаты измерений состоят как из двоичных данных, которые представляют определенные измеренные напряжения на отдельных электродах в течение времени, так и из метаданных, которые представляют собой текстовые данные, подробно описывающие эксперимент и его обстоятельства. Это, например, описание испытуемого (возраст, вес, рост, его заболевания), окружающая среда (температура, погода, время суток) или перечень используемых вспомогательных средств (модель шапки ЭЭГ, описание подключенных электроды) Архитектура Это веб-приложение, написанное на языке Java и использующее возможности платформы Java EE (Java Enterprise Edition) [2]. Это стандартное приложение 4
14 с использованием трехуровневой архитектуры, в которой уровни данных, приложения и представления разделены, и каждый из этих уровней состоит из нескольких других. Поскольку Портал является классическим корпоративным приложением, в нем используются проверенные фреймворки и процедуры написаниябольшие веб-проекты на Java. Поэтому используется фреймворк Spring, который в первую очередь заботится о внедрении зависимостей и правильном создании и подключении отдельных компонентов приложения. База данных Oracle 11g используется в качестве постоянного хранилища данных, а среда Hibernate развернута для связи между приложением и базой данных. Это обеспечивает так называемое объектно-реляционное отображение (ORM) между базой данных и объектами, с которыми может работать приложение. Уровень представления также является неотъемлемой частью каждого приложения. Здесь используется фреймворк Wicket или на момент написания этой работы он был переведен на уровень данных. С точки зрения этой работы главное, что интересно, это то, как работает слой данных. Поэтому в этой главе он обсуждается более подробно. Над этим слоем работают контроллеры (в настоящее время используется Spring MVC) и над ними уже упомянутый Wicket, через который генерируются формы и весь пользовательский интерфейс. Это, например, конструктор без параметров или никаких мощных методов (за исключением геттеров и сеттеров). В приложении они используются для представления постоянных объектов, которые хранятся в базе данных. Hibernate заботится о сопоставлении их атрибутов с определенными столбцами в таблицах и автоматической загрузке и записи их из/в базу данных. У них нет функциональности самих по себе, они только представляют данные DAO. DAO или объект доступа к базе данных — это группа классов, которые привязаны к (в основном одному) объекту POJO. Они содержат как методы записи, обновления и удаления записей в базе данных (относящиеся к данному POJO), так и методы их извлечения, например, на основе id, фильтрации по значениям атрибутов и тому подобное. Слой DAO заботится о создании объектов POJO. 5
15 классов служебных DAO содержат методы дляработать с одной сущностью и выполнять очень простые и частичные операции с точки зрения функционирования всего приложения. И именно по этой причине существует сервисный слой, который имеет ссылки на несколько объектов DAO и способен выполнять более сложные операции. Например. регистрация пользователя означает следующие шаги с точки зрения всего приложения: зашифровать его пароль сохранить объект пользователя в базе данных назначить ему роль обычного пользователя, если регистрация включала приглашение в исследовательскую группу, присоединиться к нему отправить подтверждение И последнее, но не менее важное: этот уровень обеспечивает транзакции, которые проводятся на уровне объектов службы. Вся операция, выполняемая над сервисным объектом, затем появляется снаружи как атомарный фасад Фасад выполняет ту же роль, что и сервисный уровень. Это еще один уровень абстракции, который может выполнять очень обширные операции с данными. В то же время он может использовать один или несколько сервисных объектов для своей функциональности. На данный момент этот уровень не так часто используется и более или менее просто передает управление дочерней службе. Полный обзор разбивки уровня данных показан на следующем рисунке: 6
16 2.5. Важные сущности и ссылки Эксперимент Рисунок 2: Архитектура слоя данных Это самая обширная сущность как с точки зрения количества ссылок на другие объекты, так и важности смысла. Он представляет собой реальные эксперименты, измеренные в лаборатории. Он содержит метаинформацию о проведенном эксперименте (простые типы данных или ссылки на другие объекты), такие как: время начала, время окончания, субъект, исследовательская группа, владелец, файл данных, сценарий, электродеконф. Кроме того, эксперимент содержит ряд очень похожих параметров, которые все хранятся как отдельные постоянные объекты, хотя они точно такие же по структуре. Этими сущностями являются: оцифровка, погода, температура, аппаратное обеспечение, программное обеспечение, болезнь, тип проекта,Pharma, Experimentoptparam Их структура следующая: name тип данных значение id int первичный ключ title String тип значения параметра String необязательный тип, практически неиспользуемый description String более длинное текстовое описание параметра isdefault boolean флаг присутствует ли этот параметр в новом эксперименте Experiments Set ссылка на эксперименты, содержащие этот параметр Таблица 1: Соответствующие параметры эксперимента 7
17 Очевидно, что все вышеперечисленные сущности можно было бы объединить в одну, более общую, которая была бы дополнена свойством типа параметра, которое отличало бы, какой это параметр. Это значительно упростит базу данных, устранит несколько таблиц привязки и значительно упростит добавление новых типов параметров, теперь необходимо создать новый постоянный объект, сгенерировать таблицу (таблицы) в базе данных, создать DAO, несколько служб и объекты фасада изменены и, наконец, расширены GUI 5, чтобы иметь возможность создавать этот объект. Вместо этого предлагаемый тип параметра enum будет просто расширен на одно значение, и это будет использоваться DataFile DataFile — это сущность, связанная с экспериментом. Помимо ссылки на эксперимент, к которому он относится, краткого описания, имени файла и MIME-типа, он в основном содержит бинарные данные, полученные от измерительного устройства. Фактическое содержание бинарных данных для данной работы не интересует, но потенциальный размер этой сущности (может доходить до единиц ГБ) да Сценарий и Сценарная схема Каждый эксперимент проводится в лаборатории по определенному плану. Такой план включает, например, продолжительность того, что проецируется за изображением на испытуемого, какая музыка играет фоном и т. д. Двоичные данные (или данные в формате XML) снова являются частью этой схемы. Ранее были опробованы формат и методы его хранения, были опробованы различные проприетарные Oracle.XML-типы базы данных, типы данных blob и тому подобное. Одной из целей данной работы является попытка унифицировать и упростить использование этих схем сопоставления уровней данных.Портал использует ORM для связывания таблиц базы данных с POJO-объектами, с которыми затем может работать само приложение. Hibernate предлагает два способа реализации этого сопоставления [3]: Внешние файлы конфигурации *.hbm.xml Это файлы XML, в которых каждый объект POJO имеет теги XML для определения того, как его свойства сопоставляются с конкретными таблицами и столбцами. Это оригинальный (ныне устаревший) способ реализации этого сопоставления. Проблема, с одной стороны, в 5 GUI: графический пользовательский интерфейс. Графический интерфейс, через который конечный пользователь управляет приложением. 8
18 довольно сложная файловая структура, поэтому в необходимости хранить связанную информацию в двух разных местах, как в самом классе Java, так и в этом файле. Пример такого сопоставления выглядит следующим образом: Здесь вы можете увидеть определение сопоставления для объекта Experiment (указано полное имя класса и имя таблицы, в которой хранятся данные). Затем определяется первичный идентификатор этого объекта и, наконец, ссылка на два других объекта (первый связан ссылкой 1:N, а второй — M:N). Аннотации Java, являющиеся частью сущностей POJO. Это более современный и понятный способ написания отображений. Непосредственно для каждой переменной в коде класса POJO сопоставление определяется аннотациями. Написание такого кода значительно короче, а соответствующая информация собрана вместе. Mapping then = «EXPERIMENT») открытый класс Experiment реализует Serializable = «generator», Strategy = = «EXPERIMENT_ID», nullable = false, точность = 22) private int = = «WEATHER_ID», nullable = false) private Weather = = «RESEARCH_GROUP_ID «, nullable = false) private ResearchGroup = FetchType.LAZY) 9
19 @JoinColumn(имя =»ELECTRODE_CONF_ID», nullable = false) private ElectrodeConf = «START_TIME», length = 7) private Timestamp starttime; В этом примере сопоставление снова относится к сущности Experiment, но определения отдельных свойств базы данных теперь определяются непосредственно в коде этого класса. Благодаря Java Reflection API, Hibernate может самостоятельно находить множество свойств, и нет необходимости указывать их, как в предыдущем примере XML (например, полные имена классов, на которые ссылаются). Объединение обоих этих подходов в конфигурации портала является проблемой, поскольку сопоставления должны поддерживаться в двух разных синтаксисах и в разных местах. Кроме того, для некоторых классов определены как сопоставления аннотаций, так и файл hbm.xml для них. Трудно найти, что актуально, что (не)действительно и какой подход Hibernate действительно загружает и использует. Еще одна проблема с этим гибридным подходом заключается в том, что вы должны перечислить по одному объекту за раз (в специальном файле конфигурации), как каждый класс отображается, и предоставить ссылку на этот ресурс сопоставления. 10
20 3. Изменения и доработки функционала Портала Поскольку проект со временем развивается и динамично реагирует на требования пользователей, в то же время сотрудники отдела пытаются сформировать определенные видения и планы, в каком направлении должен развиваться Портал с точки зрения функциональности, это часто происходит с вмешательством в архитектуру приложения и обширными изменениями в коде. Кроме того, в проекте участвуют чередующиеся команды студентов, которые выполняют поставленные задачи и реализуют различные функциональные возможности в качестве семестровой работы по своему предмету. Эти упомянутые факторы часто негативно сказываются на качестве получаемого кода. Поэтому часть этой работы — выявление самых больших недочетов, попытка их исправления и их удаление и рефакторинг, чтобы код в дальнейшем был легко поддерживаемым и читабельным Перенос части данных в NoSQL Entity и привязкипараметры эксперимента излишне сложны, много кода повторяется, а добавление других типов параметров затруднено. Поэтому возникает необходимость найти репозиторий, обеспечивающий некоторую гибкость при работе с этими данными. Кроме того, владельцы портала хотели бы выполнять полнотекстовый поиск по этим атрибутам, включая расширенные методы анализа текста, такие как выделение корней, распознавание синонимов и т. д. Современные нереляционные базы данных позволяют это в сочетании с динамической структурой хранимых данных. , поэтому он представляется идеальным хранилищем для этой области. Замена базы данных Oracle Как уже было описано в предыдущих главах, в будущем кафедра планирует начать продвижение Портала за пределами университетской среды. Поэтому не исключено, что со временем проект разрастется и потребуется развернуть приложение не на университетских серверах, а где-то еще. К сожалению, действующая лицензия системы баз данных Oracle 11g не позволяет такое использование, и необходимо будет приобрести коммерческую лицензию. Цены на эти лицензии колеблются от единиц до десятков тысяч долларов [4], что на данный момент неприемлемо для вуза. Более того, с точки зрения университета, такое использование проприетарного программного обеспечения представляется не самым подходящим. Необходимо найти другую подходящую базу данных SQL, куда будут перемещены все существующие данные. Основной упор будет сделан на открытость исходного кода, простоту развертывания и максимально возможное сходство с существующим Oracle. 11
21 3.3. Изменение конфигурации Hibernate В предыдущей главе были описаны нелогичности в настройке сопоставления сущностей с базой данных. Более чем уместно унифицировать это сопоставление. Новые версии Spring позволяют указать путь ко всем сущностям, которые он будет автоматически загружать и обрабатывать. Нет необходимости перечислять все объекты один за другим. Еще одна проблема с настройкой всего Портала — наличие примерно шести конфигурационных файлов, гденекоторая информация (учетные данные базы данных, конфигурация Java Beans, настройки уровня логирования и т. д.) повторяется, и вообще не понятно, какие свойства откуда загружаются. 12
22 4. База данных NoSQL Портал содержит данные (в основном метаданные о измеренных экспериментах), которые по своему характеру не укладываются в схему стандартных реляционных баз данных, поскольку их структура постоянно развивается, добавляются другие типы параметров или различаются элементы являются обязательными для различных параметров / необязательными. Кроме того, было бы желательно иметь возможность выполнять полнотекстовый поиск по этим данным, что означает не только значение SQL WHERE LIKE %val%, но и использование таких методов, как поиск корней (поиск основной формы слова). ), распознавание синонимов, оценка релевантности (например, где и сколько раз искомое слово встречается в тексте) и т. д. Реализации вышеупомянутых процедур также включены в стандартные реляционные базы данных, но часто это только базовая поддержка, эти базы данных не позволяют детально настроить индексацию и обработку текстовых данных, которые обычно требуют определенной процедуры хранения и последующего поиска. И последнее, но не менее важное: масштабирование этих баз данных затруднено при увеличении размера индексированных данных. Термин NoSQL был впервые использован в 1998 году и был призван подчеркнуть отличие от традиционных баз данных тем, что для доступа к данным используется не установленный язык SQL, а какой-то другой, специфичный для данной базы данных. В последующие годы многие базы данных этого типа SQL vs. NoSQL Традиционные реляционные базы данных (SQL) используются с 1980-х годов. Основным элементом этих баз данных являются сеансы таблиц базы данных. Таблица состоит из записей (строк), которые имеют четко определенные атрибуты (столбцы). Затем атрибуты определяются конкретным типом данных и диапазоном значений, которые может принимать атрибут. Каждыйзатем запись содержит уникальный идентификатор первичного ключа каждой строки в таблице. Это может быть один или несколько столбцов, которые вместе образуют уникальную комбинацию. Еще одна важная особенность — внешние ключи. Они используются именно для выражения тех отношений/связей (сессий), которые отдельные записи из разных таблиц имеют друг с другом. Опять же, это один или несколько столбцов, которые однозначно идентифицируют запись в другой таблице. И последнее, но не менее важное: целостность данных — важный элемент реляционных баз данных. 13
23 В последние годы начинают широко использоваться системы баз данных, которые имеют относительно разные свойства и связанные варианты использования. Речь идет о так называемых NoSQL (нереляционных) базах данных. Важны высокая доступность данных и стремление к максимально возможной пропускной способности, будь то чтение или запись. Чтобы соответствовать этим требованиям, он в основном подчиняется некоторым принципам, известным из СУБД 6. Как правило, это правило 3NF 7, данные не являются атомарными, нет транзакций, а согласованность базы данных не гарантируется в каждый момент времени. В некоторых случаях это может не быть проблемой. Например. неважно, что научная статья после внесения в базу данных будет доступна для полнотекстового поиска не сразу, а лишь через одну-две секунды, и притом она несет с собой полные данные о своем авторе, поэтому при отображается, устраняется необходимость JOIN-соединения нескольких таблиц. Сравнение обоих типов хранения представлено в следующей таблице: Свойство NoSQL SQL Стиль хранения данных Документы, пары ключ-значение, графические структуры Таблицы. Организация данных Динамическая схема предопределенных, четко определенных неструктурированных данных. диаграмма. Масштабирование (увеличение производительности) Более высокая производительность по горизонтали достигается за счет добавления большего количества работающих серверов. Вертикаль повышает производительность работающего сервера (больше оперативной памяти, более мощный процессор, SSD-диски). Данные обработаныЯзык запросов Согласованность данных Безопасность данных Подходит для иерархических данных с различными вложенными элементами в виде документов JSON или XML Каждая база данных NoSQL использует свой собственный язык запросов. В основном для получения четко заданных данных из базы данных по более простым критериям. Поскольку не существует эффективного способа соединения связанных объектов (документов), связанные данные часто копируются как вложенные вложенные документы внутри хранимого объекта. Требования ACID, известные из реляционных баз данных, не могут быть обеспечены в (распределенных) базах данных NoSQL. Таблица 2: Сравнение баз данных SQL и NoSQL Сложные данные со множеством сложных отношений между отдельными таблицами. Менее подходит для иерархически распределенных данных. Стандартизированный SQL используется для выполнения сложных запросов. Подходит для создания различных сложных проекций над исходными данными. Отношения определяются внешними ключами, запись содержит ссылку на связанный объект в другой таблице. Они поддерживают так называемый подход ACID, Атомарность операций (закрытые в транзакции), Непротиворечивость в каждый момент времени, данные находятся в безошибочном состоянии, Изоляцию, поскольку транзакции (не)видятся окружающей средой, Долговечность. 6 РСУБД: реляционная база данных системы управления реляционными базами данных. 7 3NF: Третья нормальная форма: набор правил и рекомендаций по проектированию структур баз данных для оптимального использования свойств реляционных баз данных. 14
24 4.2. Использование NoSQL Из вышеописанного сравнения свойств репозиториев SQL и NoSQL следует и метод использования. NoSQL подходит для: Хранения больших объемов данных, требующих распределенного доступа из разных частей мира (горизонтальное масштабирование). В приложениях, где модель данных проще (нужно не так много операций JOIN). В приложениях, где упор делается на быструю разработку. Для простого и автоматического резервирования данных (восстановление после падения определенногоколичество узлов). Чтобы создать слой быстрого кэширования. При небольшой задержке доступности вновь сохраненных данных это не проблема. Как гибкое хранилище данных (неструктурированные/полуструктурированные данные). случаи: Наоборот, в этих случаях использование NoSQL не совсем уместно или даже плохо. Ключом является атомарность и непротиворечивость хранимых данных (например, список онлайн-платежей клиентов). Сохраняемые данные обычно носят реляционный характер. Приложения, требующие обработки транзакций. Необходим комплексный анализ, агрегация и дальнейшая обработка хранимых данных. Требуется более сложная система разрешений и доступов на уровне учетных записей пользователей базы данных. Требуется стопроцентная отладка и тестирование используемой базы данных. 15
25 дат: 4.3. Разделение баз данных NoSQL Основная классификация баз данных NoSQL [5] может быть выполнена на основе типа хранения Документ. Фундаментальной концепцией баз данных документов является концепция документа. Он содержит частично структурированные данные, включающие произвольные элементы (ключи). Затем по этим ключам можно создавать индексы и по ним можно искать документы. Для кодирования документов используются многие форматы, например JSON, XML, YAML, BSON (= двоичный JSON). К типичным представителям этих баз данных относятся: MongoDB, Elasticsearch, Neo4J, CouchDB, Solr и другие. Пара «ключ-значение» Часто это очень узкоспециализированные базы данных, оптимизированные для конкретной задачи. Данные можно получить только с помощью первичного ключа. Они часто стараются держать все данные в оперативной памяти, таким образом добиваясь очень высоких скоростей записи и чтения. Представителями этой технологии являются, например: Memcached, Redis. Граф В этих базах данных для представления данных используются графовые структуры, такие как узлы и ребра. Узлы напрямую связаны со своими соседними элементами, поэтому нет необходимости выполнять какие-либо операции JOIN и искать в индексе. они используютсянапример, для представления данных в социальных сетях, на картах или, возможно, в сетевых топологиях. Есть, конечно, и множество других типов хранения (объектное, столбцовое, XML), но они выходят за рамки данной работы, а потому не будут далее разрабатываться экспериментами. Это означает совершенно новые типы параметров, а также простое расширение существующих параметров дополнительными подпараметрами. О необходимости перебора этих данных уже писалось ранее в этой работе. 16
26 Таким образом, использование базы данных без схемы является идеальным решением. В следующей части этой главы будет проведено базовое сравнение нескольких известных баз данных NoSQL, специализирующихся на полнотекстовом поиске. Это сравнение должно привести к подходящему решению для хранения метаданных для экспериментов. Из характера баз данных NoSQL ясно, что не все данные будут переданы в эту базу данных (например, автор эксперимента или исследовательская группа, к которой принадлежит эксперимент), потому что это данные, тесно связанные с другими объектами Портала. и было бы очень сложно поддерживать эти данные синхронизированными и актуальными в обеих базах данных Распределение данных на Портале На основании описанных свойств баз данных NoSQL и их принципиальных отличий от традиционных баз данных необходимо решить, какие данные останутся в реляционной части и будут перемещены в нереляционную базу данных. Важными сущностями являются в основном индивидуальные параметры эксперимента, для которых нужны гибкие структуры по мере развития требований отдельных лабораторий. Текущая реализация, в которой каждый параметр представляет собой конкретную сущность, не может быть реализована в будущем. Полнотекстовый поиск, в котором доминируют современные базы данных NoSQL,тоже важная особенность. Текущая схема Портала имеет 76 таблиц, в которых хранятся все рабочие данные. Сюда входят, например, пользователи Портала, их роли и полномочия, членство в исследовательских группах, измеренные эксперименты, лицензии на эти эксперименты, статьи, комментарии и другие данные. Большая часть таблиц состоит из параметров и метаданных для экспериментов или таблиц связи между ними. Поэтому большая часть параметров будет перемещена в нереляционную базу данных, кроме тех, которые содержат ссылки на другие сущности Портала (конкретно это, например, описание состава соединения отдельных электродов , этот параметр очень специфичен и сложен). Сущность DataFile также не принадлежит нереляционной базе данных, поскольку NoSQL не подходит для хранения двоичных данных. Из принципа нереляционных баз данных (нет возможности удержания ссылок на другие сущности) также следует, какие объекты должны оставаться в реляционном хранилище. Например, все они являются пользователями (содержат ссылки на исследовательские группы, разрешения, фигурируют как авторы статей, комментариев и т. д.). Эти связи между отдельными сущностями нельзя смоделировать в базе данных NoSQL. 17
27 Распределение данных между исходной реляционной базой данных и недавно реализованной базой данных Elasticsearch описано на диаграмме на следующем рисунке (Рисунок 3: Разграничение данных SQL и NoSQL. Следует подчеркнуть, что это не стандартный UML). или диаграмме ER мощность взаимосвязей не указана, а также (для ясности) не показаны все сеансы портала или, например, таблицы соединений в привязках M:N Рисунок 3: Определение данных SQL и NoSQL 4.6. Базы данных MongoDB Это документно-ориентированная база данных NoSQL, написанная на языке C++ [6]. Позволяет разделять данные на базы данных, каждая из которых состоит из одной или нескольких коллекций. Коллекции должны (но не обязательно) группировать документы с одинаковыми или похожийструктура. Каждый документ должен содержать уникальный первичный ключ. Это может быть сгенерировано либо базой данных при вставке документа, либо указано вручную. Индексы могут быть определены над отдельными ключами в документе, 18
28, которые ускоряют поиск документов при их чтении. С другой стороны, они замедляют операции записи, как и в классических системах SQL. MongoDB поддерживает так называемые ReplicaSets, что является принципом репликации master-slave. Это работает таким образом, что есть несколько экземпляров MongoDB на разных машинах, которые подключены к одному ReplicaSet. Один из экземпляров действует как первичный узел, который может обрабатывать как операции чтения, так и записи. Если происходит запись, он также перенаправляет это изменение на вторичные узлы. Они могут обрабатывать только операции чтения, тем самым снижая нагрузку на основной узел. JSON используется в качестве формата для сохранения документов. Вся база данных в основном очень близка к Javascript, оболочка Mongo является интерактивным (REPL) клиентом этого самого языка. В следующем коде показан пример использования консольного клиента Mongo, подключения к базе данных, вставки трех документов (первичный ключ _id указывается вручную для второго) и, наконец, вывода списка всех записей:
29 Elasticsearch Это относительно новый проект (февраль 2010 г.) [8], разработанный на Java. Elasticsearch — это база данных, ориентированная на документы, которая полностью взаимодействует через REST API. Как следует из названия, его основное внимание уделяется анализу текста и полнотекстовому поиску. Он построен на основе индекса Lucene [9]. Формат связи также JSON. Он используется как для хранения и извлечения данных (язык запросов), так и для настройки всей базы данных, количества узлов в кластере, метода репликации, параметров отображения и т. д. Структура хранимых данных следующая: Индекс представляет собой определенный(аналогично реляционной базе данных или схеме), каждый индекс может иметь несколько типов (аналогично таблице), которые группируют документы с одинаковым или похожим содержимым. Как и Mongo, Elasticsearch по умолчанию поддерживает репликацию. Несколько экземпляров объединены в так называемый кластер, и для каждого индекса определено, сколько реплик (на скольких экземплярах) он должен существовать. Затем Elasticsearch автоматически позаботится о равномерном распределении данных между отдельными узлами. На следующем изображении показан пример работы с Elasticsearch из командной строки, создания нового индекса, индексации двух документов (типа людей), поиска определенного человека по _id и, наконец, поиска всех людей:
31 Lucene и инвертированный индекс В тексте уже несколько раз упоминалось, что обе базы данных работают с индексом Lucene. Lucene — это проект с открытым исходным кодом, написанный на Java в рамках Apache Software Foundation. Это движок, который используется для индексации и поиска текстовых данных. Он использует структуру данных, известную как инвертированный индекс, для организации данных. Сама Lucene содержит только низкоуровневые команды для хранения и извлечения данных. Для этого он предоставляет сложный и сложный API. Кроме того, в нем не рассматриваются масштабирование, распределенный доступ и другие полезные функции для создания сложных приложений. Инвертированный индекс — это структура, подходящая для полнотекстового поиска. Вместо индексации документа с входным текстом (всеми словами), который он содержит, индекс строится в обратном порядке. База данных просматривает входной текст и добавляет все слова в индекс (если их там еще нет) с информацией о том, что они (также) содержатся в индексируемом в данный момент документе. Например, для следующих документов: DOC1: Это тест. DOC2: Забавный тестовый пример. DOC3: Это странно Будет построен инвертированный индекс: this => 1 => 1,2,3 и => 1 тест=> 1.2 пример => 2, что => 2 смешно => 2 это => 3 странно => 3 Поиск фразы test is даст результат: <1,2 && <1,2,3 = <1,2 Найдены следующие документы: DOC1 и DOC2. В таком указателе также может храниться информация о положении слова в данном документе и другая метаинформация. Не менее важным аспектом является запоминание слов не в прямом виде, как они есть в тексте, а в лемматизированной форме. Это объединяет слова с одинаковым морфологическим значением (множественное число, притяжательные формы, прошедшее время и т. д.), которые 8 Лематизация: нахождение основной формы слова. 22
32 положительно влияет на полнотекстовый поиск. Кроме того, побочным эффектом является меньший размер такого индекса Теоретическое сравнение Это две очень похожие на первый взгляд системы. Оба написаны на Java, оба построены на основе Lucene, и оба профилируют себя как хранилища данных, уделяя основное внимание полнотекстовому поиску. Зрелость Elasticsearch — это более новая система, которая лучше соответствует текущим требованиям. С самого начала он запрограммирован с упором на масштабируемость (развертывание на нескольких серверах). Solr, с другой стороны, является более старым проектом, что может означать преимущество с точки зрения более стабильного кода, гораздо более глубокого тестирования всего проекта и в целом более обширных и надежных приложений, созданных поверх этого репозитория. Первая стабильная версия Elasticsearch (1.0.0) была официально выпущена во время написания этой работы. До этого была только версия для разработки.Возраст проекта также оказывает большое влияние на размер пользовательской базы и активных участников, которые участвуют либо непосредственно в разработке базы данных, либо в ее использовании, что является преимуществом. для Солра. Конфигурация Solr имеет более сложную конфигурацию по сравнению с Elasticsearch, которая также фрагментирована на несколько XML-файлов. В частности настроен весь сервер, и особенно после этогокаждое ядро (база данных). Проблема с этими файлами заключается в том, что XML является очень сложным форматом (поэтому некоторые переменные конфигурации записываются как вложенный элемент XML, другие, например, как атрибут элемента), и необходимо постоянно проверять документацию, поскольку каждое свойство записывается по-разному. . Elasticsearch имеет только один файл конфигурации в формате YAML, который также придерживается плоской структуры, поэтому работать с таким файлом очень просто. Затем конфигурация отдельных индексов (баз данных) выполняется через REST API, поэтому необходимость в дополнительных файлах отпадает. С этим связано еще одно преимущество Elasticsearch, большинство изменений в конфигурации индекса можно сделать на лету, вызвав конкретную конечную точку 9. Для изменения такой конфигурации нет необходимости перезапускать сервер, что не возможно с Solr. Там даже изменение (добавление) нового сопоставления требует перезагрузки. 9 Конечная точка: обозначение, используемое в службах REST для URL-адреса, на который отправляются запросы на выполнение отдельных действий. 23
33 Мониторинг состояния Elasticsearch в основном не имеет четкого мониторинга состояния (только вывод JSON из конечной точки состояния REST), но есть два официально поддерживаемых плагина: HEAD и Paramedic. Head — это плагин для общего администрирования базы данных, проверки основного состояния, просмотра сохраненных данных и тестирования запросов. Эти операции удобно выполнять с помощью встроенного клиента REST. Кроме того, он запоминает все отправленные команды, поэтому в любой момент есть возможность вызвать ранее заданный вопрос. Пример этого плагина показан на следующем изображении: Рисунок 4: Образец плагина управления базой данных Paramedic, с другой стороны, может четко отображать различную статистику сервера в реальном времени в виде графиков, например, количество запросов, оперативную память использование, ЦП, состояние отдельных индексов и т. д. Наглядный пример визуализации показан на следующем изображении: Рисунок 5: Elasticsearchмониторинг 24
34 Согласно документации и описаниям в Интернете, Solr должен предоставлять интерфейс мониторинга через Консоль управления Java, но, к сожалению, это решение не может быть реализовано. Веб-интерфейс Solr Admin предоставляет базовую статистику, но по сравнению с инструментами мониторинга Elasticsearch Solr сильно отстает. Пример Solr Admin показан на следующем рисунке: Рисунок 6: Solr мониторинг встроенных объектов Одним из больших недостатков Solr является невозможность индексации встроенных (вложенных) документов. Пример такого документа можно увидеть здесь: < _id: » «, title: «Красивый заголовок», author_info: < имя: «Джон», фамилия: «Доу», рождение: » » Запись author_info является вложенным документом. Есть выход из этой ситуации, а именно преобразовать вложенный документ в плоскую структуру, например следующим образом: < _id: » «, title: «Красивый заголовок», author_info_name: «Джон», author_info_surname: «Доу», author_info_birth: » » 25
35 Solr уже мог работать с таким документом. К сожалению, в тот момент, когда (в данном конкретном случае) было бы, например, больше авторов, реализовать такую структуру было бы сложно. Отдельные поля пришлось бы начинать нумеровать: author_info_name1, author_info_name2, что приводит к невозможности поиска по такому элементу, сложно задать запрос в смысле: ГДЕ author_info_name1=»john» ИЛИ author_info_name2 = «john». В Solr есть возможность пометить поле как многозначное, но она подходит и для других целей, например для простого списка ключевых слов. Он не подходит для более сложной информации. Elasticsearch же без проблем работает с вложенными документами. Проблема разделения мозга Это явление может возникнуть, когда база данных (либо Elasticsearch, либо Solr) работает распределенно в нескольких экземплярах. Один узел всегда действует как ведущий, и только один можетпринимать запросы на регистрацию новых документов. Затем другие узлы (подчиненные) внутренне реплицируют записанные данные и обслуживают запросы на чтение данных. В тот момент, когда сеть между этими узлами выходит из строя по какой-либо причине, подчиненные узлы предполагают, что что-то случилось с главным узлом, и берут на себя его роль. Это создает два главных узла, каждый из которых получает часть запросов на запись, и это приводит к фатальной несогласованности данных. Кроме того, приложение может претендовать на работоспособность, что еще больше усугубит проблему. Solr решает эту проблему, вводя единый референтный узел ZooKeeper [12], который существует только в одном экземпляре и отвечает за определение главных узлов. Таким образом, ZooKeeper может работать со сбоем узла напрямую, а в случае сбоя узла все приложение станет нефункциональным, что предотвратит появление несогласованных данных. Хотя Elasticsearch не устойчив к проблеме разделения мозга в конфигурации по умолчанию, все можно решить, отредактировав одну строку в конфигурации. Это элемент discovery.zen.minimum_master_nodes, и его значение говорит, сколько узлов должно быть видно друг другу, чтобы выбрать своего мастера. Установка этой директивы на N/2+1, где N — общее количество узлов в кластере, гарантирует, что ситуация с разделенным мозгом вообще не может возникнуть.13] Ряд англоязычных книг был загружен в текстовом формате. В сумме это 25 МБ чистого текста. Книги были объединены в одну 26
36 файлов и разделены на абзацы. В результате получилось несколько абзацев со средней длиной 150 слов/абзац. Затем каждый абзац использовался при вводе в базу данных как отдельный проиндексированный документ. Впоследствии для каждой базы данных было составлено несколько различных сценариев вставки документов, ихчтение, а также взаимное параллельное выполнение этих операций с разной интенсивностью. Измеряемой переменной было либо количество документов, которые база данных может прочитать/индексировать за определенное время, либо, в случае вставки записей, время, которое потребовалось для вставки определенного количества документов. Каждый сценарий повторялся несколько раз для получения более точных результатов. Эталонная машина, на которой проводились тесты, имела следующую конфигурацию: Macbook Pro Retina (начало 2013 г.) Intel Core i5, 2,6 ГГц, 8 ГБ ОЗУ, 256 ГБ SSD-накопитель Программное обеспечение: OSX 10.9 Mavericks Java: 1.6.0_65 Solr: Elasticsearch, сценарий 1, время встраивания один миллионов документов в пустую базу данных, без чтения. Сценарий 2 Эксперимент/база данных Elasticsearch [мс] Solr [мс] Таблица 3: Сравнение производительности 1 В базе данных содержится миллион документов, считываемых в одном потоке в течение 30 секунд. Измеряется количество прочитанных документов. Эксперимент/база данных Elasticsearch [количество] Solr [количество] Таблица 4: Сравнение производительности 2 27
