Более простой синтаксис запросов меньше ошибок - Ремонт и установка крупной бытовой техники

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

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

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

История популярности

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

NoSQL — это революция

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

Принципиально новыми подходами NoSQL решения тоже не могут массово похвастаться — к примеру, концепция запущенной в 2008 году MongoDB — это более эффективная реализация модели работы БД Pick 1965-го года выпуска.

SQL базы данных обречены

Подобные разговоры ведутся уже почти второй десяток лет, и по-прежнему реляционные БД держат доминирующие позиции на рынке с огромным отрывом от любых NoSQL решений. Это происходит в первую очередь потому, что NoSQL базы данных не могут более эффективно решать задачи SQL. Наиболее удачные NoSQL решения, в первую очередь, нацелены на решения специфических задач и создаются гигантами IT-индустрии для собственных нужд — это продукты от Google, Amazon, Microsoft и Apache, обслуживающие конкретные проекты. Google AppEngine Data Store возможно использовать столько с веб-сервисами Google, хранилище SQL Data Services является частью платформы Microsoft Azure, а SimpleDB входит в состав Amazon WebServices.

Необлачные хранилища, которыми можно пользоваться, просто скачав и установив их у себя, зачастую являются достаточно молодыми открытыми проектами, которые так же создавались под конкретные нужды. Они не были созданы, чтобы решать весь объем задач, который позволяют решать SQL системы. Более того, назначение чаще всего не является ключевой преградой для массового внедрения NoSQL систем — они имеют определенный набор недостатков, который не критичен для гигантов IT-индустрии, но становится решающим для большей части обычных компаний.

Вся шумиха вокруг NoSQL и Big Data — это обман

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

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

Виды 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 базы имеют проблему с масштабированием, что не позволяет использовать их для крупных социальных сетей. Помимо этого реляционные хранилища обладают и рядом других преимуществ, в числе которых надежность, гарантия целостности информации и безопасности пользовательских данных. При реализации действительно сложных многопользовательских проектов молниеносная скорость и бесконечная масштабируемость системы редко выходят на первый план — в первую очередь компании стремятся сделать надежный продукт.

Пик популярности NoSQL решений был во многом связан с амбициозным заявлением, поступившим от социальной сети Twitter. Они видели определенные недостатки работы с реляционным хранилищем MySQL для своих твитов и изъявили желание перейти на новую NoSQL СУБД Cassandra. Но эта идея так и не была воплощена в жизни — как комментируют этот момент сами сотрудники Twitter — компания оценила свои приоритеты, после чего решение было признано слишком рискованным. С другой стороны, то же самое NoSQL хранилище отлично прижилось в качестве основной базы данных для социальных сетей Instagram и Facebook — а это уже очень весомые истории успеха для всего семейства NoSQL.

Аналитика данных

В облачных хранилищах и разработанных для них NoSQL решениях часто используется принцип множественной аренды. Он заключается в том, что большое количество пользователей одновременно использует одну и ту же систему. Чтобы предотвратить её перегруз в решениях, рассчитанных на большую масштабируемость, применяют политику ограничения запросов. Например, в SimpleDB время выполнение запроса не может превышать 5 секунд, а в Google AppEngine Datastore один запрос к базе не позволяет получить более 1000 записей.

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

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

Выводы

Резкий скачок популярности NoSQL баз данных и связанные с ним истории использования нереляционных СУБД показали миру IT важность реалистичной оценки приоритетов компании. Некоторые вендоры успешно внедрили у себя NoSQL хранилища и получили заметное снижение убытков и повышение качества приложений. Другие потерпели неудачу, поздно поняв, что принятое решение им не подходит. А третьи просто остались со своими технологиями. Реляционные или нереляционные базы данных — это не единственный выбор, который предстоит сделать компании. Не менее важен и выбор между конкретными системами и конкретными стратегиями работы с ними.

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

Источник

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

SQL (Structured Query Language) — универсальный язык запросов, который используется всеми реляционными системами.

NoSQL имеют собственный API для взаимодействия.

Преимущества РСУБД — соответствия базы данных требованиям ACID, целостность данных, структурированность.

