нир. Формулировка задачи 3 Предметная область 3
 Скачать 0.71 Mb.
|
СодержаниеВведение 2 Формулировка задачи 3 Предметная область 3 Предпосылки появления NoSQL 3 О выборе SQL-баз данных 4 О выборе NoSQL баз данных 4 Классификация типов NoSQL СУБД 5 База данных типа «ключ-значение» 5 Документные базы данных 6 Семейство столбцов 6 Графовые базы данных 7 Выводы 8 Список используемых источников 10 ВведениеСовременный IT-специалист должен обладать навыками эффективного применения СУБД при проектировании и реализации современных распределенных информационных систем. Во многих источниках определение NoSQL баз данных подается достаточно неоднозначно, что может сформировать неверное или неполное представление о значении этого термина. Сама его суть сбивает с толку. Понятие NoSQL связывает между собой программные решения, зачастую совершенно не аналогичные. В данной работе будет проведено практическое исследование NoSQL СУБД, которые были спроектированы как альтернатива классическим реляционным СУБД, предоставляющих определенные преимущества, например, такие как: горизонтальная масштабируемость, высокая доступность и т.п. Логически понятие NoSQL может включать в себя и дореляционные БД, которые проектировались без оглядки на опыт использования SQL систем и не несут в себе цели создания современных NoSQL решений. Эта цель - отступление от реляционной модели хранения данных в попытке устранить некоторые известные недостатки SQL или достичь более высокой производительности в конкретных задачах. Формулировка задачиВ рамках научно-исследовательской работы (далее НИР) нужно изучить особенности проектирования нереляционных баз данных. В данной работе предоставлен ответ на вопрос: «Почему NoSQL?». Основными целями НИР являются: определение преимуществ и недостатков NoSQL; изучение различных видов согласованности в нереляционных БД; получение представления об основах и особенностях масштабируемости в нереляционных БД; Основными задачами НИР являются: изучить понятие «нереляционные базы данных»; определить различия между SQL и NoSQL сформировать представление о согласованности и масштабируемости в нереляционных БД; изучить особенности согласованности и масштабируемости в нереляционных БД; Предметная областьNoSQL—термин, обозначающий ряд подходов, направленных на реализацию систем управления базами данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемости и доступности за счёт атомарности и согласованности данных [2]. Предпосылки появления NoSQLКлючевым фактором, заставившим мировое IT-сообщество задуматься над новыми стратегиями хранения и доступа к информации, стал планомерный рост объемов данных в сети Интернет. В связи с этим был создан термин Big Data, включающий в себя некую стратегию, позволяющую эффективно работать с огромными постоянно растущими массивами данных. И на фоне этой концепции четко вырисовывалась необходимость в модели базы данных, которая будет больше нацелена на скорость доступа и масштабируемость. Нужно было какое-то более простое решение, чем существующие реляционные БД, при этом не уступающее им в ряде конкретных задач. В первую очередь, это задачи построения облачных хранилищ, где конечному пользователю в первую очередь важна скорость доступа и возможный объем хранимой информации. О выборе SQL-баз данныхНе существует баз данных, которые подойдут абсолютно всем. Именно поэтому многие компании используют и реляционные, и нереляционные БД для решения различных задач. Хотя NoSQL-базы стали популярными благодаря быстродействию и хорошей масштабируемости, в некоторых ситуациях предпочтительными могут оказаться структурированные SQL-хранилища. Вот две причины, которые могут послужить поводом для выбора SQL-базы: Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность). Это позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных. Достигается подобное путём жёсткого определения того, как именно транзакции взаимодействуют с базой данных. Это отличается от подхода, используемого в NoSQL-базах, которые ставят во главу угла гибкость и скорость, а не 100% целостность данных. Данные, с которыми работает пользователь, структурированы, при этом структура не подвержена частым изменениям. Если организация не находится в стадии экспоненциального роста, вероятно, не найдётся убедительных причин использовать БД, которая позволяет достаточно вольно обращаться с типами данных и нацелена на обработку огромных объёмов информации. О выборе NoSQL баз данныхЕсли есть подозрения, что база данных может стать узким местом некоего проекта, основанного на работе с большими объёмами информации, стоит посмотреть в сторону NoSQL-баз, которые позволяют то, чего не умеют реляционные БД. Вот возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase: Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных. Использование облачных вычислений и хранилищ. Облачные хранилища — отличное решение, но они требуют, чтобы данные можно было легко распределить между несколькими серверами для обеспечения масштабирования. Использование, для тестирования и разработки, локального оборудования, а затем перенос системы в облако, где она и работает — это именно то, для чего созданы NoSQL базы данных. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз. [3] Классификация типов NoSQL СУБДБаза данных типа «ключ-значение»Такие базы данных как правило используют хеш-таблицу, в которой находится уникальный ключ и указатель на конкретный объект данных. Существует понятие блока (bucket) — логической группы ключей, которые не группируют данные физически. В разных блоках могут быть идентичные ключи. Ключ может быть синтетическим или автоматически сгенерированным, а значение может быть представлено строкой, JSON и т.д. Подобные хранилища используются в тех случаях, когда конкретное содержимое отдельной ячейки не интересно оператору базы данных — иначе говоря, полностью отсутствуют связи между отдельными ячейками хранилища. Базы данных типа “ключ-значение” не очень хорошо подходят в качестве полной замены реляционных БД, но нашли своё применение в качестве кэшей для объектов — ведь между кэшированными объектами разных пользователей точно так же нет связей, важна лишь скорость доступа к кэшу, а также возможность быстро менять масштаб системы. Примером базы данных типа «ключ-значение» служит набор данных, представленных таблицей ниже. Здесь ключ — это название страны, а значение — список адресов в этой стране (рис. 1.):  Рис. 1. Пример базы данных типа «ключ-значение» Riak и Dynamo от Amazon — самые популярные СУБД данных типа «ключ-значение». |