что такое nosql простыми словами
Что такое nosql простыми словами
NoSQL – это подход к реализации масштабируемого хранилища (базы) информации с гибкой моделью данных, отличающийся от классических реляционных СУБД. В нереляционных базах проблемы масштабируемости (scalability) и доступности (availability), важные для Big Data, решаются за счёт атомарности (atomicity) и согласованности данных (consistency) [1].
Зачем нужны нереляционные базы данных в Big Data: история появления и развития
NoSQL-базы оптимизированы для приложений, которые должны быстро, с низкой временной задержкой (low latency) обрабатывать большой объем данных с разной структурой [2]. Таким образом, нереляционные хранилища непосредственно ориентированы на Big Data. Однако, идея баз данных такого типа зародилась гораздо раньше термина «большие данные», еще в 80-е годы прошлого века, во времена первых компьютеров (мэйнфреймов) и использовалась для иерархических служб каталогов. Современное понимание NoSQL-СУБД возникло в начале 2000-х годов, в рамках создания параллельных распределённых систем для высокомасштабируемых интернет-приложений, таких как онлайн-поисковики [1].
Вообще термин NoSQL обозначает «не только SQL» (Not Only SQL), характеризуя ответвление от традиционного подхода к проектированию баз данных. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII-файлы, а вместо SQL-запросов доступа к данным использовала шелловские скрипты [3]. В начале 2000-х годов Google построил свою поисковую систему и приложения (GMail, Maps, Earth и прочие сервисы), решив проблемы масштабируемости и параллельной обработки больших объёмов данных. Так была создана распределённые файловая и координирующая системы, а также колоночное хранилище (column family store), основанное на вычислительной модели MapReduce. После того, как корпорация Google опубликовала описание этих технологий, они стали очень популярны у разработчиков открытого программного обеспечения. В результате этого был создан Apache Hadoop и запущены основные связанные с ним проекты. Например, в 2007 году другой ИТ-гигант, Amazon.com, опубликовав статьи о своей высокодоступной базе данных Amazon DynamoDB. Далее в эту гонку NoSQL- технологий для управления большими данными включилось множество корпораций: IBM, Facebook, Netflix, eBay, Hulu, Yahoo! и другие ИТ-компаний со своими проприетарными и открытыми решениями [1].
Многообразие NoSQL-решений
Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных
Все NoSQL решения принято делить на 4 типа:
Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки
По сравнению с классическими SQL-базами, нереляционные СУБД обладают следующими преимуществами:
Обратной стороной вышеуказанных достоинств являются следующие недостатки:
Подводя итог описанию основных аспектов нереляционных СУБД, стоит отметить некоторую некорректность запроса «NoSQL vs SQL» в связи с разными архитектурными подходами и прикладными задачами, на которые ориентированы эти ИТ-средства. Традиционные SQL-базы отлично справляются с обработкой строго типизированной информации не слишком большого объема. Например, локальная ERP-система или облачная CRM. Однако, в случае обработки большого объема полуструктурированных и неструктурированных данных, т.е. Big Data, в распределенной системе следует выбирать из множества NoSQL-хранилищ, учитывая специфику самой задачи. В частности, для самостоятельных решений интернета вещей (Internet of Things), в т.ч. промышленного, отлично подходит Cassandra, о чем мы рассказывали здесь. А в случае многоуровневой ИТ-инфраструктуры на базе Apache Hadoop стоит обратить внимание на HBase, которая позволяет оперативно, практически в режиме реального времени, работать с данными, хранящимися в HDFS.
Нереляционные СУБД находят больше областей приложений, чем традиционные SQL-решения
Понимание NoSQL
NoSQL относится к базе данных, которая не основана на SQL (Structured Query Language), языке, чаще всего ассоциирующимся с реляционными базами данных. По факту, NoSQL данные не являются реляционными, NoSQL БД обычно не имеют схем и они имеют более согласованную модель, чем имеющиеся в традиционных реляционных БД.
Термин «NoSQL» означает, что традиционные реляционные БД не позворяют решить все задачи, особенно те, которые связаны с большими объемами данных. Термин был расширен до значения «Not only SQL», который означает поддержку для потенциальных SQL-интерфейсов в каждом ядре нереляционной БД. Разработчики приложений, которые используют NoSQL решения, не обязательно исключают реляционные БД, а вместо этого видят ценность правильности использования каждого из хранилищ данных для решения соответствующей задачи.
Использование NoSQL
NoSQL хранилища данных отвечают за те ключевые требования хранения данных, которые не могут быть удовлетворены реляционными БД.
Кеширование
Кеширование результатов является общей задачей повышения отзывчивости приложения. К примеру, web-сайт отдает одни и те же ответы сотням и тысячам пользователей. Вместо того, чтобы утомительно пересчитывать в реляционной БД одно и то же, стоит вручную настроить кеширование. Некоторые NoSQL хранилища предоставляют похожие решения, но разработчику не нужно поддерживать пользовательский кеш.
Хранилища ключ-значение
Некоторые NoSQL БД сохраняют пары ключ-значение для быстрого поиска, к примеру, в случае доступа вопрос/ответ. Реляционные БД более ориентированы на сохранение сложных структур данных и различных взаимосвязей между типами данных. Эта технология излишне усложняет, когда разработчик хочет реализовать способ быстрого сохранения и доступа к Q&A данным.
Хранение документов
другие типы данных более документо ориентированы и имеют различные вариации. К примеру, формы данных могут иметь дополнительные поля. Реляционные БД с их строгими схемами предъявляют требования ко всем полям каждой из сохраняемой строки данных. Документоориентированные NoSQL хранилища более гибкие и эффективны в этом плане.
Быстрый доступ к большим наборам данных
Реляционные БД теряют производительность при поиске в больших объемах данных. Исторически, разработчики строят системы, в которых пишутся SQL запросы для нахождения небольшого количества записей, которые удаляют для увеличения общей эффективности. Чем больше результирующий набор, тем более дорогим становится запрос. Большие объемы данных или запросы, которые включают обработку больших объемов данных, называются «data warehousing».
NoSQL хранилища становятся более популярными и протестированы во многих ситуациях. Эти ситуации включали большие объемы данных, а также большой темп роста данных во многих системах.
Менее жесткие требования согласованности
NoSQL также считается альтернативой традиционным реляционным БД, потому что некоторые из требований к согласованности, которые являются частью реляционных БД, очень отличаются в современных системах.
Разработчики знают, что некоторые требования к данным не требуют жесткой ACID модели реляционных БД, но они, как правило, имеют худшую производительность. Взамен они могут удовлетворить свои потребности, используя согласованность в конечном счете, которая, как правило, имеет лучшую производительность. Некоторые NoSQL хранилища даже предоставляют разработчику выбор какой должна быть согласованность, жесткой или нет.
Ограничения NoSQL
SQL является мощным, 40-летним стандартом, который был возможен потому, что все реляционные БД имели одну и ту же концепцию сохранения данных в таблицы и ссылку на них посредством внешнего ключа. Несмотря на то, что переход с одной реляционной БД на другую не на 100% прозрачен, он намного легче, чем переход между двумя различными NoSQL хранилищами. Разрабочики, изучившие SQL, сталкиваются с небольшими проблемами при переходе между вендорами.
Поэтому каждое NoSQL хранилище имеет уникальный подход к тому, как хранить данные, а также как разные биты данных относятся к другим, нет одного API для управления всем этим. Когда применяется новое NoSQL хранилище, разработчик должен потратить время и усилия на изучение нового языка запросов, а также семантику согласованности.
примеры NoSQL баз данных
Доступно множество NoSQL хранилищ; ниже представлены наиболее популярные:
С оригинальным текстом урока вы можете ознакомиться на spring.io.
Учебные материалы
Spring data и поддержка NoSQL
Ниже приведены ссылки на Spring NoSQL проекты:
Каждый из этих проектов предоставляет упрощенный API для взаимодействия с соответствующим хранилищем. Они также используют Spring Data Commons для возможности написания базовых методов, таких как save(), delete(), update() и findXxxYyyZzz(), с автоматической генерацией запросов.
Что такое NoSQL?
Высокопроизводительные нереляционные базы данных с гибкими моделями данных
Что такое базы данных NoSQL?
Базы данных NoSQL специально созданы для определенных моделей данных и обладают гибкими схемами, что позволяет разрабатывать современные приложения. Базы данных NoSQL получили широкое распространение в связи с простотой разработки, функциональностью и производительностью при любых масштабах. Ресурсы, представленные на этой странице, помогут разобраться с базами данных NoSQL и начать работу с ними.
Как работает база данных NoSQL (нереляционная БД)?
Базы данных NoSQL используют разнообразные модели данных для доступа к данным и управления ими. Базы данных таких типов оптимизированы для приложений, которые работают с большим объемом данных, нуждаются в низкой задержке и гибких моделях данных. Все это достигается путем смягчения жестких требований к непротиворечивости данных, характерных для других типов БД.
Рассмотрим пример моделирования схемы для простой базы данных книг.
Для чего можно использовать базы данных NoSQL?
Базы данных NoSQL хорошо подходят для многих современных приложений, например мобильных, игровых, интернет‑приложений, когда требуются гибкие масштабируемые базы данных с высокой производительностью и широкими функциональными возможностями, способные обеспечивать максимальное удобство использования.
Типы баз данных NoSQL
БД на основе пар «ключ‑значение». Базы данных с использованием пар «ключ‑значение» поддерживают высокую разделяемость и обеспечивают беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД. Хорошими примерами использования для баз данных типа «ключ‑значение» являются игровые, рекламные приложения и приложения IoT. Amazon DynamoDB обеспечивает стабильную работу БД с задержкой не более нескольких миллисекунд при любом масштабе. Такая устойчивая производительность послужила основной причиной переноса Snapchat Stories в сервис DynamoDB, поскольку эта возможность Snapchat связана с самой большой нагрузкой на запись в хранилище.
Документ В коде приложения данные часто представлены как объект или документ в формате, подобном JSON, поскольку для разработчиков это эффективная и интуитивная модель данных. Документные базы данных позволяют разработчикам хранить и запрашивать данные в БД с помощью той же документной модели, которую они используют в коде приложения. Гибкий, полуструктурированный, иерархический характер документов и документных баз данных позволяет им развиваться в соответствии с потребностями приложений. Документная модель хорошо работает в каталогах, пользовательских профилях и системах управления контентом, где каждый документ уникален и изменяется со временем. Amazon DocumentDB (совместимая с MongoDB) и MongoDB — распространенные документные базы данных, которые предоставляют функциональные и интуитивно понятные API для гибкой разработки.
Графовые БД. Графовые базы данных упрощают разработку и запуск приложений, работающих с наборами сложносвязанных данных. Типичные примеры использования графовых баз данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний. Amazon Neptune – это полностью управляемый сервис графовых баз данных. Neptune поддерживает модель Property Graph и Resource Description Framework (RDF), предоставляя на выбор два графовых API: TinkerPop и RDF / SPARQL. К числу распространенных графовых БД относятся Neo4j и Giraph.
БД в памяти. Часто в игровых и рекламных приложениях используются таблицы лидеров, хранение сессий и аналитика в реальном времени. Такие возможности требуют отклика в пределах нескольких микросекунд, при этом резкое возрастание трафика возможно в любой момент. Amazon MemoryDB для Redis – это совместимый с Redis надежный сервис базы данных в памяти, который уменьшает задержку чтения до миллисекунд и обеспечивает надежность в нескольких зонах доступности. MemoryDB специально создана для обеспечения сверхвысокой производительности и надежности, поэтому ее можно использовать как основную базу данных для современных приложений на базе микросервисов. Amazon ElastiCache – это полностью управляемый сервис кэширования в памяти, совместимый с Redis и Memcached для обслуживания рабочих нагрузок с низкой задержкой и высокой пропускной способностью. Такие клиенты, как Tinder, которым требуется, чтобы их приложения давали отклик в режиме реального времени, пользуются системами хранения данных в памяти, а не на диске. Еще одним примером специально разработанного хранилища данных является Amazon DynamoDB Accelerator (DAX). DAX позволяет DynamoDB считывать данные в несколько раз быстрее.
Поисковые БД. Многие приложения формируют журналы, чтобы разработчикам было проще выявлять и устранять неполадки. Amazon Elasticsearch Service (Amazon ES) – специально разработанный сервис для визуализации и аналитики автоматически генерируемых потоков данных в режиме, близком к реальному времени, путем индексирования, агрегации частично структурированных журналов и метрик и поиска по ним. Amazon ES – это также мощная высокопроизводительная поисковая система для полнотекстового поиска. Компания Expedia задействует более 150 доменов Amazon ES, 30 ТБ данных и 30 миллиардов документов для разнообразных особо важных примеров использования – от операционного мониторинга и устранения неисправностей до отслеживания стека распределенных приложений и оптимизации затрат.
Сравнение баз данных SQL (реляционных) и NoSQL (нереляционных)
В течение десятилетий центральное место в разработке приложений занимала реляционная модель данных, которая использовалась в реляционных базах данных, таких как Oracle, DB2, SQL Server, MySQL и PostgreSQL. Но в середине – конце 2000‑х годов заметное распространение стали получать и другие модели данных. Для обозначения появившихся классов БД и моделей данных был введен термин «NoSQL». Часто «NoSQL» используется в качестве синонима к термину «нереляционный».
Существует множество типов БД NoSQL с различными особенностями, но в таблице ниже приведены основные отличия баз данных NoSQL от SQL.
Подходящие рабочие нагрузки
Реляционная модель нормализует данные и преобразует их в таблицы, состоящие из строк и столбцов. Схема жестко задает таблицы, строки, столбцы, индексы, отношения между таблицами и прочие элементы базы данных. Такая БД обеспечивает целостность ссылочных данных в отношениях между таблицами.
Реляционные базы данных обеспечивают набор свойств ACID: атомарность, непротиворечивость, изолированность, надежность.
Сравнение терминологии SQL и NoSQL
В следующей таблице приведено сравнение терминологии некоторых баз данных NoSQL с терминологией баз данных SQL.
SQL или NoSQL — вот в чём вопрос
Все мы знаем, что в мире технологий баз данных существует два основных направления: SQL и NoSQL, реляционные и нереляционные базы данных. Различия между ними заключаются в том, как они спроектированы, какие типы данных поддерживают, как хранят информацию.
Реляционные БД хранят структурированные данные, которые обычно представляют объекты реального мира. Скажем, это могут быть сведения о человеке, или о содержимом корзины для товаров в магазине, сгруппированные в таблицах, формат которых задан на этапе проектирования хранилища.
Нереляционные БД устроены иначе. Например, документо-ориентированные базы хранят информацию в виде иерархических структур данных. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.
Внутреннее устройство различных систем управления базами данных влияет на особенности работы с ними. Например, нереляционные базы лучше поддаются масштабированию.
Какую технологию выбрать? Ответ на этот вопрос зависит от особенностей проекта, о котором идёт речь.
О выборе SQL-баз данных
Не существует баз данных, которые подойдут абсолютно всем. Именно поэтому многие компании используют и реляционные, и нереляционные БД для решения различных задач. Хотя NoSQL-базы стали популярными благодаря быстродействию и хорошей масштабируемости, в некоторых ситуациях предпочтительными могут оказаться структурированные SQL-хранилища. Вот две причины, которые могут послужить поводом для выбора SQL-базы:
О выборе NoSQL-баз данных
Если есть подозрения, что база данных может стать узким местом некоего проекта, основанного на работе с большими объёмами информации, стоит посмотреть в сторону NoSQL-баз, которые позволяют то, чего не умеют реляционные БД.
Вот возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase:
SQL и NoSQL
Начнём с некоторых ключевых концепций реляционных и нереляционных баз данных. Ниже показана база данных, содержащая сведения о взаимоотношениях людей. Вариант a — это бессхемная структура, построенная в виде графа, характерная для NoSQL-решений. Вариант b показывает, как те же данные можно представить в структурированном виде, типичном для SQL. 
Два варианта представления данных
Бессхемность означает, что два документа в структуре данных NoSQL не должны иметь одинаковые поля и могут хранить данные разных типов. Вот, например, массив объектов, набор полей которых не совпадает.
При реляционном подходе данные надо хранить в заранее спроектированной структуре, из которой эти данные потом можно извлекать. Например, используя оператор JOIN при выборке из двух таблиц:
Как более продвинутый пример, для демонстрации того, когда SQL предпочтительнее NoSQL, рассмотрим особенности применения в NoSQL-базах алгоритмов уплотнения. Проблема заключается в том, что в некоторых NoSQL-базах (например, в CouchDB и HBase) постоянно приходится формировать так называемые sstables — строковые таблицы в формате ключ-значение, отсортированные по ключу. В такие таблицы, которые сохраняются на диск, данные попадают из таблиц, хранящихся в памяти, при их переполнении и в других ситуациях. При интенсивной работе с базой создание таблиц, со временем, приводит к тому, что подсистема ввода-вывода устройства хранения данных становится узким местом для операций чтения данных. Как результат, чтение в NoSQL-базе происходит медленнее, чем запись, что сводит на нет одно из главных преимуществ нереляционных баз данных. Именно для того, чтобы уменьшить этот эффект, системы NoSQL используют, в фоновом режиме, алгоритмы уплотнения данных, пытаясь объединить множество таблиц в одну. Но и сама по себе эта операция весьма ресурсоёмка, система работает под повышенной нагрузкой.
Масштабируемость
Одно из основных различий рассматриваемых технологий заключается в том, что NoSQL-базы лучше поддаются масштабированию. Например, в MongoDB имеется встроенная поддержка репликации и шардинга (горизонтального разделения данных) для обеспечения масштабируемости. Хотя масштабирование поддерживается и в SQL-базах, это требует гораздо больших затрат человеческих и аппаратных ресурсов.
| Тип хранилища данных | Сценарий использования | Пример | Рекомендации |
| Хранилище типа ключ-значение | Подходит для простых приложений, с одним типом объектов, в ситуациях, когда поиск объектов выполняют лишь по одному атрибуту. | Интерактивное обновление домашней страницы пользователя в Facebook. | Рекомендовано знакомство с технологией memcached. Если приходится искать объекты по нескольким атрибутам, рассмотрите вариант перехода к хранилищу, ориентированному на документы. |
| Хранилище, ориентированное на документы | Подходит для хранения объектов различных типов. | Транспортное приложение, оперирующее данными о водителях и автомобилях, работая с которым надо искать объекты по разным полям, например — имя или дата рождения водителя, номер прав, транспортное средство, которым он владеет. | Подходит для приложений, в ходе работы с которыми допускается реализация принципа «согласованность в конечном счёте» с ограниченными атомарностью и изоляцией. Рекомендуется применять механизм кворумного чтения для обеспечения своевременной атомарной непротиворечивости. |
| Система хранения данных с расширяемыми записями | Более высокая пропускная способность и лучшие возможности параллельной обработки данных ценой слегка более высокой сложности, нежели у хранилищ, ориентированных на документы. | Приложения, похожие на eBay. Вертикальное и горизонтальное разделение данных для хранения информации клиентов. | Для упрощения разделения данных используются HBase или Hypertable. |
| Масштабируемая RDBMS | Использование семантики ACID освобождает программистов от необходимости работать на достаточно низком уровне, а именно, отвечать за блокировки и непротиворечивость данных, обрабатывать устаревшие данные, коллизии. | Приложения, которым не требуются обновления или слияния данных, охватывающие множество узлов. | Стоит обратить внимание на такие системы, как MySQL Cluster, VoltDB, Clustrix, ориентированные на улучшенное масштабирование. |
Более подробное сравнение SQL и NoSQL можно найти в этом материале. Вот его основные положения. А именно, были проведены испытания трёх основных характеристик систем: параллельная обработка данных, работа с хранилищами информации, репликация данных. Возможности параллельной обработки оценивались путём анализа механизмов блокировки, управления параллельным доступом на основе многоверсионности, и ACID. Тестирование хранилищ охватывало и физические носители, и хранилища использующие оперативную память. Репликацию испытывали в синхронном и асинхронном режимах.
Используя данные, полученные в ходе испытаний, авторы делают выводы о том, что SQL-базы с возможностью кластеризации показали многообещающие результаты производительности в расчёте на один узел, и, кроме того, обладают способностью масштабируемости, что даёт системам RDBMS преимущество перед NoSQL за счёт полного соответствия принципам ACID.
Индексация
В системах RDBMS индексация используется для ускорения операций извлечения данных из баз. Отсутствие индекса означает, что таблица должна быть просмотрена целиком для того, чтобы выполнить запрос на чтение.
И в SQL, и в NoSQL-базах индексы служат одной и той же цели — ускорить и оптимизировать извлечение данных. Но то, как именно они работают — различается из-за разных архитектур баз данных и особенностей хранения информации в базе. В то время, как SQL-индексы представлены в виде B-деревьев, которые отражают иерархическую структуру реляционных данных, в NoSQL базах данных они указывают на документы, или на части документов, между которыми, в основном, нет никаких отношений. Вот подробный материал на эту тему.
CRM-системы
CRM-приложения — это один из лучших примеров систем, для которых характерны огромные объёмы ежедневно обрабатываемых данных и очень большое количество транзакций. Все разработчики таких приложений используют и SQL, и NoSQL базы данных. И, хотя большая часть данных транзакций всё ещё хранится в SQL-базах, применение находят общедоступные системы класса DBaaS (data-base-as-a-service, база данных как сервис), наподобие AWS DynamoDB и Azure DocumentDB, в результате, серьёзная нагрузка по обработке данных может быть перенесена в облачные NoSQL-базы.
В то время, как использование подобных служб освобождает разработчика от решения задач по обслуживанию хранилищ, это, кроме того, область, где NoSQL базы применяются для того, для чего они, в основном, и были созданы, например, для глубинного анализа данных. Объёмы информации, хранимой в огромных CRM-системах финансовых и телекоммуникационных компаний, было бы практически невозможно проанализировать, используя инструменты вроде SAS или R. Это потребовало бы огромных аппаратных ресурсов.
Главное преимущество таких систем — использование неструктурированных данных, похожих на документы. Такие данные могут подаваться на вход статистических моделей, которые дают компаниям возможность выполнять различные виды анализа. CRM-приложения, кроме того, являются весьма удачным примером, в котором две системы баз данных выступают не конкурентами, а существуют в гармонии, играя каждая свою роль в большой архитектуре управления данными.
Итоги
Занимаясь поиском системы управления базами данных, можно выбрать одну технологию, а позже, уточнив требования, переключиться на что-то другое. Однако, разумное планирование позволит сэкономить немало времени и средств.
Вот признаки проектов, для которых идеально подойдут SQL-базы:
Уважаемые читатели, а вам приходилось выбирать системы управления базами данных для собственных проектов? Если да — поделитесь пожалуйста опытом, расскажите, что и почему вы в итоге выбрали.