No-sql субд — для студента

Умение выбрать СУБД важно при разработке любого ПО. Мы собрали 10 систем управления базами данных и разобрались в их преимуществах.

Разоблачение мифа о безопасности NoSQL СУБД

Содержание статьи

Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД, противоположному популярным MySQL, Oracle Database и MSSQL. Так как интерес к перечисленным базам данных в последнее время значительно возрос, хакеры всех мастей просто не могли пройти мимо них. Давай же окунемся в увлекательный мир NoSQL-инъекций!

Думаю, ты знаком с реляционной моделью СУБД, согласно которой база данных состоит из сущностей (таблиц), связанных между собой. Доступ к данным осуществляется с помощью SQL — структурированного языка запросов.

За примерами реляционных СУБД далеко ходить не надо: MySQL, Oracle, Microsoft SQL Server.

Все остальные СУБД, архитектура которым отличается от классической реляционной модели, смело можно отнести к классу NoSQL-решений:

различные варианты хеш-таблиц (Redis, BigTable, memcached);
документо-ориентированные базы данных (MongoDB, CouchDB);
базы данных, основанные на графах (Neo4j, Sones GraphDB);
объектно-ориентированные базы данных (db4o, Cache, Jade);
XML-ориентированные базы данных (eXist, BaseX).

Основное отличие NoSQL-СУБД от их SQL-ориентированных конкурентов заключается в отсутствии единого, унифицированного языка запросов.

Например, MongoDB использует в качестве языка запросов BSON, eXist применяет XQuery, а Sonic GraphDB требует от разработчика знания GraphQL, языка запросов к данным, имеющим вид графов. Популярность NoSQL-СУБД растет с каждым днем, что не может не сказываться на нас с тобой.

Совсем скоро, буквально завтра, тебе придется искать не SQL-инъекции, а NoSQL-инъекции в очередном проекте. Не будем терять времени и поговорим о потенциальных уязвимостях.

No-SQL СУБД - Для студента Пример базы данных, построенной на графах
Другие статьи в выпуске:

Содержание выпуска
Подписка на «Хакер»

REST (Representational state transfer) — подход к разработке архитектуры распределенных систем, который подразумевает, что каждый объект системы однозначно определяется глобальным идентификатором, например URL.

Каждый URL, в свою очередь, имеет строго определенный формат. Управление сервисом основано на протоколе передачи данных.

Обычно это HTTP или HTTPS, который поддерживает минимальный набор операций над объектами: GET (получить), PUT (добавить), POST (сохранить) и DELETE (удалить).

BSON (Binary JavaScript Object Notation) — это бинарная форма представления простых структур данных и ассоциативных массивов. Название произошло от широко распространенного формата обмена данными JSON и неофициально расшифровывается как бинарный JSON (Binary JSON).

Довольно часто я слышу утверждение, что нереляционные СУБД безопасны, так как они не используют SQL и злоумышленник не может провести на них атаки типа SQL-injection. В какой-то степени это верно: нет SQL — нет SQL-инъекций.

Но, если в систему невозможно внедрить SQL-код, это еще не значит, что она безопасна.

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

манипулировать с REST-интерфейсом и подделывать межсайтовые запросы (CSRF);
использовать регулярные выражения в параметрах запроса;
выполнять скрипты на сервере, если на нем установлена NoSQL-СУБД (например, MongoDB позволяет запускать JavaScript-код);
получать доступ к данным через специальный интерфейс, поддерживаемый СУБД (SQL в реляционных базах данных, BSON в MongoDB и т. д.), и, если используется язык запросов, «исправлять» эти запросы.

Рассмотрим типовую архитектуру приложения с доступом к хранилищу данных NoSQL. Обычно она состоит из трех уровней:

приложение;
API базы данных NoSQL;
NoSQL-СУБД.

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

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

Но у тебя есть очень большое преимущество: большинство программных продуктов поставляются с исходным кодом, а значит, ты вполне сможешь его проанализировать и, возможно, найти что-нибудь стоящее. Если тебе повезет, то в твоих руках окажется ключ практически к любой базе данных!Следующий уровень — клиентское API.

Большинство NoSQL-СУБД имеют целый зоопарк различных библиотек для доступа к данным. Стоит отметить, что большинство библиотек представляют собой проекты с открытым исходным кодом, но часть из них уже не поддерживается. Вероятность обнаружить уязвимость в клиентской библиотеке значительно выше, чем непосредственно в самой СУБД.

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

