Главная › Новости

Что такое NoSQL базы данных

Опубликовано: 05.09.2018

Запись вебинара на тему "SQL vs NoSQL"

NoSQL охватывает большое количество различных технологий баз данных, которые были разработаны для работы с растущим объёмом хранимых данных о пользователях, объектах и продуктах, растущей частотой, с которой эти данные запрашивались, и обеспечения необходимых производительности и обработки данных.

Реляционные базы данных, с другой стороны, не были сконструированы для решения задач масштабирования и гибкости, которые поставили современные приложения, также они не рассчитаны для получения преимуществ дешёвых хранилищ и вычислительных мощностей, доступных сегодня.

Типы NoSQL баз данных

Документные базы данных составляют пару каждого ключа со сложной структурой данных, известной как документ. Документы могут содержать много различных пар «ключ-значение» или пар «ключ-массив» или даже вложенные документы.

Графические хранилища используются для хранения информации о сетях, таких как социальные связи. Графические хранилища включают Neo4J и HyperGraphDB.

Хранилища «ключ-значение» - простейшие NoSQL базы данных. Каждый единичный элемент базы данных хранится как имя аттрибута(или ключ) вместе со своим значением. Примеры таких хранилищ, Riak и Voldemort. Некоторые хранилища «ключ-значение», такие как Redis, разрешают иметь каждому значению тип, например integer, что увеличивает функциональность.

Хранилища, такие как Cassandra и HBase, оптимизированы для запросов к большим наборам данных и хранят колонки данных вместе, вместо рядов.

Преимущества NoSQL

При сравнении с реляционными базами данных, NoSQL базы данных более масштабируемые и предоставляют лучшую производительность, и их модель данных решает несколько проблем, для которых реляционная модель не предназначена:

Динамические схемы

Реляционные базы данных требуют, чтобы схемы были определены до того, как Вы сможете добавлять данные. Например, Вы хотите хранить данные о Ваших заказчиках, такие как телефонные номера, имя и фамилию, адрес, город и страну - SQL базе данных необходимо знать, что Вы храните, заранее.

Это плохо соотносится с подходами гибкой разработки, потому что каждый раз как Вы добавляете новые характеристики, схема Вашей базы данных часто требует изменений. Так, если Вы решите на некоторой стадии разработки, что хотите хранить предпочтения заказчиков в дополнение к телефонным номерам, Вам понадобится добавить колонку в базу данных и затем перенести всю базу данных в новую схему.

Если база данных большая, это очень медленный процесс, занимающий значительный промежуток времени. Если Вы часто меняете данные, хранящиеся в Вашем приложении, этот временной промежуток также может повторяться часто. Также нет способа, использовать реляционные базы данных для эффективной адресации к данным, которые не структурированы или неизвестны заранее.

NoSQL базы данных позволяют вводить данные без предопределённой схемы. Это делает простым значительные изменения в приложении в реальном времени, не беспокоясь о прерываниях сервиса, что делает разработку быстрее, интеграцию кода более надёжной, и занимает меньше времени у администратора баз данных.

Автошардинг

По причине того, что реляционные базы данных структурированы, обычно они масштабируются вертикально - одиночный сервер выделен под всю базу, обеспечивая надёжность и сохранность данных. Это приводит к быстрому удорожанию, появлению ограничений масштабирования и создаёт относительно малое число ошибок в инфраструктуре базы данных.

Решение - масштабировать горизонтально, путём добавления серверов вместо концентрирования большей ёмкости на единичном сервере. Шардинг базы данных на много серверов может быть достигнут с SQL базами данных, но обычно это достигается через использование SAN и других сложных манипуляций с аппаратным обеспечением, для того, чтобы они работали как одиночный сервер. Поскольку базы данных не предоставляют такую возможность изначально, команды разработчиков работают над размещением множественных баз данных на некоторое число машин. Данные хранятся в каждом экземпляре базы данных автономно.

Код приложения разрабатывается для представления данных, представления запросов, и сбора результатов по всем экземплярам баз данных. Должен быть разработан дополнительный код для отслеживания ошибок ресурсов, представления объединений различных баз данных, для балансировки данных, репликации и прочих нужд. Кроме того, многие преимущества реляционных баз данных, такие как единство транзакций, компрометируются или исчезают при ручном шардинге.

NoSQL базы данных, с другой стороны, обычно поддерживают автошардинг, который означает, что они изначально и автоматически распределяют данные на произвольном количестве серверов, без необходимости приложению знать даже состав серверного пула. Данные и запросы автоматически загружаются на сервера, и, когда сервер выключается, они могут быстро быть перемещены без сбоя приложения.

Облачные вычисления стали значительно проще с провайдерами, такими как Amazon Web Service, предоставляющими неограниченное виртуальное хранилище «по запросу» и берущих на себя заботы по всем необходимым задачам администрирования баз данных.

Разработчикам больше не нужно создавать сложные, дорогие платформы для поддержки своих приложений, и они могут сконцентрироваться на написании кода приложения. Сервера общего пользования могут предоставить некоторые вычислительные возможности и некоторое хранилище, в виде единичного сервера за небольшую плату.

Репликация

Большинство NoSQL баз данных также поддерживают автоматическую репликацию данных. Это означает, что вы получаете высокую надёжность и восстановление после сбоев без привлечения отдельного приложения для управления этими задачами. Среда хранения, в сущности, виртуальна с точки зрения разработчика.

Интегрированное кэширование

Большое количество продуктов предлагают слой кэширования для SQL баз данных. Эти системы могут существенно улучшить быстродействие на чтение, но они не могут улучшить быстродействие на запись, и они усложняют конфигурацию системы. Если в Вашем приложении преобладают запросы на чтение, тогда распределённый кэш может подойти, но если в Вашем приложении преобладают запросы на запись или Вы имеете относительно равные количества чтений и записи, тогда распределённый кэш может не удовлетворить потребности Ваших конечных пользователей.

Многие технологии NoSQL баз данных имеют прекрасные встроенные средства кэширования, хранящие наиболее часто используемые данные в системной памяти, так долго как это возможно, и избавляют от необходимости отдельного слоя кэширования.

Выбор правильной базы данных для Ваших целей и приложений очень важен. Если Вы решаете использовать или нет альтернативные инфраструктуры, Вы можете учесть несколько факторов: масштабирование или повышение быстродействия относительно Вашей существующей системы, наличие доступных альтернатив в противовес дорогим проприетарным программам, или увеличение скорости и гибкости разработки. При выборе правильной базы данных для Вашего бизнеса и приложений, учитывайте эти пять важных факторов.