Преимущества NoSQL — скорость обработки данных, масштабируемость, распределенность систем.

Сильные стороны

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

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

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

Слабые стороны

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

Нереляционным системам всё ещё не хватает универсальности, надежности, целостности и предсказуем

Источник

Что такое NoSQL

Это нереляционные базы данных.

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

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

Способ организации данных

В SQL-базах всё просто: есть, условно говоря, таблицы, и есть связи между ними. Все данные хранятся в этих таблицах.

В NoSQL-базах всё иначе — там может не быть таблиц, а вместо них — свои модели данных. Каждая из них подходит под свои задачи, универсальной нет. Вот основные модели:

Ключ-значение

У каждой записи есть название поля и его значение. Например:

name: ‘Миша’
today: ‘9/09/2020’
president: ‘Путин’
writer: ‘Пушкин’
pogoda: ‘ну такая’

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

Это полезно, например, для словарей или механизмов автозамены: «Если встретилось такое слово — замени на вот такое».

Колонки

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

1 6

Графы

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

Дерево — это когда данные хранятся по системе «родитель — отпрыски». Есть некий родительский кусок данных, у него есть связанные с ним отпрыски. У тех тоже могут быть свои отпрыски и так далее. Каждая единица данных может быть чьим-то отпрыском (но только кого-то одного) и иметь сколько-то собственных отпрысков.

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

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

❤️ Про деревья мы недавно писали: что такое Trie и как работает бустинг

2 5

Документы

Вот это космос, смотрите.

Если мы храним данные в таблице, у нас есть столбцы и строки. И если у нас про кого-то есть данные, а про другого нет, — где-то в таблице будут пропуски. А если в таблице нет нужного столбца, а нам нужно положить в неё новый тип данных, нам придётся создавать новый столбец, и он для всех будет пустым:

Имя	Возраст	Город	Роль
Миша	35	Брянск	Редактор
Женя	Москва	Директор
Родион	Ульяновск

Реляционная БД заставляет нас заранее придумывать, как будет работать база данных; какие там будут поля; какие допустимы типы данных. Например, в таблицу выше уже не добавишь информацию о том, что Родион носит бороду — точнее, добавить-то её можно, но тогда у нас появится куча пустых ячеек. А если этих столбцов нужно добавлять много? Это крайне нерационально.

Теперь представьте, что есть механизм, который позволяет хранить эти данные в более свободном формате. Например:

name: Миша
age: 35
city: Брянск
job: Редактор
stickerpack: Доктор Хаус

Каждая из этих записей (про Мишу, Женю и Родиона) — это три отдельных документа. И база данных настолько умна, что может при необходимости распознать, что там где лежит. Если мы запросим у нее Boroda, то она прошерстит все документы и поищет там разметку со словом «Борода». В первых двух документах этой разметки не будет, а в третьем — будет. Именно этот документ нам база данных и вернёт.

Работа с SQL-запросами

Уже по названию видно, что NoSQL не поддерживает SQL-запросы. Это значит, что у каждой такой базы своя методика работы с данными и общего стандарта нет. Не получится выучить операции в Redis, который работает по принципу «ключ-значение» и быстро освоить MongoDB, где всё основано на документах.

Некоторые NoSQL-базы пытаются поддерживать что-то из SQL, но на практике это работает плохо.

Скорость и масштабируемость

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

В NoSQL-подходе базу легко разделить между несколькими компьютерами, связанными по сети. Чем больше компьютеров и чем быстрее сеть — тем больше база и скорость работы. Получается, что железо можно оставить тем же, и просто увеличить количество узлов в базе.

Надёжность и безопасность

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

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

Применение

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

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

Источник

Какие свойства характерны для nosql решений

Содержание

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

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

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

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

Существует довольно много различных моделей и функциональных систем для NoSQL баз данных:

Чтобы лучше понять чем отличаются все эти типы СУБД, рассмотрим их.

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

Начнем наше рассмотрение с типа хранилища ключ-значение, так как это самое основное решение из семейства NoSQL. Этот тип БД работает с данными типа ключ-значение, например как словарь. Здесь нет места ни структуре, ни связям. После подключения к серверу (например Redis) приложение может задать ключ и его значение, а в последствии получать эти данныe по запросу.

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

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