Источник: https://xakep.ru/2012/04/13/exposure-nosql-db/

NoSQL базы данных — преимущества и недостатки

Привет всем! В данной статье речь пойдёт про NoSQL базы данных, которые были спроектированы и созданы после массового внедрения реляционных баз данных.

No-SQL СУБД - Для студента

Предпосылки появления

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

В связи с этим был создан термин Big Data, включающий в себя некую стратегию, позволяющую эффективно работать с огромными постоянно растущими массивами данных.

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

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

Виды NoSQL баз данных

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

Хранилище вида “ключ-значение”

Хранилища “ключ-значение” представляют собой простейший вид базы данных, являясь, по сути, ассоциативным массивом — каждому значению сопоставляется свой уникальный ключ. Простота хранилищ этого типа открывает просторы невероятной масштабируемости.

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

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

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

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

Базы данных типа “ключ-значение” не очень хорошо подходят в качестве полной замены реляционных БД, но нашли своё применение в качестве кэшей для объектов — ведь между кэшированными объектами разных пользователей точно так же нет связей, важна лишь скорость доступа к кэшу, а так же возможность быстро менять масштаб системы.

Наиболее известные примеры СУБД данного типа это Amazon DynamoDB, Berkeley DB, MemcacheDB, Redis и Riak.

Документоориентированные базы данных

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

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

Фактически документоориентированные БД являются более сложной версией хранилищ “ключ-значение” — они все ещё не очень хороши для систем, подразумевающих множество связей между элементами, но позволяют осуществлять выборку по запросу без полной загрузки отдельных документов в оперативную память.

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

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

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

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

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

Примеры СУБД данного типа: CouchDB, Couchbase, MarkLogic, MongoDB, eXist.

Графовые базы данных

Графовая модель базы данных представляет собой обобщение сетевой модели данных и отличается сильными связями между узлами.

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

В подобных задачах они сильно опережают реляционные БД по производительности, простоте внесения изменений и наглядности представления информации. У некоторых баз данных существуют механизмы специальной оптимизации для работы с SSD-накопителями.

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

Наиболее известные графовые СУБД это ArangoDB, FlockDB, Giraph, HyperGraphDB, Neo4j, OrientDB.

Bigtable-подобные базы данных

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

Эти хранилища имеют много общего с документоориентированными БД — системы управления содержимым, регистрацию событий, блоги.

Не стоит путать bigtable-подобные базы данных с колоночными хранилищами, которые являются, по сути, реляционными БД с раздельным хранением колонок.

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

Примерами СУБД данного типа являются: HBase, Cassandra, Hypertable, SimpleDB.

Сильные и слабые стороны NoSQL

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

Отсутствие SQL

Первая особенность весьма очевидна — это отсутствие SQL (Structured Query Language) — универсального языка запросов, который используется всеми реляционными системами. Все NoSQL системы имеют собственный API для взаимодействия или встроенный язык запросов, зачастую являющийся просто урезанной версией SQL. Это решение имеет свои позитивные стороны:

Простота работы.

Многие NoSQL решения, в основном хранилища вида “ключ-значение” имеют по сравнению с реляционными базами данных очень сильно урезанную функциональность, которая им просто не требуется для выполнения поставленных задач.

В таком случае оператору базы данных не требуется глубоких знаний достаточно мощного и гибкого механизма работы с SQL-запросами. Это очень сильно снижает входной порог для начала работы с NoSQL хранилищами.

Более простой синтаксис запросов — меньше ошибок. Для упрощения работы с базой данных некоторыми разработчиками используется ORM (Object-Relational Mapping) — технология, позволяющая автоматически транслировать операции с объектами в запросы к базе данных.

Зачастую подобные решения работают неэффективно и плодят множество ненужных или откровенно ошибочных запросов. Нельзя сказать, что разработчики ORM плохо выполняют свою работу — просто задача слишком сложна. Язык SQL универсален и очень емок, для полноценной работы с ним необходим определенный багаж знаний.

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

Недостатки у данного решения так же присутствуют, притом в долгосрочной перспективе они могут серьёзно перевесить все позитивные моменты:

