СанктПетербургский государственный университет
 Скачать 0.75 Mb.
|
|
3.2. Наборы данных для тестирования Для тестирования СУБД были подобраны два набора метаданных из разных источников. Датасеты представляют собой структурированные наборы данных, чтоб бы можно было протестировать СУБД не только на запись и чтение данных, но и более сложных запросах. Полная структура экземпляров двух наборов “amazon-meta” и “All_Viruses.gene_info” приводится в Приложении[2] (рис.1, рис.2). Таблица описание наборов данных наим. All_Viruses.gene_info amazon-meta краткое описание часть набора gene_info из базы данных геномов часть набора данных amazon-meta.txt, содержит собранную информацию о продуктах с amazon количество записей 322.547 300.000 общий размер файла 147 Мб 971 Mб атрибуты 1. tax_id 2. GeneID 3. Symbol 4. Locus Tag 5. Synonyms 6. dbXrefs 7. chromosome 8. map_location 9. description 10. type_of_gene 11. Symbol_from_nomenclature _authority 12. Full_name_from_nomenclat ure_authority Nomenclature_status 13. Other_designations 14. Modification_date 1. Id 2. ASIN 3. title 4. group 5. salesrank 6. similar 6.1. total 6.2. asin 7. categories 7.1. total 7.2. categories 8. reviews 8.1. total 8.2. downloaded 8.3. avg_rating 8.4. reviews 8.4.1. data 8.4.2. customer 8.4.3. rating 8.4.4. votes 8.4.5. helpful источник ftp://ftp.ncbi.nih.gov/gene/DATA/GE NE_INFO/Viruses/All_Viruses.gene_ info.gz https://snap.stanford.edu/data/bigdata/amazon/am azon-meta.txt.gz Табл.2 13 3.3. Обзор инструментов и метрик тестирования Сравнение производительностей баз данных довольно распространенная задача. Реализовано большое количество тестов, многие из которых находятся в открытом доступе и при желании их можно воссоздать на собственной машине. Часто тесты, например, как в статьях[1,15], создаются под определенную нагрузку, и имеют задачу продемонстрировать лучшие характеристики определенной базы данных, на специально подобранных наборах данных и запросах, которые в большей мере отразят желаемые показатели. Такие тесты раскрывают возможности выбранной СУБД, а запросы к другим сравниваемым базам данных обычно редко оптимизируют исходя из их особенностей, поэтому возможен не совсем объективный результат. В некоторых работах [6,8] наоборот сравнивают более общие показатели СУБД, касающиеся модели хранения, поддержки согласованности, и других характеристик, не связанных с хранимыми данными. Выбор СУБД для сравнения определяется задачами, которые ставятся в статье, или темой, которую исследуют авторы. Например, как в статье [2] тестируются две мульти-модельные СУБД и две другие СУБД, имеющие разные модели хранения, которые объединяют для хранения одного специально синтезированного набора. Авторы сравнивают производительность выбранных средств хранения, когда требуется использование двух NoSQL-схем в одном приложении. В зависимости от сформулированных запросов СУБД с наилучшей производительностью меняется. В данной работе нас больше интересует сравнение производительности и анализ СУБД для организации хранения метаданных, мы рассматриваем базы данных с различными моделями хранения на двух наборах данных разных по структуре. Для некоторых замеров, например, определения операционной задержки определенного запроса, можно воспользоваться возможностями самой СУБД, для определения пропускной способности и создания большей 14 нагрузки на систему можно разработать собственные тесты, однако существуют и готовые довольно гибкие решения для воссоздания разных типов нагрузки на базы данных, например, для тестирования NoSQL баз данных распространен инструмент YCSB (Yahoo! Cloud Serving Benchmark) (например, [4,7]). Он имеет несколько профилей нагрузки, различающихся соотношением количества выполняемых операций на запись и чтение или чтения и обновления, при которых и прогоняет базы данных на наборе тестов. Тестирование с помощью данной утилиты отражает общие характеристики: пропускную способность и время ожидания работы баз данных. Основной целью является разработка рабочих нагрузок для хранилищ «ключ-значение» или облачных хранилищ и сравнение производительности в созданных условиях. Важное значение при тестировании имеют характеристики окружения, то, где будет располагаться сервер базы данных, храниться данные и запускаться тесты при желании масштабирования системы и создания кластера, но отсутствии требуемого оборудования, можно воспользоваться возможностями облачных сервисов. Так, довольно часто для тестирования больших нагрузок разворачивают кластер базы данных на серверах от Amazon (Amazon Web Services), которые предоставляют дополнительные вычислительные возможности для хранения и анализа производительности баз данных, такие как EC2 (the Elastic Compute Cloud) и EBS (Elastic Block Storage) (например, [9,10]). С помощью собственных скриптов и дополнительных инструментов сервис позволяет тестировать базы данных. Использовать для замеров производительности можно как собственную тестовую систему, так и, например, утилиту YCSB (как в статье [10]). В данной работе на начальных этапах - определения схемы хранения и пробных замерах времени при исполнении запросов и операций загрузки данных и вставки, базы данных тестируются без использования внешних ресурсов. На последующих этапах при загрузке больших объемов данных и тестировании предполагается развернуть базы данных на кластере. Для 15 тестирования необходимо выбрать подходящий инструмент. Например, в статье [5] рассматривается разработка инструмента тестирования, а также возможные сценарии. На первом этапе замеры, осуществляются возможностями СУБД. Для составления верной оценки и выбора СУБД, которая будет больше соответствовать нашей задаче, важно правильно определить метрики, которые будем измерять и их условия. В качестве ключевых метрик сравнения баз данных могут быть рассмотрены разные показатели, наиболее подробно возможные метрики описываются в статье [9]. Исходя из цели данной работы, для тестирования были выбраны следующие метрики: Операционная задержка (operational latency) - данная метрика будет измерять задержку выполнения запроса. Параллельно будет запущенно несколько потоков, которые непрерывно будут отправлять системе запросы и будем замерять разницу в секундах между отправлением запроса и получением результата от системы. Пропускная способность (throughput) - измерение количества выполненных операций(запросов) за единицу времени. Использование дискового пространства (disk space usage) - измеряем размер, занятый данными, метаданными и другими вспомогательными структурами системы базы данных. Системная нагрузка (system load) - анализируем использования CPU, памяти и диска на протяжении эксперимента. Собираются данные о нагрузке каждые 5 секунд во время тестирования системы. 16 4. Основная часть 4.1. Определение схемы хранения данных Поскольку для системы хранения метаданных может быть необходима поддержка хранения нетипизированных данных или гибкость схемы, преимуществом является то, что в NoSQL базах данных, таких как ArangoDB и MongoDB, не требуется определять схему и можно добавлять документы в формате JSON. Датасеты можно сразу загрузить в базы данных в соответствующие коллекции. Можно сравнить насколько эффективен такой способ хранения для управления. Для этого рассмотрим небольшую часть данных каждого набора, и загрузим их в базы данных таким образом, что каждый набор будет храниться в одной коллекции. От каждого набора взяли для эксперимента по 5.000 записей и загрузили их в отдельные коллекции в базы данных ArangoDB и MongoDB (как в Приложение[1]). Первый набор имеет достаточно простую структуру и данный способ хранения не скажется на эффективности управления данными. Рассмотрим более подробно часть второго набора “amazon-meta”, на примере выполнения запросов проанализируем усложняет ли данная схема хранения поиск или анализ данных. Исходя из структуры документа (Приложение[2], рис.1) были выбраны следующие запросы: 1. Запрос, возвращающий продукты, для которых были написаны отзывы конкретного числа (Приложение[1.7.1]). 2. Запрос, возвращающий несколько первых продуктов с максимальным числом отзывов (Приложение [1.7.2]). 3. Запрос, возвращающий оценку нашего товара и схожих с ним (Приложение [1.7.3]). 4. Запрос, возвращающий группы товаров и количество товаров в каждой группе (Приложение [1.7.4]). 17 Измерили время выполнения данных запросов и добавление документа - для некоторых запросов в ArangoDB возможно сократить среднее время, изменив схему хранения. Так как при исходной схеме параметризованные атрибуты в запросах являются глубоко вложенными и на текущий момент их индексация в данной СУБД не поддерживается, можем воспользоваться следующей возможностью ArangoDB - хранить документы в виде графов. Представим нашу коллекцию в виде нескольких связанных коллекций вершин и ребер (связей). В наборе “amazon-meta” выделим отдельно коллекцию отзывов и коллекцию оставшихся частей документов, а для связей между ними и связей между схожими продуктами создадим коллекции-ребра. Новая структура документа набора “amazon-meta” теперь состоит из нескольких документов и имеет вид, приведенный в табл.3. Будем загружать в таком виде коллекции в ArangoDB (Приложение [1.2]). product_meta similars_edges Reviews rev_edges Id ASIN _key title group salesrank categories reviews total downloaded avg_rating _from _to _key data customer rating votes helpful _from _to Табл.3 С ростом желания поддержки гибких схем развивались и реляционные базы данных, так, в PostgreSQL появились типы столбцов json и jsonb. Благодаря чему можно загрузить документы набора “amazon-meta” целиком в базу данных в PostgreSQL, однако, при такой загрузке мы также не сможем оптимизировать запросы, используя индексы по атрибутам в глубоко вложенной структуре документа. Поэтому воспользуемся представлением из табл.3, создав таблицы со столбцами типа jsonb. Для загрузки первого набора “all_viruses” также создадим таблицу со столбцом типа jsonb (Приложение[1.5]). 18 В MongoDB при загрузке набора “amazon-meta” в виде нескольких коллекций некоторые сложные запросы невозможно будет реализовать, используя на уровне СУБД, так как в ней не поддерживаются join и придется использовать дополнительный модуль для реализации операций map-reduce. Поэтому при тестировании будем рассматривать первую схему хранения - в одной коллекции (Приложение[1.3-1.4]). Apache Cassandra не позволяет нам хранить документы произвольной структуры без потери функциональности. Если документ имеет сложную структуру и мы не можем определить его схему, приходится хранить его как строку и становится невозможным ни выполнять поиск по атрибутам, ни управлять данными в коллекции. Такой способ хранения не является оптимальным. Так как хотим сравнить время выполнения запросов в данной СУБД, то должны определить его схему в базе данных. Исходный набор “amazon-meta” содержит вложенные структуры, которыми сложно управлять в Apache Cassandra, поэтому для более эффективного управления загрузим этот набор, разделенный по отдельным коллекциям (как в табл.3) и создадим для него схему, где столбцы – атрибуты документов из табл.3. Также для загрузки первого набора “all_viruses” в Apache Cassandra определим схему, соответствующую представлению документа в табл.1. 19 4.2. Описание данных и особенности СУБД Рассмотрим подробнее два выбранных набора данных и посмотрим их наиболее вероятные сценарии использования. Исходя из особенностей структур наборов, определим на каких запросах к этим наборам будем тестировать СУБД. Первый набор не имеет вложенных структур и все типы атрибутов являются простыми, в данном случае атрибут - либо число, либо строка. Один из наиболее вероятных сценариев использования набора “all_viruses” – анализ (группировки, выборки, другие операции реляционной алгебры), т.е. потенциально более ориентирован на выполнение с ним OLAP-операций. Второй набор является иерархическим с множеством вложенных параметров, которые могут быть различны. Набор данных “amazon-meta” меньше подходит для аналитики, с таким видом представленных метаданных обычно выполняют мелкие транзакции, такие как операции вставки, обновления, т.е. данная коллекция больше ориентирована на выполнение OLTP-операций. При разработке тестов учтем возможные сценарии использования наборов. Рассмотрим, во время тестирования, разные запросы к этим коллекциям исходя из целей их наиболее вероятного использования. Так при тестировании на первом наборе данных, мы измеряем операционную задержку и пропускную способность, не только на запись и чтение строк, но и рассматриваем три запроса: выборка документов по значению атрибута, лежащего в заданном диапазоне, группировка и сортировка по выбранному атрибуту. Запросы к базам данных приводятся в Приложении[1]. При тестировании на втором наборе большее внимание стоит обратить на операции записи, чтения, но так как в работе рассматриваются и возможности управления данными на уровне СУБД, то протестируем также на некоторых запросах со сложно структурированным набором данных, такие как выборка с вложенным подзапросом, сортировка по вложенному 20 атрибуту и группировка с большим числом возможных групп. Запросы приводятся в Приложении[1]. Некоторые СУБД плохо подходят для выполнения сложных аналитических операций без использования дополнительных ресурсов и менее гибкие в этом отношении, так, например в Apache Cassandra нельзя выполнить сортировку по любому атрибуту документа заранее при создании таблицы не указав CLUSTERING ORDER по этому атрибуту, также язык CQL не обладает поддержкой вложенных запросов, поэтому не удалось реализовать и протестировать данную СУБД на некоторых запросах. Исходя из особенностей разных типов СУБД и их ориентированности на разные операции[18], показатели могут сильно разнится на запросах, будем искать наиболее оптимальное решение на основе проводимых замеров. 21 4.3. Методика тестирования Для тестирования, определим, каким образом будем работать с базами данных, отправлять запросы и фиксировать метрики. Рассматриваем СУБД со следующими характеристиками ArangoDB v.3.1.17, MongoDB v.3.2, Postgresql 9.6, Apache Cassandra v3.0.9. Для замеров посылаются семантически эквивалентные запросы к разным СУБД – выполняются транзакции, операции записи, чтения и выбранные запросы для первого набора данных (Приложение[1.8-1.11]) и второго набора данных (Приложение[1.12-1.15]). Работа с базой данных организуется таким образом: в программе запускаются несколько потоков, параллельно отправляющие запросы к базе данных, общее число выполняемых операций в потоке 1000, во время работы фиксируются показатели, которые нужно измерить. Перед запуском основного тестирования, базы данных разогреваются, выполняя несколько раз те же запросы, что и в самом тесте. Для всех коллекций во время выполнения любых транзакций выполняется синхронизация данных на диск. 22 4.4. Тестирование операционной задержки Одним из важных показателей производительности системы является время между отправкой запроса и получением ответа от системы – операционная задержка (operational latency). Данный показатель может быть определен как сумма времени операций, когда выполняется в линейных рабочих процессах или как время самой медленной операцией, выполняемой одним рабочим потоком, когда выполняется в параллельных рабочих процессах. При увеличении данных и росте системы возрастает стоимость времени отклика. Однако низкая задержка может достигаться в ущерб сохранности данных (durability and consistency). Сохранение данных на диске и синхронизация гарантируют их прочность (durability), но увеличивает задержку, несинхронизация записи на диск влечет уменьшение задержки и увеличение пропускной способности, но и снижает гарантии долговечности данных. Обеспечение сохранности и согласованности данных гарантирует нам корректный результат выполнения запроса в любой момент и то, что данные не будут утеряны при сбое системы, поэтому при тестировании будем обеспечивать в системах синхронизацию данных на диск. В данной работе для измерения операционной задержки параллельно запускались несколько потоков, которые непрерывно отправляли системе запросы, замеряя разницу в секундах между отправлением запроса и получением результата от системы, затем считалась средняя задержка для потока и брался самый медленный результат среди одновременно запущенных потоков. Операционную задержу к рассматриваемым СУБД измеряем для операций записи и чтения документа, и на выбранных запросах: для первого набора это операции выборки, сортировки и группировки, скрипты запросов в Приложении [1.8-1.11] и для второго набора были написаны запросы с вложенными атрибутами и вложенными подзапросами, скрипты в 23 Приложении[1.12-1.15]. Результаты представлены на диаграммах (рис.1- рис.4) Первый набор “Viruses” Рис.1 Второй набор “Amazon-meta” Рис.2 Первый набор “Viruses” Рис.3 Второй набор “Amazon-meta” Рис.4 Запрос1: выборка по атрибуту – ‘дата изменения записи’, за определенный период. Дата изменения генерируется случайным образом в программе при тестировании. |