В настоящее время базы данных считаются жизненно важной частью организаций и используются во всем мире. Реляционные базы данных позволяют хранить, извлекать данные и манипулировать ими с помощью стандартного языка SQL. До сих пор реляционные базы данных были оптимальным выбором предприятия.
Однако с постоянным ростом объема хранимых и анализируемых данных реляционные базы данных сталкиваются с целым рядом ограничений, например, с ограничениями масштабируемости и хранения, потерей эффективности запросов из-за больших объемов данных, а хранение и управление большими базами данных становится сложной задачей.
Для преодоления этих ограничений была разработана новая модель базы данных с набором новых возможностей, известных как базы данных NoSQL. Нереляционные базы данных возникли как революционная технология и могут использоваться как единственные или как дополнение к реляционной базе данных. NoSQL повышает производительность реляционных баз данных за счет набора новых характеристик и преимуществ.
По сравнению с реляционными базами данных NoSQL более гибкие и масштабируемые по горизонтали.
Они могут использовать преимущества новых кластеров и узлов прозрачно, не требуя дополнительного управления базой данных или ручного распространения информации. Поскольку администрирование базы данных может быть сложной задачей с такими объемами данных, предполагается, что базы данных NoSQL будут автоматически управлять и распределять данные, восстанавливаться после сбоев и автоматически восстанавливать всю систему.
Когда начала появляться технология NoSQL, базы данных NoSQL были известны и характеризовались отсутствием согласованности хранящихся в них данных. Для компаний и систем, для которых важна сильная согласованность, отсутствие согласованности может быть большим ограничением.
С ростом популярности несвязанных баз данных, такие возможности и системные характеристики начали развиваться.
В настоящее время существует более 150 баз данных NoSQL с различными возможностями и оптимизациями, а ряд баз данных NoSQL предоставляют все новые возможности и преимущества при сохранении согласованности или даже согласованности данных, в зависимости от потребностей системы.
Например, MongoDB1, DynamoDB2 и SimpleDBB3 поддерживают сильную и конечную согласованность, а CouchDB4 обеспечивает функцию конечной согласованности. Кроме того, для повышения скорости выполнения запросов в нереляционных базах данных стали использоваться энергонезависимая память.
Поскольку доступ к данным ввода/вывода медленнее, отображение базы данных или ее частей в энергозависимую память повышает производительность и сокращает общее время выполнения запросов.
БАЗЫ ДАННЫХ NOSQL
Базы данных NoSQL основаны на принципе BASE (практически доступного, мягкого состояния и, в конечном счете, согласованного), который характеризуется высокой доступностью данных, принося в жертву их согласованности . С другой стороны, реляционные базы данных представлены по принципу ACID, где все совершенные транзакции корректны и не повреждают базу данных, а данные являются согласованными.
Оба принципа вытекают из теоремы CAP - согласованность, доступность и толерантность разделов. Согласно этой теореме, при работе с распределенными системами могут быть достигнуты только две из трех гарантий, поэтому необходимо выбрать наиболее важную.
Когда согласованность данных имеет решающее значение, следует использовать реляционные базы данных. При сравнении этих двух моделей можно считать, что BASE является более гибкой, чем ACID.
Следовательно, базы данных Key-value Store лучше подходят для управления запасами и продукцией, а также для анализа данных в режиме реального времени, благодаря тому, что эти базы данных имеют хорошую скорость извлечения - извлечение значений с учетом конкретных ключей - когда наибольший объем данных может быть нанесен на карту памяти.
Базы данных хранилища документов являются хорошим выбором при работе с большими объемами документов, которые могут храниться в структурированных файлах, таких как текстовые документы, электронные письма или XML и CMS и CRM системы.
Семейства баз данных должны использоваться, когда количество операций записи превышает количество операций чтения, и это происходит, например, при системном журнале. Наконец, графические базы данных более подходят для работы с взаимосвязанными данными, например, для анализа социальных связей между группой лиц, дорожных карт и транспортных систем.
Семейства баз данных должны использоваться, когда количество операций записи превышает количество операций чтения, и это происходит, например, при системном журнале. Наконец, графические базы данных более подходят для работы с взаимосвязанными данными, например, для анализа социальных связей между группой лиц, дорожных карт и транспортных систем.
ЭКСПЕРИМЕНТАЛЬНАЯ УСТАНОВКА
Для экспериментального анализа использовались тесты YCSB - Yahoo! Cloud Serving Benchmark, который позволяет оценить и сравнить производительность баз данных NoSQL. Этот эталон состоит из двух компонентов: генератора данных и набора тестов производительности, состоящих, в упрощенном виде, из операций чтения и вставки.
Каждый из тестовых сценариев называется рабочим объемом и определяется набором функций, включающих процент операций чтения и обновления, общее количество операций и количество используемых записей. Эталонный пакет содержит набор рабочих нагрузок по умолчанию, которые могут быть выполнены и определены процентным соотношением чтения, обновления, сканирования и вставки.
По умолчанию это рабочие нагрузки: A (50% чтение и 50% обновление), B (95% чтение и 5% обновление), C (100% чтение), D (95% чтение и 5% вставка), E (95% сканирование и 5% вставка) и F (50% чтение и 50% чтение готовой записи). Нашей целью является сравнение скорости выполнения операций получения и сдачи, которые являются наиболее часто используемыми операциями.
Поэтому мы выполнили только рабочие нагрузки A, C и определенную нами дополнительную рабочую нагрузку H, которая составляет 100% обновления.
Для экспериментального анализа использовались тесты YCSB - Yahoo! Cloud Serving Benchmark, который позволяет оценить и сравнить производительность баз данных NoSQL. Этот эталон состоит из двух компонентов: генератора данных и набора тестов производительности, состоящих, в упрощенном виде, из операций чтения и вставки.
Каждый из тестовых сценариев называется рабочим объемом и определяется набором функций, включающих процент операций чтения и обновления, общее количество операций и количество используемых записей.
Эталонный пакет содержит набор рабочих нагрузок по умолчанию, которые могут быть выполнены и определены процентным соотношением чтения, обновления, сканирования и вставки.
По умолчанию это рабочие нагрузки: A (50% чтение и 50% обновление), B (95% чтение и 5% обновление), C (100% чтение), D (95% чтение и 5% вставка), E (95% сканирование и 5% вставка) и F (50% чтение и 50% чтение готовой записи). Нашей целью является сравнение скорости выполнения операций получения и сдачи, которые являются наиболее часто используемыми операциями.
Поэтому мы выполнили только рабочие нагрузки A, C и определенную нами дополнительную рабочую нагрузку H, которая составляет 100% обновления.