Приложение сильно привязывается к конкретной СУБД. Язык SQL универсален для всех реляционных хранилищ и пользователю не придётся кардинально переписывать весь код в случае смены СУБД. Даже если две NoSQL системы концептуально практически не отличаются, они будут иметь очень мало общих стандартов в API и в специфике запросов.
Ограниченная емкость встроенного языка запросов. SQL имеет очень богатую историю и множество стандартов. Это очень мощный и сложный инструмент для операций с данными и составления отчетов. Практически все языки запросов и методы API хранилищ NoSQL были созданы на основе тех или иных функций SQL — как следствие, они имеют куда меньшую функциональность.
Низкая ценность и узкопрофильность знаний — специалистов с хорошим знанием SQL гораздо проще найти, в то время когда спецификой работы API некоторых NoSQL решений на серьёзном уровне мало кто увлекается — это значит, что многие специфические моменты оператору базы данных придется осваивать “на ходу”.

Простота и молодость NoSQL

Если преимущества простоты NoSQL хранилищ достаточно очевидны, то недостатки зачастую выясняются только с горьким опытом. Во-первых, ограничения структуры реляционных БД в определенной степени гарантируют целостность данных — информация, которая не удовлетворяет ограничениям по типу, просто не сможет попасть в базу.

В случае использования, например, хранилищ типа “ключ-значение” задача контроля целостности данных полностью ложится на приложение. Во-вторых, процесс создания реляционного хранилища включает в себя этап проектирования модели данных. На этой стадии можно оценить узкие места выбранной стратегии и спроектировать действительно надёжную и удобную систему.

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

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

Теперь есть смысл обсудить другую важную особенность NoSQL решений — они все по большей части весьма молоды. Многие из них распространяются по BSD-подобной лицензии и поддерживаются усилиями сообщества.

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

Помимо вероятности наличия багов и уязвимостей в самом коде нереляционных СУБД, это приводит к другим ошибкам — некоторые компании выбирают решения, которые просто не соответствуют их нуждам.

Самые сильные стороны NoSQL

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

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

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

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

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

Ключевые преимущества NoSQL баз в распределенных системах заключаются в процедурах шаринга и репликации.

Репликация — это копирование данных при их обновлении на другие сервера. Этот механизм позволяет добиться большей отказоустойчивости и масштабируемости системы. Принято выделять два вида репликации: master-slave и peer-to-peer.

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

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

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

Второй тип — peer-to-peer — предполагает, что все узлы равны в возможности обслуживать запросы на чтение и запись. Информация о обновлении данных передаётся от сервера к серверу по кругу.

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

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

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

Социальные данные

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

Действительно, формирование ленты новостей для пользователя средствами реляционной базы данных представляет собой операцию соединения нескольких таблиц.

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

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

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

Источник: https://andy-blog.ru/nosql-bazy-dannyh-preimushhestva-i-nedostatki

Субд nosql

11.05.2014 Ганеш Чандра Дека

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

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

СУБД класса NoSQL необходимы для приложений, имеющих дело с очень большими объемами квазиструктурированных и неструктурированных данных [1, 2], и, по информации nosql-database.org, сегодня имеется уже как минимум 150 Субд nosql, отвечающих требованиям разных типов пользователей.

Репрезентативная выборка из 15 популярных баз данных позволяет получить представление об основных особенностях таких СУБД.

Системы NoSQL

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

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

Cassandra

СУБД Apache Cassandra обеспечивает хорошую масштабируемость и высокую готовность без деградации быстродействия. Отказоустойчивость при работе на стандартном оборудовании в облачных инфраструктурах и линейная масштабируемость делают эту СУБД оптимальной платформой для критически важных данных.

Cassandra позволяет выполнять тиражирование между несколькими ЦОД и имеет средства обеспечения доступности данных при сбоях региональных систем.

Информационная модель ColumnFamily, используемая в Cassandra, предоставляет удобные столбцовые индексы с механизмом журнально-структурированной (log structured) записи высокого быстродействия, мощную систему поддержки мгновенных снимков и развитый встроенный механизм кэширования.

Источник: https://www.osp.ru/os/2014/04/13041253/

Разбираемся в типах NoSQL СУБД

Перевод статьи «EXPLORING THE DIFFERENT TYPES OF NOSQL DATABASES»
В этой статье мы познакомимся с разными типами NoSQL СУБД.
Всего есть 4 основных типа:

Хранилище «ключ-значение» — в нём есть большая хеш-таблица, содержащая ключи и значения.

Примеры: Riak, Amazon DynamoDB;
Документоориентированное хранилище — хранит документы, состоящие из тегированных элементов. Пример: CouchDB;
Колоночное хранилище — в каждом блоке хранятся данные только из одной колонки.