Распределённое хранилище

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

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

Документо-ориентированные хранилища

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

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

Базы данных на основе графов

На последок мы оставили самое интересное. БД на основе графов хранят данные в совсем другом виде. Они используют древовидные структуры с узлами и связями соединяющими их. Так же как и в математике, некоторые операции гораздо удобнее выполнять с такими данными благодаря связям между ними и их группировке (например, связи между людьми).

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

СУБД Ключ-Значение (Key-Value)

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

Популярные СУБД

Некоторые популярные хранилища:

Примеры использования

Часто встречающиеся случаи применения БД хранилищ ключ-значение:

NoSQL распределённые СУБД

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

Популярные СУБД

Вот основные представители этого типа БД:

Примеры использования

Основные области применения:

Документо-ориентированные СУБД

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

Популярные СУБД

Часто встречающиеся СУБД:

Примеры использования

Часто встречающиеся сферы применения:

NoSQL базы данных типа граф

Такие типы БД хранят информацию совершенно особенно, совсем не как все остальные СУБД.

Популярные СУБД

Часто встречаемые СУБД:

Примеры использования

Часто встречаемые примеры использования:

Сравнение NoSQL СУБД и реляционных СУБД

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

Примеры использования NoSQL

Источник

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

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

nosql

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствие SQL

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

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

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

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

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

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

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

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

Аналитика данных

Выводы

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

Источник

5 рекомендаций по оптимизации запросов SQL

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

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

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

Возможно, вы думаете: “Я мастерски владею SQL и пишу отличные запросы. Даже если в моем стиле и присутствуют мелкие непродуктивные навыки, почему я должен от них отказываться?”. На это есть несколько причин.

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

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

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

1. Начните грамотно оформлять запросы

Отступы и пробелы необходимы для структурирования запросов. Так звучит основная концепция SQL. Рассмотрим данный постулат.

Начнем с совершенно экстремального примера. Надо сказать, что написать такой запрос стоило немало усилий.

Этот запрос не содержит отступов и пробелов:

select TA.id, TA.client_name, TA.client_surname, sum(TB.client_purchases) as total_client_purchases, sum(TB.client_Discounts) as total_clients_discounts 
from table_A as TA left join table_B as TB on TA.id = TB.id where TA.country = "France"
group by TA.id

Как вам далось чтение запроса? Весьма сложное испытание. Однажды я работал с человеком, который программировал запросы SQL именно так.

Попробуем добавить в запрос отступы:

select 
    TA.id, 
    TA.client_name,
    TA.client_surname, 
    sum(TB.client_spent_amount) as total_client_spent_amount, 
    sum(TB.client_Discounts) as total_clients_discounts 
from table_A as TA 
left join table_B as TB 
    on TA.id = TB.id 
where TA.country="France"
group by TA.id

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

select

TA.id,
TA.client_name,
TA.client_surname,
sum(TB.client_spent_amount) as total_client_spent_amount,
sum(TB.client_Discounts) as total_clients_discounts

from table_A as TA
left join table_B as TB
on TA.id = TB.id
where TA.country = "France"
group by TA.id

Отлично! Теперь без особого труда можно понять различные уровни внутри запроса.

2. Пишите синтаксис SQL в верхнем регистре

Согласно писаным и неписаным законам, синтаксис SQL пишется в верхнем регистре.

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

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

Преобразуем предыдущий запрос с учетом новой логики:

SELECT     TA.id, 
    TA.client_name,
    TA.client_surname, 
    SUM(TB.client_spent_amount) AS total_client_spent_amount, 
    SUM(TB.client_Discounts)    AS total_clients_discounts 



  


                       
  



    FROM table_A                    AS TA 
LEFT JOIN table_B               AS TB 
    ON TA.id = TB.id 
WHERE TA.country = "France"
GROUP BY TA.id

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

3. Попрощайтесь с инструкцией SELECT * FROM

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

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

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

Поэтому избегаем следующего способа действия:

SELECT * FROM tableA

