Анализ производительности РСУБД PostgreSQL и NoSQL

САНКТ-ПЕТЕРБУРГСКИЙ
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Математико-Механический факультет
Кафедра информационно-аналитических систем
Суманеев Артем Павлович
Анализ производительности РСУБД
PostgreSQL и NoSQL-хранилищ Redis и
Apache Cassandra
Êóðñîâàÿ ðàáîòà
ñòóäåíòà 1 êóðñà ìàãèñòðàòóðû
Научный руководитель:
д. ф.-м. н., профессор Новиков Б. А
Заведующий кафедрой:
д.ф. - м.н., профессор Новиков Б. А
Санкт-Петербург
2015 г.
1
Содержание
ВВЕДЕНИЕ
2
ГЛАВА 1. Введение в предметную область
4
1.1
1.2
Реляционные базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.1
PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
NoSQL базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.1
7
Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Apache Cassandra
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4
Yahoo Cloud System Benchmark . . . . . . . . . . . . . . . . . . . . . . . .
8
1.4.1
8
Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ГЛАВА 2. Тестирование
10
2.1
Загрузка данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Workload A - тяжелое обновление . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
Workload B - тяжелое чтение . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4
Workload E - короткие наборы записей . . . . . . . . . . . . . . . . . . . .
13
Заключение
14
Список литературы
15
2
ВВЕДЕНИЕ
В различных областях деятельности накоплено огромное количество данных, что ведет
к усилению требований к их обработке и хранению, в частности к производительности
систем управления данными (СУБД). Данная проблема особенно актуальна для
данных, требующих глубокого анализа. В связи с этой ситуацией появляются
новые подходы к построению таких систем, которые должны преодолеть недостатки
существующих.
На сегодняшний день существуют два наиболее распространенных типа систем
управления данными: реляционные и NoSQL СУБД, различные во многих аспектах
работы. Такие кардинальные отличия в вопросах, как надежность, гибкость,
согласованность данных и масштабируемость, требуют тщательного анализа различных
моментов функционирования систем, в особенности производительности. Цель данной
курсовой работы - провести сравнение производительности СУБД этих двух типов.
В рамках работы было проведено сравнение производительности трех систем
управления базами данных: реляционной СУБД (РСУБД) PostgreSQL и хранилищ
Redis и Apache Cassandra типа «ключ-значение». В качестве тестирующей системы
был выбран Yahoo Cloud System Benchmark фреймворк, позволяющий сравнить
производительность множества аспектов работы систем.
Результаты тестирования показали следующее:
1. При тестировании чтения данных у всех систем наблюдается ухудшение
производительности при значительном увеличении объема данных (с 1 MB до
0.1 GB).
2. В
остальных
случаях
системы
демонстрируют
постепенное
ухудшение
производительности при увеличении размера данных.
3. PostgreSQL:
(a) Загрузка данных показывает лучшую производительность перед чтением.
(b) Производительность выполнения операций чтения и одновременно с записью
и только операций чтения одинакова. Однако, наблюдается сильное
ухудшение производительности на чтении наборов записей при увеличении
размеров данных (на два порядка).
(c) Производительность PostgreSQL значительно лучше Apache Cassandra на
небольших размерах данных. При работе с большим числом записей
производительности обеих систем практически совпадают.
4. Redis:
3
(a) Производительность выше, чем у других систем, за счет расположения
записей в оперативной памяти.
(b) Система не может работать с размерами данных, превышающие размер
оперативной памяти.
(c) Имеет слабую моделью конкурентного выполнения запросов.
5. Cassandra:
(a) В системе отдано предпочтение операции вставки.
(b) Вставки
при
больших
данных
в
системе
показывают
лучшую
производительность, чем в PostgreSQL.
Итогом может служить то, что РСУБД система PostgreSQL работает не хуже Apache
Cassandra при использовании описанной далее конфигурации.
4
ГЛАВА 1. Введение в предметную область
Проблемы, связанные с хранением и обработкой информации всегда имели место в
связи с потребностями индустрии, бизнеса и научных исследований. Базы данных
были специально разработаны для организованного доступа к данным. Они начались
с навигационных баз данных, основанные на связных списках, далее была разработана
реляционная модель данных, а вместе с ней реляционные БД, после - объектноориентированные, и, наконец, NoSQL подход.
В настоящее время двумя наиболее используемыми типами баз данных являются
реляционные и NoSQL БД. Не смотря на то, что базы данных NoSQL являются
относительно свежими, по сравнению с другими, они стали достаточно популярным
благодаря своим способностям быстро обрабатывать несвязные и неструктурированные
данные. Широкое разнообразие баз данных создает трудности для разработчиков в
выборе подходящей системы. Сравнение этих двух типов баз данных необходимо - это
позволит выявить их сильные и слабые стороны, а также применимость в решении той
или иной задачи. Базы данных играю важную роль в приложениях, и неправильный
выбор может иметь катастрофические последствия в дальнейшем, так как сложно
сменить БД в процессе работы системы, тем более на другой тип.
Есть множество работ по сравнению как NoSQL баз данных между собой, так и с
реляционными СУБД. В [6] рассматриваются способы поддержки таких характерных
особенностей нескольких РСУБД и NoSQL, как управление параллелизмом, хранение
данных, репликации и транзакционные механизмы. Авторы [13] показывают несколько
классификаций систем NoSQL, сравнивают аспекты реализации и производительности
нескольких NoSQL баз данных и СУБД MySQL. [10] рассматривает несколько NoSQL
баз данных и общие для все NoSQL достоинства и недостатки по сравнению с РСУБД.
В [1] показываются результаты тестирования производительности различных NoSQL
баз данных.
В рамках курсовой работы рассматривается сравнение производительности
нескольких баз данных двух типов. Основным результатом работы является анализ
производительности каждой из них в различных аспектах функционирования.
Работа организована следующим образом. В Главе 1 дается общее представление
предметной области, краткий обзор концепции реляционных СУБД и NoSQL баз
данных, в частности PostgreSQL, Redis и Apache Cassandra. Далее представлен
способ тестирования и Yahoo Cloud System Benchmark. В Главе 2 рассматриваются
сравнение результатов тестирования исследуемых СУБД. В Заключении подводится
итог проведенной работы и предлагаются направления дальнейшего анализа.
5
1.1
Реляционные базы данных
Базы данных определяются как коллекция хранимых данных, используемая
приложениями [7, стр. 11]. Хотя, используя термин «база данных», мы, зачастую,
подразумеваем систему целиком, сам термин определяет только коллекции и данные.
Система, управляющая данными, транзакциями и другими использования БД,
называется Система Управления Данными (СУБД). Далее последует описание двух
типов баз данных, сравниваемых в данной работе.
Реляционные базы данных основаны на реляционной модели и теории множеств,
в которой все данные представляются как n-арное отношение, которое, в свою
очередь, представляется как подмножество n-арного декартова произведения n
множеств. Отношение (таблица) состоит из множества кортежей (записей), атрибуты
которых соответствуют столбцам. Такая модель данных очень точная и хорошо
структурирована.
Реляционная база данных гарантирует высокую надежность транзакций благодаря
полной поддержке четырех свойств ACID:
∙ Атомарность: если какая-либо часть транзакции не выполняется, то не
выполняется транзакция целиком.
∙ Согласованность: если база данных находилась в согласованном состоянии до
выполнения транзакции, то после выполнения она также будет находиться в
согласованном состоянии.
∙ Изолированность: множество транзакций, выполняемых одновременно, не влияют
на ход работы друг друга. Иными словами, параллельные транзакции должны
быть сериализуемы.
∙ Долговечность: изменения, совершенные зафиксированной транзакцией, будут
оставаться в системе не смотря на какие-либо сбои.
Из множества реляционных систем управления данными, в работе предлагается
анализ производительности РСУБД PostgreSQL.
1.1.1
PostgreSQL
PostgreSQL [11] является объектно-реляционной системой управления базами данных.
Система разрабатывается более 15 лет и имеет проверенную архитектуру, которая
заработала хорошую репутацию надежности, целостности данных и точности. Также
она целиком поддерживает ACID и стандарт ANSI-SQL:2008.
PostgreSQL содержит в себе нетривиальные возможности, такие как управление
конкурентным доступом с помощью многоверсионности (MVCC), возврат к состоянию
6
в определенный момент времени (Point-in-time recoverty), пространство таблиц,
асинхронные репликации, внутренние транзакции (точки сохранения), резервное
копирование во время исполнения, сложные планировщик и оптимизатор запросов
и другие. Все эти функции позволяют PostgreSQL быть хорошей альтернативой
NoSQL-системам в плане масштабируемости, сохраняя возможность сложных глубоких
аналитических запросов посредством SQL.
1.2
NoSQL базы данных
В последние годы было разработано больше число новых систем [4, 9, 2],
предоставляющих хорошее горизонтальное масштабирование для простых операций
чтения/записи над базами данных, распределенных на множестве серверов. В отличии
от них, традиционные базы данных дают меньше возможности к масштабированию.
Множество новых систем определяются термином «NoSQL»-хранилища данных.
Термин «NoSQL», что расшифровывается как «Not Only SQL» или «Not Relational», до
конца не определен. Обычно такие системы удовлетворяют следующим признакам:
1. Наличие средств распределения нагрузки на множество серверов.
2. Возможность распределение данных на множество серверов.
3. Простой протокол вызова операций (в сравнении с SQL).
4. Более слабая модель параллелизма, чем ACID-транзакции.
5. Эффективное использование распределенных индексов и оперативной памяти для
хранения данных.
6. Отсутствие фиксированной схемы данных.
NoSQL-системы обычно не удовлетворяют свойствам ACID-транзакций: допускается
согласованность в конечном счете. Предлагается модель «BASE» (Basically Available,
Soft
state,
Eventually consistent, согласованность в конечном счете) в противоположность ACID.
Идея состоит в том, что, отказавшись от ограничений ACID, можно добиться гораздо
лучшей производительности и масштабируемости. Большинство систем разнятся в
степени отказа от ACID.
Сторонники NoSQL часто ссылаются на CAP-теорему, которая утверждает, что
система может удовлетворять только двум из трех следующих свойств:
∙ Согласованность - данные всегда одинаковы на всех репликах,
∙ Доступность - данные всегда доступны пользователю,
7
∙ Устойчивость к разделению - система базы данных продолжает корректную
работу не смотря на отказ сети или узлов.
В NoSQL системах обычно опускается согласованность, но допущения могут быть
сложнее.
Зачастую
модели
данных
в
NoSQL-системах
разбиваются
на
следующие
категории [8]:
∙ Хранилища типа «ключ-значение» (Key-value stores ): хранят значения и
идентификатор для поиска, основанный на заданном ключе.
∙
Документно-ориентированные
хранилища (Document
stores ):
система хранит
данные в форме документов, которые индексируются.
∙ Хранилища с расширяемой записью (Extensible records stores ): записи в таких
хранилищах могут быть распределены вертикально и горизонтально по узлам.
Данная работа сосредотачивается на NoSQL-системах типа «ключ-значение» , в
частности для сравнения была выбраны Redis и Apache Cassandra.
1.2.1
Redis
Redis [12] является системой типа «ключ-значение». Такие системы, подобно хештаблицам или ассоциативным массивам, используют простую структуру данных,
содержащую пару ключ/значение. Временная сложность доступа к такой структуре
- O(1). Ключ является уникальным и простым для поиска.
Redis - хранилище структур данных в оперативной памяти с открытым исходным
кодом. Хранилище поддерживает такие структуры данных как строки, хеш-таблицы,
списки, упорядоченные и неупорядоченные множества, и набор разнообразных
запросов. В Redis встроены механизмы репликаций и транзакций. Для достижения
выдающейся производительности Redis работает с базой данных в оперативной
памяти, при этом предоставляется возможность сохранять ее на диск через некоторые
промежутки времени или записывать каждую команду в журнал.
1.3
Apache Cassandra
Модель данных и функциональность Apache Cassandra [3] имеет сходство с другими
масштабируемыми хранилищами. Обновления и группировки столбцов кэшируются
в оперативной памяти, после чего сбрасываются на диск. Присутствует поддержка
распределения данных и механизмы репликации, автоматические обнаружения отказов
узлов и восстановление. Однако модель параллелизма в Cassandra слабее, чем в других
8
системах, в следствии отсутствия механизмов блокировки и асинхронного обновление
реплик.
Для обработки данных Cassandra поддерживает CQL - Cassandra Query Language,
основанный на SQL.
Важным фактором при сравнении производительности нескольких систем является
выбор тестирующей системы. В данной работе в качестве такой системы был выбран
Yahoo Cloud System Benchmark.
1.4
Yahoo Cloud System Benchmark
Yahoo Cloud System Benchmark (YCSB) [5] - фреймворк для тестирования
производительности, созданный для сравнения системы PNUTS от Yahoo с другими
системами. Основной целью YCSB является выявления сильных и слабых сторон
СУБД. Для тестирования производительности системы был выбран именно этот
инструмент в связи с прозрачностью тестирования (благодаря открытым исходным
кодам) и возможностью расширения и переработки под собственные нужды.
Система тестирования содержит набор готовых загрузок (workloads), покрывающих
основные аспекты функционирования (чтение, запись, сканирование) и поддерживает
созданные пользователем загрузки. Важной особенностью фреймворка является
расширяемость: генератор загрузок облегчает работу по созданию новых типов
загрузок, дополнительно, пользователь может достаточно легко добавить новую
систему баз данных к фреймворку.
1.4.1
Workloads
В YCSB загрузкой является набор операций (их общее число и процентное отношение),
размер обрабатываемых данных, запрос на распределенность и т.д., что может быть
использовано для симулирования определенных ситуаций и поведения системы.
Предлагаемые разработчиками загрузки используют одну таблицу с N полями,
среди которых есть ключевое. Значения каждого поля - случайная строка длины L.
Количество полей и их размер можно настраивать.
Операции над хранилищем выбираются случайно из следующих:
∙ Вставка: добавление новой записи.
∙ Обновление: обновление значения записи.
∙ Чтение: чтение случайной записи или всех.
∙ Сканирование: упорядоченное чтение случайного числа записей, начиная с
некоторого ключевого значения.
9
Общее число операций и их процентное соотношение - настраиваемые параметры,
от которых будет зависеть направление тестирования.
Случайность выбора записи задается одним из распределений: равномерное,
распределение Парето (с предпочтением некоторых записей перед большинством
остальных), позднее (подобно Парето, но наиболее вероятными записями становятся
более поздние) и мультномиальное.
Используемые в работе загрузки описываются следующим образом:
∙ A: загрузка по обновлениям. Операции распределяются поровну между чтением
и обновлением. Примером может служить загрузка обновлениями, основанными
на предыдущих действиях.
∙ B: тяжелое чтение. 95% чтений и 5% обновлений. Пример - растравление меток
фотографиям. Добавление тега - обновление, но большинство операций является
чтением тегов.
∙ C: только чтение.
∙ D: чтение поздних записей. 95% чтений и 5% вставок. Пример - пользователи
хотят читать новейшие данные.
∙ E: короткие наборы. 95% сканирований и 5% вставок.
Тестирование производится на простой схеме данных, содержащей одну таблицу
с несколькими строковыми столбцами, число которых, а также их размер и число
записей, можно задать. Однако, расширяемость архитектуры позволяет усложнить эту
схему для проведения более сложных операций, чем простое чтение или обновление
записей из одной таблицы.
В данной курсовой работе было проведено тестирование систем с помощью YCSBфреймворка и вышеупомянутыми загрузками. Результаты тестирования и их анализ
приведены в следующей главе.
10
ГЛАВА 2. Тестирование
Тестирование проводилось на следующей конфигурации: одна машина (4х ядерный
3.4GHz Intel Core i5 процессор, 4GB RAM, диск размера 150 GB) для запуска одной из
систем. В качестве тестирующей системы использовалась YCSB на отдельной машине,
использовались стандартные загрузки для баз данных, описанные выше. Каждая
система не подлежала дополнительным настройкам конфигурации, кроме увеличения
времени ожидания ответа от Cassandra.
В каждом из этапов тестирования использовалась одна таблица или ее аналог
в NoSQL-системе с десятью столбцами, каждый размера 100 байт, по умолчанию
используемые тестирующей системой, с 103 (≈ 1𝑀 𝐵), 105 (≈ 0.1𝐺𝐵) и 107 (≈
10𝐺𝐵) записями. Общее число операций над таблицей - 1000, того или иного типа.
Число операций конкретного типа зависело от процентного соотношения. Выполнялись
следующие операции:
∙ Вставка.
∙ Обновление.
∙ Чтение.
∙ Сканирование.
Для каждой загрузки были измерены следующие величины: число операций
в секунду (throughput), как отношение общего числа операций ко времени их
выполнения, и средняя задержка выполнения операции. На графиках приведена только
пропускная способность, так как ее тенденция и изменение задержки несут одинаковую
информацию
Последующие параграфы представляют результаты проведенных тестов, отдельно
вынесено испытание загрузки данных. По результатам тестирования и особенной
каждой из загрузок предложен некоторой вывод о особенности производительности
систем:
1. Для загрузок на чтение наблюдается улучшение производительности при переходе
от 1000 до 100000 записей, что обусловлено, видимо, прогревом кэша, и сильное
ухудшение производительности при дальнейшем увеличении размера.
2. В других случаях - постепенное ухудшение производительности при увеличении
объема данных.
3. PostgreSQL:
(a) Загрузка данных демонстрирует лучшую производительность перед чтением.
PostgreSQL ориентирована на вставки.
11
(b) Производительность одновременных чтений и записей отдельных элементов
и только чтение единичных полей одинакова. Однако, наблюдается сильное
ухудшение производительности на чтении наборов записей (Workload E) при
увеличении размеров данных (на два порядка).
(c) Производительность PostgreSQL значительно лучше Apache Cassandra на
небольших размерах данных (пропускная способность выше на два порядка).
При работе 10000000 записей производительности обеих систем практически
совпадают.
4. Redis:
(a) Производительность выше, чем у других систем, за счет расположения
записей в оперативной памяти.
(b) Система не может работать с размерами данных, превышающие размер
оперативной памяти. Проверить случай, когда задействован файл подкачки
не удалось.
(c) При чтении наборов записей и одновременных вставках (загрузка E)
наблюдается худшая производительность системы, чем у PostgreSQL,
что может быть обусловлено слабой моделью конкурентного выполнения
запросов.
5. Cassandra:
(a) В системе отдано предпочтение операции вставки.
(b) Вставки
при
больших
данных
в
системе
показывают
лучшую
производительность, чем в PostgreSQL.
2.1
Загрузка данных
Перед каждым этапом тестирования производилась загрузка данных в хранилище,
одинаковая для каждого. 100% операций являются вставками. Здесь можно выявить,
какую производительность для вставок предоставляет система. На Рис. 1 показаны
результаты загрузки данных в систему. На оси X отмечено число записей в базе данных,
на оси Y - пропускная способность системы, количество операций в секунду.
Из рисунка видно, что система Redis показывает лучшую производительность перед
двумя другими. PostgreSQL работат лучше при небольших объемах данных, а Cassandra
- при большом числе записей.
12
𝑝𝑜𝑠𝑡𝑔𝑟𝑒𝑠𝑞𝑙
𝑟𝑒𝑑𝑖𝑠
𝑐𝑎𝑠𝑠𝑎𝑛𝑑𝑟𝑎
Оп./сек.
2,000
1,500
1,000
500
0
103
104
105
106
Число записей
107
Рис. 1: Результаты загрузки данных в систему
2.2
Workload A - тяжелое обновление
В данной загрузке операции распределяются следующим образом: 50% чтений и 50%
обновлений. Результаты тестирования приведены на Рис. 2.
4,000
𝑝𝑜𝑠𝑡𝑔𝑟𝑒𝑠𝑞𝑙
𝑟𝑒𝑑𝑖𝑠
𝑐𝑎𝑠𝑠𝑎𝑛𝑑𝑟𝑎
Оп./сек.
3,000
2,000
1,000
0
103
104
105
106
Число записей
107
Рис. 2: Результаты Workload A
Из результатов загрузки A можно сделать вывод, что PostgreSQL читает данные
лучше Cassandra при малом числе записей, и производительность двух систем
одинакова на 10000000 записях.
2.3
Workload B - тяжелое чтение
Здесь использовалось 95% чтений и 5% обновлений. Из Рисунка 3 видно, что результаты
этой загрузки совпадают с результатами загрузки A.
Результаты загрузок C и D также аналогичны результатам A.
13
4,000
𝑝𝑜𝑠𝑡𝑔𝑟𝑒𝑠𝑞𝑙
𝑟𝑒𝑑𝑖𝑠
𝑐𝑎𝑠𝑠𝑎𝑛𝑑𝑟𝑎
Оп./сек.
3,000
2,000
1,000
0
103
104
105
106
Число записей
107
Рис. 3: Результаты Workload B
2.4
Workload E - короткие наборы записей
В данной загрузке операции распределяются следующим образом: 95% сканирований
и 5% вставок. Результаты тестирования приведены на Рис. 2.
800
𝑝𝑜𝑠𝑡𝑔𝑟𝑒𝑠𝑞𝑙
𝑟𝑒𝑑𝑖𝑠
𝑐𝑎𝑠𝑠𝑎𝑛𝑑𝑟𝑎
Оп./сек.
600
400
200
0
103
104
105
106
Число записей
107
Рис. 4: Результаты Workload E
В данной загрузке наблюдается сильное ухудшение производительности системы
Redis. PostgreSQL вновь демонстрирует лучшую производительность перед Cassandra
на небольшом числе записей, и схожую производительность на большом объеме данных.
14
Заключение
В данной курсовой работе был произведен краткий анализ реляционных систем
управления данными и NoSQL-систем, были приведены их основные отличия. Основной
целью работы было сравнение производительности РСУБД и NoSQL-систем.
В работе представлено обзорное сравнение двух типов СУБД. Основное отличие
NoSQL-систем от реляционных состоит в том, что они не удовлетворяют требованиям
ACID, вместо которых предложена модель BASE.
В ходе работы было проведено тестирование трех систем управления данными:
РСУБД PosgreSQL, NoSQL Apache Cassandra и Redis. Каждая из них была работала на
единственной машине. Была использована простая схема данных, состоящая из одной
таблицы с десятью столбцами, количество записей в таблице для каждого из этапов
тестирования было 103 , 105 и 107 .
Результаты
тестирования
показали,
что
при
рассмотренной
конфигурации
PostgreSQL работает лучше Apache Cassandra при небольших объемах данных, и
производительности этих систем совпадают при большом числе записей. Система Redis
показывает лучшую производительность, чем у двух других, за счет расположения
данных в памяти, однако не может работать с данными, размер которых превышает
объем оперативной памяти. При этом у всех систем наблюдается ухудшение
производительности при увеличении числа записей.
В качестве дальнейших направлений сравнения производительности можно
рассматривать следующие:
∙ Данное тестирование производилось для систем, запущенных на одной машине.
Для проверки масштабируемости нужно провести тестирование на кластере.
Дополнительно, такой случай позволит увеличить размер данных.
∙ Использованная в тестировании схема данных проста. Использование более
сложной схемы позволит продемонстрировать случай, когда обработка данных
в NoSQL-системах, не предоставляющих сложных аналитических запросов,
делегируется клиентскому приложению, в то время как реляционные системы
поддерживают такие запросы.
15
Список литературы
[1] Abramova, V. Which NoSQL Database? A Performance Overview / Veronika Abramova,
Jorge Bernardino, Pedro Furtado. — 2014.
[2] Amazon DynamoDB. [Электронный ресурс] - Режим доступа: свободный. —
https://aws.amazon.com/documentation/dynamodb/
. — (дата обращения 1.12.2015).
[3] Apache Cassandra. [Электронный ресурс] - Режим доступа: свободный. —
. — (дата обращения 1.12.2015).
http://cassandra.apache.org/
[4] Apache
HBase.
[Электронный ресурс] - Режим доступа: свободный. —
https://hbase.apache.org/
.—
(дата обращения 1.12.2015).
[5] Benchmarking cloud serving systems with YCSB / Brian F Cooper, Adam Silberstein,
Erwin Tam et al. // Proceedings of the 1st ACM symposium on Cloud computing /
ACM. — 2010. — P. 143–154.
[6] Cattell, R. Scalable SQL and NoSQL data stores / Rick Cattell // ACM SIGMOD
Record. — 2011. — Vol. 39, no. 4. — P. 12–27.
[7] Data, C. An introduction to database systems, 8/E / CJ Data. — Addison-Wesley publ.,
2004.
[8] He, C. Survey on NoSQL Database Technology / Changlin He // Journal of Applied
Science and Engineering Innovation Vol. — 2015. — Vol. 2, no. 2.
[9] MongoDB.
[Электронный
https://www.mongodb.org/
ресурс]
-
Режим
доступа:
свободный. —
. — (дата обращения 1.12.2015).
[10] Nayak, A. Type of NOSQL Databases and its Comparison with Relational Databases /
Ameya Nayak, Anil Poriya, Dikshay Poojary // International Journal of Applied
Information Systems. — 2013. — Vol. 5, no. 4. — P. 16–19.
[11] PostgreSQL.
[Электронный
http://www.postgresql.org/
ресурс]
-
Режим
доступа:
свободный. —
. — (дата обращения 1.12.2015).
[12] Redis. [Электронный ресурс] - Режим доступа: свободный. — http://redis.io/. — (дата
обращения 1.12.2015).
[13] Tudorica, B. G. A comparison between several NoSQL databases with comments and
notes / Bogdan George Tudorica, Cristian Bucur // Roedunet International Conference
(RoEduNet), 2011 10th / IEEE. — 2011. — P. 1–5.