Примеры: HBase, Cassandra;
Хранилище на основе графов — сетевая база данных, которая использует узлы и рёбра для отображения и хранения данных. Пример: Neo4J.

База данных типа «ключ-значение»

Отсутствие схемы в базах данных «ключ-значение», например, Riak, — это как раз то, что вам нужно для хранения данных. Ключ может быть синтетическим или автосгенерированным, а значение может быть представлено строкой, JSON, блобом (BLOB, Binary Large Object, большой двоичный объект) и т.д.

Такие базы данных как правило используют хеш-таблицу, в которой находится уникальный ключ и указатель на конкретный объект данных. Существует понятие блока (bucket) — логической группы ключей, которые не группируют данные физически. В разных блоках могут быть идентичные ключи.

Производительность сильно вырастает за счёт кеширующих механизмов, которые работают на основе маппингов. Чтобы прочитать значение, вам нужно знать как ключ, так и блок, поскольку на самом деле ключ является хешем (блок + ключ).

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

Если поразмыслить о теореме CAP, то становится довольно очевидно, что такие хранилища хороши в плане доступности (Availability) и устойчивости к разделению (Partition tolerance), но явно проигрывают в согласованности данных (Consistency).
Пример: посмотрим на набор данных, представленных таблицей ниже. Здесь ключ — это название страны, а значение — список адресов в этой стране:
База данных такого типа позволяет читать и записывать значения с помощью ключа следующим образом:

Get(key) возвращает значение, связанное с переданным ключом;
Put(key, value) связывает значение с ключом;
Multi-get(key1, key2, …, keyN) возвращает список значений, связанных с переданным ключами;
Delete(key) удаляет запись для ключа из хранилища.

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

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

Riak и Dynamo от Amazon — самые популярные СУБД данных такого типа.

Документоориентированная база данных

Данные, представленные парами ключ-значение, сжимаются как хранилище документов схожим с хранилищем «ключ-значение» образом, с той лишь разницей, что хранимые значения (документы) имеют определённую структуру и кодировку данных. XML, JSON и BSON — некоторые из стандартных распространённых кодировок.

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

{officeName: «3Pillar Noida»,
{Street: «B-25», City: «Noida»,
State: «UP», Pincode: «201301»}
}
{officeName: «3Pillar Timisoara»,
{Boulevard: «Coriolan Brediceanu No. 10»,
Block: «B, Ist Floor»,
City: «Timisoara», Pincode: «300011»}
}
{officeName: «3Pillar Cluj»,
{Latitude: «40.748328»,
Longitude: «-73.985560»}
}

Одним из ключевых различий между хранилищем «ключ-значение» и документоориентированным является то, что последний включает метаданные, связанные с хранимым содержимым, что даёт возможность делать запросы на основе содержимого. Например, в указанном примере можно попробовать найти все документы, в которых «City» равно «Noida», что вернёт все документы, связанные с магазинами в этом городе.

Apache CouchDB — пример документоориентированной СУБД. CouchDB использует JSON для хранения данных, JavaScript в качестве языка запросов с использованием MapReduce и HTTP для API. Данные и отношения не хранятся в таблицах так, как в традиционных реляционных базах данных, а по сути являются набором независимых документов.

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

Couchbase и MongoDB — самые популярные документоориентированные СУБД.

Колоночная база данных

В колоночных NoSQL базах данных данные хранятся в ячейках, сгруппированных в колонки, а не в строки данных. Колонки логически группируются в колоночные семейства.

Колоночные семейства могут состоять из практически неограниченного количества колонок, которые могут создаваться во время работы программы или во время определения схемы.

Чтение и запись происходит с использованием колонок, а не строк.

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

Реляционные базы данных хранят каждую строку как непрерывную запись на диске.

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

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

Модель данных

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

Источник: https://tproger.ru/translations/types-of-nosql-db/

Управление базами данных

Системный архитектор, Oracle DBA, разработчик perl/python, опыт в отрасли — 20 летВ настоящее время работает на аутсорсе. Работал в интернет-провайдерах и телекоме. Имел опыт внедрения и разработки продуктов в госструктурах, таких как минздрав и соцфонд.

Был главным разработчиком стартап проекта Ipstudio AMBS (биллинг для VoIP). Участвовал в проектировании и разработке OLTP систем. Проектировал и развертывал серверные системы в датацентрах.Закончил Кыргызско-Российский Государственный Университет, 2001, Инженер автоматизированных систем.

