СанктПетербургский государственный университет
 Скачать 0.75 Mb.
|
|
Запрос2: группировка по типам генов. Запрос3: сортировка записей по атрибуту – ‘дата изменения’. Запрос1: выборка c вложенным подзапросом, всех записей с отзывами определенного числа. Дата генерируется случайным образом в программе при тестировании. Запрос2: сортировка по вложенному атрибуту. Запрос3: группировка по типам товаров 0 0,005 0,01 0,015 0,02 0,025 0,03 0,035 0,04 write read сек ArangoDB MongoDB Postgresql Cassandra 0 0,02 0,04 0,06 0,08 0,1 0,12 write read сек ArangoDB MongoDB Postgresql Cassandra 0 1 2 3 4 5 6 query1 query2 query3 сек ArangoDB MongoDB Postgresql Cassandra 0 2 4 6 8 10 12 query1 query2 query3 сек ArangoDB MongoDB Postgresql Cassandra 24 4.5. Тестирование пропускной способности Необходимым показателем для оценки производительности СУБД является пропускная способность системы (throughput). Данная метрика измеряется количество выполненных транзакций за фиксированную единицу времени. Пропускная способность связана с операционной задержкой и также зависит от синхронизации данных СУБД. В тестах замерили количество операций чтения, записи и выбранных запросов (Приложение [1.8-1.15]) в секунду, запущенных в несколько параллельно выполняемых потоках для двух датасетов, результаты для ArangoDB, PostgreSQL, MongoDB и Cassandra представлены в виде графиков (рис.5 - рис.14), где нижняя ось – количество параллельно запущенных потоков, что позволяет отследить изменения пропускной способности при увеличении нагрузки на СУБД. Первый набор “Viruses” – “Чтение” Рис.5 Первый набор “Viruses” – “Запись” Рис.6 Второй набор “Amazon-meta” – “Чтение” Рис.7 Второй набор “Amazon-meta” – “Запись” Рис.8 0 50 100 150 200 250 300 350 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql Cassandra 0 50 100 150 200 250 5 10 15 20 оп/сек 0 50 100 150 200 250 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql Cassandra 0 50 100 150 200 250 5 10 15 20 оп/сек 25 Первый набор “Viruses” – Запрос1 (выборка) Рис.9 Первый набор “Viruses” – Запрос2 (групп.) Рис.10 Первый набор “Viruses” – Запрос3 (сортировка) Рис.11 Вт. набор “Amazon-meta” – Запрос1 (выборка) Рис.12 Вт.набор “Amazon-meta”– Запрос2(сортировка) Рис.13 Вт. набор “Amazon-meta” – Запрос3 (групп.) Рис.14 0 10 20 30 40 50 60 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql Cassandra 0 0,1 0,2 0,3 0,4 0,5 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql Cassandra 0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6 1,8 2 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql 0 0,05 0,1 0,15 0,2 0,25 0,3 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql 0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4 0,45 0,5 5 10 15 20 оп/сек ArangoDB MongoDB Postgresql Cassandra 26 4.6. Измерение использования дискового пространства Память на диске (disk storage) – это всегда критический ресурс для любых систем, необходимо мониторить количество свободного пространства на диске и также предусмотрительно рассчитывать занимаемые размеры базы данных, когда речь идет об использовании облачных хранилищ. При вычислении дискового пространства (disk space usage), занимаемого БД, следует учитывать размеры данных, метаданных и многих других вспомогательных структур системы базы данных. Из-за индексов и дополнительных структур для улучшения производительности, БД может занимать намного больше дискового пространства, чем может быть предусмотрено заранее с учетом действительных данных. Расчеты по занимаемому количеству дискового пространства рассматриваемых БД в ArangoDB, PostgreSQL, MongoDB и Cassandra, включая дополнительные построенные структуры в данных СУБД, представлены ниже (рис.15 – рис.16). Первый набор “Viruses” (disk space usage) Рис.15 Второй набор “Amazon-meta” (disk space usage) Рис.16 0 20 40 60 80 100 120 140 160 180 ArangoDB MongoDB Postgresql Cassandra MB 0 500 1000 1500 2000 2500 ArangoDB MongoDB Postgresql Cassandra MB 27 4.7. Анализ системной нагрузки Метрики использования памяти, диска и CPU при выполнении транзакций, наряду с другими метриками измерения производительности, так же являются важными показателями эффективности доступа к данным. Поэтому, мы проанализировали системную нагрузку (system load), т.е. измерили использование CPU, памяти и диска на протяжении тестирования. Данные о нагрузке собирались каждые 5 секунд во время тестирования системы и вычислялась средняя нагрузка. Результаты представлены в диаграммах (рис. 17 – рис. 18 ). CPU Рис.17 disk usage & RAM Рис.18 0% 10% 20% 30% 40% 50% 60% 70% 80% 0 500000 1000000 1500000 2000000 2500000 3000000 3500000 dusk usage (avr) RAM (avr) K ArangoDB; MongoDB Postgresql Cassandra 28 5. Заключение 5.1. Результаты При тестировании операционной задержки и пропускной способности на запись/чтение выявили, что в сравнении с другими СУБД MongoDB в среднем быстрее работает на выполнение этих операции с выбранными датасетами, чем другие рассматриваемые СУБД. Однако, при увеличении нагрузки она начинает уступать по этим показателям, сохраняя преимущество только при записи сложно структурированного документа. При большей нагрузке лучшие показатели на чтение и стабильность пропускной способности демонстрирует Cassandra. В большинстве рассмотренных аналитических запросов лидирует ArangoDB, но в запросе - выборке по первому набору, уступает по показателям Apache Cassandra. Минусом использования СУБД Cassandra может являться меньшая гибкость языка этой СУБД, в сравнении с SQL и возможностями, предоставляемыми ArangoDB и Mongo, и, как следствие - невозможность реализовать сложные запросы. При выполнении аналитических запросов Mongo и Postgresql по-разному обрабатывают запросы на уровне СУБД и их результаты разняться при тестировании на датасете с простой схемой и большим числом атрибутом, при работе именно с вложенными документами и выполнении с ними запросов Mongo лидирует, сразу после Arango, а при выборке с подзапросом даже превосходит. ArangoDB в свою очередь очень сильно уступает по записи и чтению документов из выбранных датасетов. Так, если рассмотреть в совокупности показатели замеров при выполнении операций на запись и чтение и запросах MongoDB демонстрирует в среднем более стабильные результаты, также данная СУБД предоставляет удобные средства для загрузки данных в базу. При тестировании было показано, что Mongo создает большую системную нагрузку на cpu, но использует во время работы намного меньше 29 памяти и диска, чем ArangoDB. Postgresql создает меньшую системную нагрузку, чем другие сравниваемые СУБД, но при этом хранение коллекций в данной СУБД занимает большее количество пространства. При оценке памяти на диске, занимаемого наборами в базах данных, Mongo лидирует при хранении сложно структурированного набора, так как в других СУБД для эффективного выполнения аналитических запросов пришлось его разбить на несколько коллекций/таблиц, что привело к увеличению занимаемого пространства на диске. Таким образом, основываясь на результатах и показателях выбранных метрик, можно выделить MongoDB как более оптимальное решение для хранения и работы с метаданными и слабоструктурированными или иерархическими данными. Минусом для определенных систем может являться отсутствие на данный момент в MongoDB обеспечения ACID свойств в полной мере, как в реляционных базах данных, однако с версии 4.0 заявляется их поддержка при транзакции с множеством документов, что будет являться ее преимуществом относительно других NoSQL-решений. 5.2. Итоги Таким образом, в данной работе, в пункте 3.1, были рассмотрены основные характеристики следующих СУБД ArangoDB, PostgreSQL, MongoDB и Cassandra, важные для обеспечения управления метаданными в базах данных. Для сравнения СУБД были выделены основные метрики, пункт 3.3, чтобы определить оптимальное решение в качестве хранилища для системы управления метаданными. В работе для тестирования СУБД были подобраны и подготовлены два разных по структуре набора метаданных (пункт 3.2), схемы хранения которых были оптимизированы с учетом особенностей СУБД, подробно рассмотрено в пунктах 4.1-4.2. Для определения производительности была определена методология тестирования (пункт 4.3), были разработаны скрипты для загрузки данных, 30 выполнения запросов, чтения и записи данных (скрипты запросов в Приложении[1.5-1.12]), были получены и наглядно представлены для сравнения результаты тестирования и замеров, выбранных метрик, приведено в пунктах 4.3-4.7. Анализ результатов и определение более оптимальный СУБД как основы для построения системы управления метаданными описаны в пункте 5.1. 31 Литература 1. Claudius Weinberger. Benchmark: PostgreSQL, MongoDB, Neo4j, OrientDB and ArangoDB [ https://www.arangodb.com/2015/10/benchmark- postgresql-mongodb-arangodb/ ].October 13, 2015 2. Fábio Roberto Oliveira, Luis del Val CuraPerformance. Evaluation of NoSQL Multi-Model Data Stores in Polyglot Persistence Applications. July 11 - 13, 2016 3. National Information Standards Organization; Rebecca Guenther; Jaqueline Radebaugh. Understanding Metadata. 2004 4. Jorge Bernardino, Pedro Furtado, Veronika Abramova. Which NoSQL Database?, 2014 5. Ion LUNGU, Bogdan George TUDORICA. The Development of a Benchmark Tool for NoSQL Databases. 2013 6. Rick Cattell, R. Scalable SQL and NoSQL data stores, 2011. 7. Bogdan George Tudorica, Cristian Bucur. A comparison between several NoSQL databases with comments and notes. 2011 8. Haleemunnisa Fatima, Kumud Wasni. Comparison of sql, nosql and new sql databases in light of internet of things – a survey. 2016 9. Alexandre Fonseca, Anh Thu Vu, Peter Grman. Evaluation of NoSQL databases for large-scale decentralized microblogging. 2013 10. John Klein, Ian Gorton, Neil Ernst, Patrick Donohoe, Kim Pham, Chrisjan Matser. Performance Evaluation of NoSQL Databases: A Case Study. 2015 11. https://docs.arangodb.com/3.3/Manual/index.html 12. http://cassandra.apache.org/doc/latest/ 13. https://www.postgresql.org/docs/10/static/index.html 14. https://docs.mongodb.com/manual/ 15. Claudius Weinberger. NoSQL Performance Benchmark 2018 – MongoDB, PostgreSQL, OrientDB, Neo4j and ArangoDB. February 14, 2018 16. http://json.org/json-ru.html 32 17. http://bsonspec.org/ 18. Jignesh M. Patel, Operational NoSQL Systems: What’s New and What’s Next? IEEE Computer, April 2016, IEEE Computer Society. 33 Приложение 1. Скрипты для загрузки и запросов 1. Скрипт первого набора в Arangodb: arangoimp --server.database viruses --file all_viruses.json --type json --collection all_viruses --batch-size 154980352 2. Скрипт загрузки второго набора в Arangodb: arangoimp –server.database amazon --file am_meta_vert.json --type json --collection am_meta_vert –batch-size 267726848 arangoimp –server.database amazon --file am_reviews_vert.json --collection am_reviews_vert –batch-size 744325120 arangoimp –server.database amazon --file am_rev_edges.json --collection am_rev_edges –batch-size 371912704 arangoimp –server.database amazon --file am_similar_edges.json --collection am_similar_edges –batch-size 88395776 3. Скрипт загрузки первого набора в MongoDB: mongoimport --db viruses --collection all_viruses --file all_viruses.json –jsonArray 4. Скрипт загрузки второго набора в MongoDB: mongoimport --db amazon --collection am_meta --file am_meta.json –jsonArray 5. Скрипт для Postgresql: Create database viruses; Create table all_viruses (id serial primary key, doc jsonb); Create database amazon; Create table am_meta_vert (id serial primary key, doc jsonb); Create table am_reviews_vert (id serial primary key, doc jsonb); Create table am_rev_edges (id serial primary key, doc jsonb); Create table am_similar_edges (id serial primary key,doc jsonb); (загрузчик данных в таблицы реализуется с помощью программы на C#) 6. Скрипт для Cassandra: Create keyspace viruses with replication={'class' : 'SimpleStrategy', 'replication_factor':1 }; Create keyspace amazon with replication={'class' : 'SimpleStrategy', 'replication_factor':1 }; (загрузчик данных в таблицы в пространстве ключей реализован с помощью программы на C#) 7. Запросы в ArangoDB при хранении набора метаданных Amazon в одной коллекции: 1. ‘RETURN LENGTH (FOR doc IN part_amazon FILTER (FOR rev IN doc.reviews.reviews FILTER rev.data == @data RETURN rev) != [ ] RETURN doc’; 2. ‘FOR doc IN part_amazon SORT doc.reviews.total DESC LIMIT 100 RETURN {‘title’: doc.title, ‘total_reviews’: doc.reviews.total}`; 34 3. ‘FOR doc1 IN part_amazon LET sim_rat = (FOR doc2 IN part_amazon FILTER doc2.ASIN IN doc1.similar.asin RETURN doc2.reviews.avg_rating) RETURN {‘title’: doc.title , ‘avg_rating’: doc1.reviews.avg_rating, ‘similar_ratings’: sim_rat}’; 4. ‘FOR doc IN part_amazon COLLECT group = doc.group WITH COUNT INTO g RETURN {‘group’: group, ‘InGroup’: g)’; 8. Запросы в ArangoDB к БД “Viruses”: 1. ‘FOR doc in all_viruses FILTER doc.Modification_date=@date RETURN doc’; 2.’FOR doc in all_viruses COLLECT type_of_gene = doc.type_of_gene RETURN {type: type_of_gene}’; 3. ‘FOR doc in all_viruses SORT doc.Modification_date RETURN doc’; 9. Запросы в MongoDB к БД “Viruses”: 1 .’ db.all_viruses.find({“Modification_date”: @data})’ 2.’ db.all_viruses.aggregate([{$group : {“type_of_gene:”$item”}}])’ 3. ‘db.all_viruses.find().sort( {“Modification_date”: -1} )’ 10. Запросы в Postgresql к БД “Viruses”: 1’select doc from all_viruses where doc @> '{"Modification_date":"@dat"}';’ 2 ‘select doc->'type_of_gene' from all_viruses group by (doc->'type_of_gene');’ 3 ‘select doc from all_viruses order by (doc->'Modification_date');’ 11. Запросы в Cassandra к БД “Viruses”: 1. ‘select * from Viruses.all_viruses where modification_date =@date’ 2. ‘select Viruses.group_and_count(type_of_gene) from Viruses.am_meta_vert;’ (aggregate - Viruses.group_and_count() – определяется заранее); 12. Запросы в ArangoDB к БД “Amazon”: 1. ‘ let k = (for i in am_rev_vert filter i.data == @date return distinct i.ASIN) for j in am_meta_vert filter j._key in k return j’ 2. ‘for j in am_meta_vert sort j.reviews.total desc return j’ 3. ‘for j in am_meta_vert collect group = j.group return {gr: group, 'count': count(group)}’ 13. Запросы в MongoDB к БД “Amazon”: 1.’ db.am_meta.find({“reviews.reviews”: {$elemMatch: {“data”: @data}}”})’ 2. ’ db.am_meta.find().sort( {“reviews.total”: 1} )’ 3 ‘db.am_meta.aggregate([{$group : {“group:”$item”}}])’ 14. Запросы в Postgresql к БД “Amazon”: 1. ‘select doc from am_meta_vert where doc->'ASIN' in (select doc->'ASIN' from am_rev_vert where doc @> '{"data": "@dat "}');’ 2. ‘select doc from am_meta_vert order by doc->'reviews'->'total' desc;’ 3. ‘select doc->'group' from am_meta_vert group by doc->'group';’ 15. Запросы в Cassandra к БД “Amazon”: 3. ‘select Amazon.group_and_count(group) from Amazon.am_meta_vert;’ (aggregate - Amazon.group_and_count() – определяется заранее); 35 2. Образцы наборов данных Экземпляр документа из набора ‘amazon-meta’ { "Id": 1, "ASIN": "0827229534", "title": "Patterns of Preaching: A Sermon Sampler", "group": "Book", "salesrank": 396585, "similar": { "total": 5, "asin": [ "0804215715", "156101074X", "0687023955", "0687074231", "082721619X" ] }, "categories": { "total": 2, "categories": [ " |Books[283155]|Subjects[1000]|Religion & Spirituality[22]|Christianity[12290]|Clergy[12360]|Preaching[12368]", " |Books[283155]|Subjects[1000]|Religion & Spirituality[22]|Christianity[12290]|Clergy[12360]|Sermons[12370]" ] }, "reviews": { "total": 2, "downloaded": 2, "avg_rating": 5.0, "reviews": [ { "data": "2000-7-28", "customer": "A2JW67OY8U6HHK", "rating": 5.0, "votes": 10, "helpful": 9.0 }, { "data": "2003-12-14", "customer": "A2VE83MZF98ITY", "rating": 5.0, "votes": 6, "helpful": 5.0 } ] } } Рис. 1 36 Экземпляр документа из набора ‘All_Viruses.gene_info’ { "#tax_id": 10390, "GeneID": 4811502, "Symbol": "MDV041", "LocusTag": "MD5V_041", "Synonyms": "GaHV2Md5_gp041", "dbXrefs": "-", "chromosome": "-", "map_location": "-", "description": "similar to HSV1 UL28 DNA packaging protein", "type_of_gene": "protein-coding", "Symbol_from_nomenclature_authority": "-", "Full_name_from_nomenclature_authority": "-", "Nomenclature_status": "-", "Other_designations": "similar to HSV1 UL28 DNA packaging protein|DNA packaging terminase subunit 2", "Modification_date": 20160806, "Feature_type": "-" } Рис. 2 |