И берем на вооружение предлагаемый вариант:

SELECT 
  column1, 
  column2, 
  column4, 
  column6 
FROM tableA

Вероятно, вы по-прежнему рассматриваете возможность применения * EXCEPT() для исключения ненужных столбцов.

Есть вариант получше.

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

4. Используйте меньше подзапросов и больше CTE

Не стоит задействовать более одного подзапроса на временную таблицу или CTE. Рассмотрим на примере.

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

Сначала пишем запрос с двумя подзапросами, который вычисляет три средние зарплаты:

SELECT T1.COUNTRY, 
         AVG(T1.salary)     AS AVG_salary_per_country
         T2.AVG_salary_per_city,
         T3.AVG_salary_companyFROM salary_table AS T1
CROSS JOIN 
   (
      SELECT 
         T1.CITY, 
         AVG(T1.salary)     AS AVG_salary_per_city,
         T3.AVG_salary_company
      FROM salary_table AS T2
      CROSS JOIN 
            (
                SELECT AVG(salary)  AS AVG_salary_company
          FROM salary_table
                ) AS T3
      GROUP BY 1,3
  ) AS T2
GROUP BY 1,3,4

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

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

WITH SALARY_COUNTRY AS 
(
    SELECT T1.COUNTRY, 
           AVG(T1.salary)     AS AVG_salary_per_country
    FROM salary_table AS T1
GROUP BY 1
),
SALARY_CITY AS 
(
    SELECT T1.CITY, 
           AVG(T1.salary)     AS AVG_salary_per_city
    FROM salary_table AS T1
    GROUP BY 1
),
SALARY_GLOBAL AS 
(
    SELECT AVG(salary)  AS AVG_salary_company
    FROM salary_table
)
SELECT 
    T1.country,
    T1.AVG_salary_per_country,
    T2.city, 
    T2.AVG_salary_per_city,
    T3.AVG_salary_company
FROM SALARY_COUNTRY       AS T1
CROSS JOIN SALARY_CITY    AS T2
CROSS JOIN SALARY_GLOBAL  AS T3

5. Присваивайте столбцам логически обоснованные имена

При создании запроса мы можем просто переносить столбцы, используя их номера:

SELECT 
    col1,
    col2,
    col3,
    col4
FROM TABLE
ORDER BY 1,2

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

SELECT 
    id,
    name,
    age,
    bank_balance,
FROM TABLE
ORDER BY bank_balance,age

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

Заключение

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

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

Доверяйте данным — они знают, как лучше!

Разоблачение мифа о безопасности 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 базы данных — преимущества и недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствие 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

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

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

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

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

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

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

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

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

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

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

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

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

Сохранение всей ленты пользователя в виде единой ненормализованной структуры выглядит очень хорошим решением. Но реализованные в данный момент графовые 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/

Источник

Эта статья содержит неполный список синтаксических различий между MariaDB и SQL Server и написана для пользователей SQL Server,незнакомых с MariaDB.

Compatibility Features

Некоторые функции предназначены для улучшения синтаксической и семантической совместимости между версиями MariaDB,между MariaDB и MySQL,а также между MariaDB и другими СУБД.Этот раздел посвящен совместимости между MariaDB и SQL Server.

sql_mode и old_mode

На семантику и синтаксис SQL в MariaDB влияет переменная sql_mode . Его значение представляет собой список флагов, разделенных запятыми, и каждый из них, если он указан, влияет на разные аспекты синтаксиса и семантики SQL.

Особенно важным флагом для пользователей, знакомых с SQL Server, является MSSQL .

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

Пример использования:

# check the current global and local sql_mode values
SELECT @@global.sql_mode;
SELECT @@session.sql_mode;
# empty sql_mode for all usaers
SET GLOBAL sql_mode = '';
# add MSSQL flag to the sql_mode for the current session
SET SESSION sql_mode = CONCAT(sql_mode, ',MSSQL');

old_mode очень похож на sql_mode, но его цель — обеспечить совместимость со старыми версиями MariaDB. Его флаги не должны влиять на совместимость с SQL Server (хотя теоретически возможно, что некоторые из них влияют как побочный эффект).

