СанктПетербургский государственный университет
 Скачать 0.75 Mb.
|
|
Санкт-Петербургский государственный университет Математическое обеспечение и администрирование информационных систем Информационно-аналитические системы Говоруха Оксана Сергеевна Анализ СУБД в качестве основы для построения системы управления метаданными Выпускная квалификационная работа Научный руководитель: д. ф.-м. н., профессор Нестеров В. М. Санкт-Петербург 2018 SAINT-PETERSBURG STATE UNIVERSITY Software and Administration of Information Systems Analytical Information Systems Govorukha Oxana Performance Analysis of DBMS as foundation of metadata management system Graduation Project Scientific supervisor: Ph.D., Professor Vyacheslav Nesterov Saint Petersburg 2018 1 Содержание Введение .......................................................................................................................... 2 1. Цель работы ............................................................................................................... 4 2. Задачи ......................................................................................................................... 5 3. Обзор ............................................................................................................................ 6 3.1 Обзор СУБД .................................................................................................... 6 3.2 Наборы данных для тестирования ............................................................... 12 3.3 Обзор инструментов и метрик тестирования ............................................. 13 4. Основная часть ......................................................................................................... 16 4.1 Определение схемы хранения данных ....................................................... 16 4.2 Описание данных и особенности СУБД .................................................... 19 4.3 Методика тестирования ............................................................................... 21 4.4 Тестирование операционной задержки ...................................................... 22 4.5 Тестирование пропускной способности...................................................... 24 4.6 Измерение использования дискового пространства ................................. 26 4.7 Анализ системной нагрузки ........................................................................ 27 5. Заключение ............................................................................................................... 28 5.1. Результаты ..................................................................................................... 28 5.2. Итоги ............................................................................................................... 28 Литература .................................................................................................................... 31 Приложение .................................................................................................................. 33 1. Скрипты для загрузки и запросов .................................................................. 33 2. Образцы наборов данных ............................................................................... 35 2 Введение При растущем объеме информации мы сталкиваемся с проблемой рационального управления данными. Оптимальная система поиска и хранения данных помогает не только быстрее находить объекты с нужными атрибутами, но и анализировать данные. Реализация такой системы невозможна без явно представленных описаний свойств данных - метаданных. Метаданные хранят основную информацию об объекте, обеспечивают сохранность данных и защищают от несанкционированного доступа. Они существенно повышают ценность данных и обеспечивают более широкие возможности их использования. Содержание метаданных, их структура, функции и средства их представления зависят от описываемых ресурсов, предметной области использующих их систем, контекста и характера их использования, а также от многих других факторов. Метаданные могут храниться вместе с объектом, что гарантирует, что они не будут потеряны и при изменении будут обновлены вместе. Однако не всегда возможно встроить метаданные в некоторые типы объектов, кроме того хранение метаданных отдельно может улучшить и упростить поиск этих объектов. Поэтому метаданные часто хранятся в базе данных и «связывают» с описываемыми объектами[3]. Использование различных СУБД может требовать разного способа представления данных, а также влиять на легкость управления данными. Поэтому выбор системы для хранения метаданных является важным решением. Для выбора такой системы важно рассмотреть СУБД с разными моделями хранения данных, так как структура метаданных может быть различна, необходимо оценить эффективность той или иной модели представления данных и сравнить возможные схемы хранения. Конечно, важное значение имеют стандарты для представления метаданных, которые определяют схему хранения и позволяют легче переиспользовать данные в дальнейшем и управлять ими. Однако, часто встречаются метаданные с 3 нефиксированным набором атрибутов или имеющие сильно иерархическую структуру, что затрудняет определение схемы. Это нужно учитывать при выборе хранилища данных. Поэтому требуется оценить сложность представления метаданных с различной структурой в разных базах данных. С увеличением количества данных, возрастает сложность управления этими данными, растет время записи, чтения или просмотра метаданных. Поэтому необходимо протестировать производительности СУБД для определения этих показателей и проанализировать системы для выявления оптимального решения в качестве хранилища метаданных. В данной работе будем тестировать на различных по структуре наборах метаданных. Для анализа выберем наиболее распространенные системы управления базами данных, имеющие разные модели хранения данных. Сравним из относительно ключевых характеристик в контексте цели данной работы и измерим их производительность при работе с метаданными на разных запросах и выполняя операции записи и чтения. 4 1. Цель работы В данной работе была поставлена следующая цель: ● Сравнить СУБД с разными моделями хранения данных на примере разных наборов метаданных, оптимизируя хранение выбранных наборов в БД с учетом преимуществ и особенностей СУБД, определить наиболее оптимальное решение в качестве хранилища для системы управления метаданными 5 2. Задачи В связи с поставленной целью были выделены следующие задачи: ● Рассмотреть основные характеристики систем управления базами данных ● Найти и подготовить наборы данных для тестирования ● Определить метрики тестирования, методологию и инструменты ● Определить схемы хранения наборов данных ● Подготовить скрипты для загрузки данных, выполнения запросов, чтения и записи данных ● Произвести замеры на различных наборах ● Сравнить результаты, полученные при тестировании разных систем на различных наборах 6 3. Обзор 3.1. Обзор СУБД В данной работе будем исследовать следующие СУБД: ArangoDB, MongoDB, Apache Cassandra и PostgreSQL. Рассмотрим их основные характеристики и ключевые отличия относительно требуемой задачи. ArangoDB - мульти-модельная СУБД, поддерживает различные модели хранения данных в виде графа, документов или как ключ/значение[11]. Документы передаются в формате JSON 1 . Все документы группируются в коллекции, внутри коллекции документы могут иметь различные атрибуты. Существуют два типа коллекций: коллекция документов (вершин), которая имеет обязательные атрибуты id и key, и коллекция ребер, имеющая атрибуты from и to, для создания связей между документами в базе. Возможно выполнение сложных запросов и управление данными с помощью AQL (Arango Query Language). Существуют специальные драйверы, позволяющие использовать базу данных через различные среды и языки программирования. Для ускорения поиска поддерживаются индексы. С v1.3 возможно определение транзакций пользователем. Для всех транзакций в ArangoDB выполняются ACID 3 свойства, кроме операций над несколькими документами или коллекциями при распределенном хранении данных на кластере. Архитектура кластера ArangoDB представляет собой master/master без единой точки отказа. Для различных случаев выделяются следующие роли: агенты, координаторы, основной и вторичный сервера. Каждому элементу кроме агентов выделяется id, по которому будет происходить взаимодействие внутри кластера. Конструкция кластера Arango позволяет минимизировать 1. JSON (JavaScript Object Notation) – текстовый формат обмена данными, имеющий структуру ключ: значение или упорядоченный список значений [16]. 2. ACID (Atomicity, Consistency, Isolation, Durability) – свойства атомарности, согласованности, независимости и устойчивости, обеспечивающие для СУБД наиболее надежную и предсказуемую работу. 7 администрирование и должна обеспечивать самостоятельное восстановление в случае временных сбоев. MongoDB - документно-ориентированная NoSQL база данных[14]. Все записи хранятся как BSON-объекты 3 . Документы могут иметь различную структуру в пределах одной коллекции, с v3.2 можно определять правила валидации для коллекции во время обновления или вставки. В базе определены некоторые ограничения для хранимых документов: порядок полей, размер документа, наличие id. Существует множество вариантов внешнего REST 4 интерфейса для MongoDB и различные драйверы для простой работы с базой данных из разных сред и с разными языками программирования, поддерживающие все основные операции. В MongoDB операция записи атомарна только на уровне одного документа. Для того, чтобы изолировать операцию записи, которая затрагивает несколько документов, можно использовать дополнительный изоляционный оператор. База данных позволяет чтение незафиксированных записей. Для ускорения поиска также возможна индексация полей. MongoDB поддерживает репликацию для увеличения доступности, и шардинг для распределенного хранения данных. Репликация может быть представлена набором реплик или master/slave. В наборе реплик поддерживается автоматическая отказоустойчивость в случае прекращения работы основного сервера. Кластер в MongoDB состоит из сервера маршрутизации, шардов и сервера конфигураций. Возможно одновременное хранение разделенных и неразделенных данных. Дополнительно в MongoDB предоставляются функции для аутентификации, управления доступом и 3. BSON (Binary JavaScript Object Notation) - формат электронного обмена цифровыми данными, бинарная форма представления простых структур данных и ассоциативных массивов (объектов), подмножество JSON, включающее дополнительно регулярные выражения, двоичные данные и даты [17]. 4. REST (Representational State Transfer) - архитектурный стиль взаимодействия компонентов распределённого приложения в сети, представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой системы. 8 шифрования. Cassandra - распределённая система управления базами данных, относится к NoSQL и предназначена для обработки и хранения больших объемов данных, обеспечивая высокую доступность без единой точки отказа[12]. Представляет гибридную модель ключ/значение и колоночно- ориентированной модели. Каждому ключу в базе соответствует определенный объект - набор столбцов. Столбцы объединяются в группы - семейство столбцов (таблицы). Ключ может идентифицировать строку из переменного числа элементов. Колонка в базе данных состоит из трех частей: имени, метки времени и значения. Возможно выполнять запросы для определения и изменения данных при помощи CQL (Cassandra Query Language). Не поддерживается выполнение join или подзапросов. Конкретное значение, хранимое в базе, идентифицируется однозначно следующими атрибутам: пространством ключей (оно позволяет на одном кластере размещать данные разных приложений), колоночным семейством (осуществляет привязку к запросу), ключом (-привязка к узлу кластера), именем колонки (-привязка к атрибуту в записи, позволяет в одной записи хранить несколько значений). Запись в базу данных Cassandra осуществляется быстрее, чем чтение. Поддерживается транзакционность и выполнение свойств ACID на уровне одной записи - набора колонок с одним ключом. Узлы кластера - равноценны. Для координации между узлами и отправления им запросов используется координатор. При распределенном хранении возможно задать стратегию выбора узла кластера в зависимости от значения ключа. Можно регулировать временные задержки операций чтения, записи и настраивать согласованность и доступность каждого вида операций. PostgreSQL - реляционная система управления базами данных[13]. Любая таблица представляет собой именованный набор строк. Все строки таблицы имеют одинаковый набор именованных столбцов, при этом каждому столбцу назначается определённый тип данных. Таблицы объединяются в 9 базы данных, а набор баз данных, управляемый одним экземпляром сервера PostgreSQL, образует кластер баз данных. Для выполнения запросов используется язык SQL, позволяющий выполнять сложные вложенные запросы и использовать join. Для ускорения поиска возможна индексация по одному столбцу или набору. Поддерживаются транзакции на уровне базы данных. Существуют функции для хранения и работы с файлами и JSON данными. Для шардинга PosgreSQL существует несколько решений: Postgres-XC, PL/Proxy, HadoopDB, Greenplum Database. Рассмотрев общие характеристики выбранных СУБД, выделим ключевые для системы хранения метаданных и управления ими и сравним СУБД относительно них. Так как метаданные могут иметь сложную иерархическую структуру или быть неструктурированными, для СУБД важно иметь возможность хранения такого вида данных, например, с помощью поддержки хранения данных типа JSON или возможности изменения схемы в любой момент работы с базой данных (гибкость схемы). При этом, даже при сложной структуре метаданных необходимо исключать вероятность добавления некорректных данных, на уровне СУБД этого можно добиться с помощью поддержки валидации данных. Для управления данными, ускорения поиска по определенным атрибутам, сортировки элементов и анализа полезна индексация, поддерживается ли она СУБД и то, каким способом она осуществляется, сказывается на эффективности управления данными в базе. Метаданные или некоторые атрибуты в них, могут быть совсем не типизированы и представлять собой текстовый тип, однако по таким данным может быть необходимо тоже выполнять поиск, например, для выделения данных содержащих определенные слова или атрибуты, в таких случаях будет полезна поддержка полнотекстового поиска. Также, немаловажен язык запросов, поддерживаемый СУБД, он должен быть достаточно гибкий для 10 выполнения сложных запросов на уровне базы данных, что может обеспечить более быстрый и эффективный поиск. При увеличении количества данных и масштабируемости системы важную роль играют скорость чтения и записи данных и поддержка их согласованности. Обеспечение полной согласованности данных и их долговечности может влиять на производительность, однако это поддерживает корректность данных в любой момент времени и исключает их потерю в случаи сбоя системы. Сравнение по ключевым характеристикам представлено в Табл.1 Таблица сравнения СУБД ArangoDB MongoDB Cassandra PostgreSQL модель хранения данных Мульти - модельная СУБД Документо - ориентированная СУБД Модель ключ - значение и колоночно – ориентированная Реляционная СУБД хранение неструктурир ованных данных Возможно различное количество атрибутов и разные типы значений в документах в одной коллекции. Возможно различное количество атрибутов и разные типы значений в документах в одной коллекции. Семейство столбцов определяется заранее. Для каждого ключа – разное число колонок. Схемы таблиц определяются заранее. Поддержка JSON. валидация атрибутов Нет Возможно типизировать значения атрибутов. Типы атрибутов описываются при определении схемы и не изменяются. Типы полей указываются при создании таблицы и не изменяются. индексация Индексация по одному или нескольким атрибутам. Автоматическая индекация id и key или from и to Индексация по одному или нескольким атрибутам. Автоматическая индексаця Id. Обязательно Primary Key. Возможен вторичный индекс. Возможна индексация по одному или нескольким полям. При хранении данных в формате JSON также возможна индексация операции чтение/запись Отложенная запись только для документов, касающихся одной коллекции (увеличивает пропускную способность). Асинхронная запись (увеличивает пропускную способность, но возможно незафиксированное чтение). Операция записи работает быстрее, чем чтение. (На времени записи и чтения сказывается устанавливаемый уровень согласованности данных). Время выполнения операций чтения и записи может увеличиваться в зависимости от типа индекса и количества данных 11 поиск Возможны сложные вложенные запросы и аналог join с помощью AQL. Возможен поиск по шаблону и фильтрация. Только несложные запросы с помощью CQL. Возможны сложные вложенные запросы и join с помощью SQL обеспечение согласованнос ти данных Возможны пользовательские транзакции. Выполнение ACID. (кроме операций над распределенными данными на кластере). Запись атомарна только на уровне документа. Можно изолировать несколько операций (но при ошибки не будет выполнен откат всех изменений). Возможно чтение незафиксированных записей. Атомарность действует на уровне одной строки. Возможно определять уровень согласованности данных. Возможно выполнение транзакций на уровне всей базы данных. Для всех транзакций выполняются ACID. Табл.1 12 |