Собственный технический блог на — dbadmins.ru

Руководитель программы

Кристина Кучерова

Сбербанк России

Тимлидархитектор БД в US-based startup Кремниевой долины.Ex-Архитектор модели данных в Сбербанке России.Окончила ЮРГПУ (НПИ) по специальности «Математическое обеспечение и администрирование информационных систем». С 2015 года — аспирант в Санкт-Петербургском политехническом университете им. Петра Великого. Работала в компании Comepay в качестве DB-тимлида и заместителя тех. директора по архитектуре. Принимала участие в реализации проекта Syncplicity (Distillery, USA), где занималась разработкой БД и оптимизацией производительности. Участник отраслевых конференций CMG Impact 2016 (San Diego, USA), Zabbix Conf 2017 (Рига, Латвия) и прочих. Есть опыт преподавания курса «Базы Данных» в Ростовском колледже связи и информатики. Считает, что очень важно учиться именно на кейсах из реального производства.

Преподаватель

Александр Румянцев

Postgres Professional

Database administrator в компании Postgres Professional. Большой опыт руководства отделами администраторов в Wikimart, Rambler и Ru-Center. В отрасли более 15 лет: из них 10 – в highload и более 5 лет на позиции руководителя

Преподаватель

Инженер-программист хранилища данных Комус, www.komus.orgРанее был архитектором, техническим руководителем проекта,ООО «РД Консалтинг», rdtex.ruЗанимался проектом «Отчет по операционной деятельности» для банка из российского ТОП-3 (ведущий разработчик), проект «Автоматизированная система налогового учета» для банка из российского ТОП-10 (технический руководитель проекта).Большой объем разработки под Oracle 11 (написание кода для построения витрин данных, вторичной обработки данных в DWH), написание регламентирующих документов, консультации для начинающих коллег, техническая поддержка стендов разработки, оценки трудозатрат, распределение актуальных задач, контроль графика выполнения, взаимодействие с заказчиком.Занимался разработкой и исправлением функционала корпоративного DWHOracle 11G, Pentaho Kettle, Business Objects, mySQL, Informix, Java, разработка веб-интерфейсов, Javascript, Visual Basic 6.0, SAP Hana, Delphi 7, интеграция с SAP HybrisЗанимался разработкой архитектуры ядра ИС, руководил группой реинжиниринга.Был главным архитектором отдела ФГУП НИИ Почтовой связи, www.niips.ru, где проектировал архитектуры и разрабатывал приложения для автоматизированных сортировочных центров Почты России. Разрабатывал инструментальные средства сбора информации для отчетности по KPI. Написание отчетов вручную и разработка инструментальных средств построения отчетности результатов работы отдела/предприятия. Взаимодействие с заказчиком. Организационная работа. Техническое руководство командой разработчиков — оценки трудозатрат, распределение актуальных задач, контроль графика выполнения, определение функционального состава новых версий, взаимодействие с заказчиком (Почта России). Разработка регламентов и нормативов деятельности отдела, должностных инструкций сотрудников.Инструментарий: Oracle 10, Delphi 6,.ODAC, BDE, Developer Express components, Toad, PL/SQL Developer, Enterprise Architect, Java 1.7, Borland StarTeam. Системный инженер в холдинге компаний RusLink. Опыт в отрасли более 10 лет. Работал как в частном секторе, так и в окологосударственном (Ростелеком). Участвовал в разработке и внедрении новых продуктов и сервисов. Есть опыт в руководстве отделом тех. поддержки и администрирования.Профессиональные навыки:- знание современных клиентских и серверных ОС;- установка и настройка различных СУБД (MS SQL, PostgreSQL, MySQL, MariaDB);- администрирование веб-серверов Apache, Nginx;- виртуализация и знание продуктов VMware, VirtualBox, Proxmox, Vagrant;- написание скриптов на Bash;- применение Ansible;- знание активного сетевого оборудования Mikrotik, D-Link и др.

Преподаватель