MariaDB поддерживает исполняемые комментарии . Они предназначены для написания общих запросов, которые выполняются только MariaDB и, возможно, только определенными версиями.

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

Выполняется MariaDB и MySQL (см.ниже):

SELECT * FROM tab  WHERE a = 1 OR b = 2;

Выполняется только MariaDB:

SELECT *  FROM tab;

Выполняется MariaDB,начиная с версии 10.0.5:

DELETE FROM user WHERE id = 100 ;

Как объясняется на странице « Понимание архитектуры MariaDB», MariaDB изначально был разветвлен на основе MySQL. В то время исполняемые комментарии уже поддерживались MySQL. Вот почему /*! ... */ синтаксис поддерживается как MariaDB, так и MySQL. Но поскольку MariaDB также поддерживает особый синтаксис, не поддерживаемый MySQL, он добавил /*M! ... */ синтаксис.

Generic Syntax

Здесь мы обсудим некоторые различия между синтаксисом MariaDB и SQL Server,которые могут повлиять на любого пользователя,а также некоторые подсказки,позволяющие сделать запросы совместимыми с разумным объемом работы.

Delimiters

SQL Server использует два разных терминатора:

Партия терминатор это go команды. Он сообщает клиентам Microsoft отправить набранный нами текст на SQL Server.
Терминатор запроса является точкой с запятой ( ; ) , и он говорит SQL сервер , где запрос заканчивается.

Редко нужно использовать ; в SQL Server. Это требуется, например, для некоторых распространенных табличных выражений.

Но то же самое не относится к MariaDB. Обычно с MariaDB вы используете только ; .

Однако в MariaDB также есть ситуации, когда вы хотите использовать ; но вы пока не хотите, чтобы клиент командной строки mysql отправлял запрос. Это можно сделать в любой ситуации, но это особенно полезно при создании сохраненных подпрограмм или использовании BEGIN NOT ATOMIC .

Причину лучше объяснить на примере:

CREATE PROCEDURE p()
BEGIN
    SELECT * FROM t1;
    SELECT * FROM t2;
END;

Если мы введем эту процедуру таким образом в клиенте mysql , как только мы введем первый ; (после первого SELECT ) и нажмите Enter, выписка будет отправлена. MariaDB попытается разобрать его и вернет ошибку.

Чтобы избежать этого, mysql реализует оператор DELIMITER . Это клиентское заявление никогда не отправляется в MariaDB. Вместо этого клиент использует его, чтобы узнать, когда следует отправить типизированный запрос. Исправим приведенный выше пример:

DELIMITER ||

CREATE PROCEDURE p()
BEGIN
    SELECT * FROM t1;
    SELECT * FROM t2;
END;

DELIMITER ;

Names

В MariaDB максимальная длина большинства имен составляет 64 символа. При переносе базы данных SQL Server в MariaDB проверьте, не превышают ли некоторые имена этот предел (максимальная длина SQL Server — 128).

По умолчанию имена MariaDB чувствительны к регистру,если в операционной системе имена файлов чувствительны к регистру (Linux),и не чувствительны к регистру,если операционная система не чувствительна к регистру (Windows).SQL Server по умолчанию является регистронезависимым во всех операционных системах.

При переносе базы данных SQL Server в MariaDB в Linux, чтобы избежать проблем, вы можете установить системную переменную lower_case_table_names равным 1, сделав имена таблиц, имена баз данных и псевдонимы нечувствительными к регистру.

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

Чтобы также включить использование двойных кавычек ( " ), измените sql_mode, добавив флаг ANSI_QUOTES . Это эквивалент установки QUOTED_IDENTIFIER ON в SQL Server.

Чтобы также включить использование кавычек в стиле SQL Server ( [ и ] ), измените sql_mode, добавив флаг MSSQL .

Чувствительность к регистру хранимых процедур и функций никогда не является проблемой,поскольку в SQL Server они не чувствительны к регистру.

Quoting Strings

В SQL Server по умолчанию строки могут заключаться только в одинарные кавычки ( ' ), а для использования двойных кавычек в строке их следует удвоить ( '' ). Это также работает по умолчанию в MariaDB.

SQL Server также позволяет использовать двойные кавычки ( " ) для заключения строк в кавычки. Это работает по умолчанию в MariaDB, но, как упоминалось ранее, не будет работать, если sql_mode содержит флаг ANSI_QUOTES .

NULL

По умолчанию семантика NULL в SQL Server и MariaDB одинакова.

Однако SQL Server позволяет изменять его глобально с помощью SET ANSI_NULLS OFF или на уровне базы данных с помощью ALTER DATABASE .

В MariaDB нет возможности достичь точно такого же результата. Чтобы выполнить NULL-безопасное сравнение в MariaDB, следует заменить оператор = оператором <=> .

Также обратите внимание, что MariaDB не поддерживает псевдо-значение UNKNOWN . Выражение типа NULL OR 0 возвращает NULL в MariaDB.

LIKE

В MariaDB выражения LIKE имеют только два символа со специальными значениями: % и _ . Эти два символа имеют то же значение, что и в SQL Server.

Дополнительные символы, распознаваемые SQL Server ( [ , ] и ^ ), являются частью регулярных выражений. MariaDB поддерживает оператор REGEXP , который поддерживает полный синтаксис регулярных выражений.

Язык определения данных

Здесь мы обсудим некоторые различия в DDL,о которых администраторы баз данных должны знать.

Хотя этот раздел предназначен для выделения наиболее заметных различий DDL между MariaDB и SQL Server, существует множество других, как в синтаксисе, так и в семантике. См. Документацию оператора ALTER .

Изменение таблиц онлайн

Изменение таблиц в режиме онлайн может стать проблемой,особенно если таблицы большие и мы не хотим нарушить работу.

MariaDB предлагает следующие решения для помощи:

Предложение ALTER TABLE … ALGORITHM позволяет указать, какой алгоритм следует использовать для выполнения определенной операции. Например INPLACE указывает MariaDB не создавать копию таблицы (возможно, потому, что у нас недостаточно места на диске), а INSTANT указывает MariaDB выполнить операцию мгновенно. Не все алгоритмы поддерживаются для определенных операций. Если выбранный нами алгоритм не может быть использован, оператор ALTER TABLE завершится с ошибкой.
Предложение ALTER TABLE … LOCK позволяет указать, какой тип блокировки следует использовать. Например, NONE сообщает MariaDB избегать любой блокировки таблицы, а SHARED позволяет получить только общую блокировку. Если для операции требуется более строгая блокировка, чем та, которую мы запрашиваем, инструкция ALTER TABLE завершится ошибкой. Иногда это происходит из-за того, что LOCK уровень LOCK недоступен для указанного ALGORITHM .

Чтобы узнать, какие операции требуют копии таблицы и какие уровни блокировки необходимы, см. InnoDB Online DDL Overview .

ALTER ALTER TABLE может быть поставлен в очередь, потому что длительная инструкция (даже SELECT ) требует блокировки метаданных . Поскольку это может вызвать проблемы, иногда мы хотим, чтобы операция просто завершилась неудачно, если ожидание слишком долгое. Этого можно добиться с помощью предложений WAIT и NOWAIT , синтаксис которых немного отличается от SQL Server.

SQL Server WITH ONLINE = ON эквивалентен MariaDB LOCK = NONE . Однако обратите внимание, что большинство операторов ALTER TABLE поддерживают ALGORITHM = INSTANT , который является неблокирующим и намного быстрее (почти мгновенно, как предполагает синтаксис).

ЕСЛИ СУЩЕСТВУЕТ,ЕСЛИ НЕ СУЩЕСТВУЕТ,ИЛИ ЗАМЕНИТЬ

Большинство операторов DDL, включая ALTER TABLE , поддерживают следующий синтаксис:

DROP IF EXISTS : выдается предупреждение (не ошибка), если объект не существует.
OR REPLACE : Если объект существует, он удаляется и создается заново; в противном случае он создается. Эта операция является атомарной, поэтому объект не существует ни в какой момент времени.
CREATE IF NOT EXISTS : если объект уже существует, выдается предупреждение (не ошибка). Объект не будет заменен.

Эти утверждения функционально похожи (но менее многословны)на фрагменты SQL Server,подобные следующим:

IF NOT EXISTS (
        SELECT name
            FROM sysobjects
            WHERE name = 'my_table' AND xtype = 'U'
    )
    CREATE TABLE my_table (
        ...
    )
go

Altering Columns

В SQL Server единственный синтаксис для изменения столбца таблицы — ALTER TABLE ... ALTER COLUMN . MariaDB предоставляет больше команд ALTER TABLE для получения того же результата:

CHANGE COLUMN позволяет выполнить любое изменение, указав новое определение столбца, включая имя.
ИЗМЕНИТЬ КОЛОНКУ позволяет вносить любые изменения, кроме переименования столбца. Это немного более простой синтаксис, который мы можем использовать, когда мы не хотим изменять имя столбца.
ALTER COLUMN позволяет изменить или удалить значение DEFAULT .
RENAME COLUMN позволяет изменить только имя столбца.

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

Слово COLUMN обычно необязательно, за исключением случая RENAME COLUMN .

MariaDB поддерживает операторы SHOW для быстрого вывода списка всех объектов определенного типа (таблицы, представления, триггеры …). Большинство операторов SHOW поддерживают предложение LIKE для фильтрации данных. Например, чтобы вывести список таблиц в текущей базе данных, имя которых начинается с ‘wp_’:

Это эквивалент данного запроса,который будет работать как на MariaDB,так и на SQL Server:

В общем, для каждого оператора CREATE MariaDB также поддерживает оператор SHOW CREATE . Например, есть SHOW CREATE TABLE, который возвращает оператор CREATE TABLE, который можно использовать для воссоздания таблицы.

Хотя SQL Server не имеет возможности показать оператор DDL для воссоздания объекта, операторы SHOW CREATE функционально аналогичны sp_helptext() .

MariaDB не поддерживает расширенные свойства. Вместо этого он поддерживает предложение COMMENT для большинства операторов CREATE и ALTER .

Комментарии можно увидеть с помощью операторов SHOW CREATE или путем запроса таблиц information_schema . Например:

Операторы MariaDB SHOW ERRORS и SHOW WARNINGS можно использовать для отображения ошибок или предупреждений и ошибок. Это удобно для клиентов, но хранимые процедуры не могут работать с выводом этих команд.

Команды администрирования и обслуживания в MariaDB используют синтаксис,отличный от синтаксиса SQL Server.

MariaDB не имеет BULK INSERT . Вместо этого он поддерживает:

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

Источник

Разработчик	Лицензия	Написана на
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

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

История популярности

NoSQL — это революция

SQL базы данных обречены

Вся шумиха вокруг NoSQL и Big Data — это обман

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

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

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

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

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

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

Отсутствие SQL

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

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

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

Аналитика данных

Выводы

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

Сильные стороны

Слабые стороны

Что такое NoSQL

Способ организации данных

Ключ-значение

Колонки

Графы

Документы

Работа с SQL-запросами

Скорость и масштабируемость

Надёжность и безопасность

Применение

Какие свойства характерны для nosql решений

Содержание

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

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

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

Распределённое хранилище

Документо-ориентированные хранилища

Базы данных на основе графов

СУБД Ключ-Значение (Key-Value)

NoSQL распределённые СУБД

Документо-ориентированные СУБД

NoSQL базы данных типа граф

Сравнение NoSQL СУБД и реляционных СУБД

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

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

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

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

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

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

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

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

Отсутствие SQL

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

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

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

Аналитика данных

Выводы

1. Начните грамотно оформлять запросы

2. Пишите синтаксис SQL в верхнем регистре

3. Попрощайтесь с инструкцией SELECT * FROM

4. Используйте меньше подзапросов и больше CTE

5. Присваивайте столбцам логически обоснованные имена

Заключение

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

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

1. Oracle

Особенности

2. MySQL

Особенности

3. Microsoft SQL Server

Особенности

4. PosgreSQL

Особенности

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

5. MongoDB

Особенности

6. DB2

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

7. Microsoft Access

Особенности