Автор курса «Архитектор высоких нагрузок».Учился в технопарке Mail.Ru. В 2013 году начал работать стажером в проекте «Почта» компании Mail.Ru. С 2015 года преподавал различные (в том числе и авторские) курсы в образовательных проектах Mail.Ru. С 2016 года занимал должность руководителя группы в Почте. В том же году получил диплом магистра по специальности «Программная инженерия» в МГТУ им. Н.Э. Баумана.С 2018 года начал работать в Ситимобил на должности руководителя группы. С апреля 2019 года был назначен руководителем направления серверной разработки. Занимается развитием технических навыков людей, поддержкой их мотивации, развитием отказоустойчивых архитектур, внедрением новых технологий в процесс разработки (golang, tarantool).Основные технические навыки:GolangCMySQLTarantoolHighload architectureLinux API Аналитик со стажем работы в крупных телекоммуникационных компаниях, таких как МТС, Ростелеком.Уверена, что посчитать и измерить можно все на свете — главное найти правильную шкалу и метрику.Обожает задавать себе и другим сложные провокационные вопросы и найти на них ответ в данных.

Преподаватель

Ведущий специалист в АО «Гринатом».Более 10 лет опыта профессиональной разработки.Основной стек: .NET / C#, Java, MS SQL Server.Full stack разработка систем для внутренних и внешних заказчиков (от анализа требований до реализации, эксплуатации и технической поддержки). Закончил в 2006 году Московский институт электронной техники (МИЭТ) по специальности «Вычислительные машины комплексы системы и сети».

Преподаватель

Источник: https://otus.ru/lessons/subd/

Понимание 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 хранилищ; ниже представлены наиболее популярные:

MongoDB. Документная БД с открытым исходным кодом.
CouchDB. БД, которая использует JSON для документов, JavaScript для MapReduce запросов, и обычный HTTP для API.
GemFire. Распределенная платформа управления данными, обеспечивающая динамическую масштабируемость, высокую производительность и сохранность как у БД.
Redis. Сервер структур данных, где ключами могут быть строки, хеши, списки, наборы и сортированные наборы.
Cassandra. БД, которая обеспечивает масштабируемость и высокую надежность без потери производительности.
memcached. Высокопроизводительная, распределенная в памяти и объектная система кеширования с открытым исходным кодом.
Hazelcast. Высоко масштабируемая распределенная платформа с открытым исходным кодом.
HBase. Hadoop БД, распределенное и масштабируемое хранилище больших объемов данных.
Mnesia. Распределенная система управления базами данных.
Neo4j. Высокопроизводительная, enterprise-класса графовая БД с открытым исходным кодом.

С оригинальным текстом урока вы можете ознакомиться на spring.io.

Источник: https://spring-projects.ru/understanding/nosql/

Разработчик	Лицензия	Написана на
Oracle	Oracle Corporation	Проприетарная	Assembly, C, C++
MySQL	Oracle Corporation	GPL v2 или проприетарная	C, C++
Microsoft SQL Server	Microsoft Corporation	Проприетарная	C, C++
PostgreSQL	PostgreSQL Global Development Group	Лицензия PostgreSQL (бесплатное ПО с открытым исходным кодом, либеральная лицензия)	C
MongoDB	MongoDB Inc.	Различные варианты лицензирования	C++, C, JavaScript
DB2	IBM	Проприетарная EULA	Assembly, C, C++
Microsoft Access	Microsoft Corporation	Пробное ПО
Redis	Salvatore Sanfilippo	Лицензия BSD	ANSI C

No-sql субд — для студента

Популярные системы управления базами данных

SQL-базы данных

1. Oracle

Особенности

2. MySQL

Особенности

3. Microsoft SQL Server

Особенности

4. PosgreSQL

Особенности

NoSQL-базы данных

5. MongoDB

Особенности

6. DB2

Особенности DB2 11.1

7. Microsoft Access

Особенности

8. Cassandra

Разоблачение мифа о безопасности NoSQL СУБД

Содержание статьи

NoSQL базы данных — преимущества и недостатки

Предпосылки появления

Виды NoSQL баз данных

Хранилище вида “ключ-значение”

Документоориентированные базы данных

Графовые базы данных

Bigtable-подобные базы данных

Сильные и слабые стороны NoSQL

Отсутствие SQL

Простота и молодость NoSQL

Самые сильные стороны NoSQL

Социальные данные

Субд nosql

Системы NoSQL

Cassandra

Разбираемся в типах NoSQL СУБД

База данных типа «ключ-значение»

Документоориентированная база данных

Колоночная база данных

Управление базами данных

Понимание NoSQL

Использование NoSQL

Кеширование

Хранилища ключ-значение

Хранение документов

Быстрый доступ к большим наборам данных

Менее жесткие требования согласованности

Ограничения NoSQL

примеры NoSQL баз данных