Субд nosql наиболее оптимальна в использовании в случаях когда

SQL или NoSQL — вот в чём вопрос

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

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

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

Внутреннее устройство различных систем управления базами данных влияет на особенности работы с ними. Например, нереляционные базы лучше поддаются масштабированию.

ac8d887f5017443fada8493d382bb04f

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

О выборе SQL-баз данных

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

О выборе NoSQL-баз данных

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

Вот возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase:

SQL и NoSQL

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

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

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

Как более продвинутый пример, для демонстрации того, когда SQL предпочтительнее NoSQL, рассмотрим особенности применения в NoSQL-базах алгоритмов уплотнения. Проблема заключается в том, что в некоторых NoSQL-базах (например, в CouchDB и HBase) постоянно приходится формировать так называемые sstables — строковые таблицы в формате ключ-значение, отсортированные по ключу. В такие таблицы, которые сохраняются на диск, данные попадают из таблиц, хранящихся в памяти, при их переполнении и в других ситуациях. При интенсивной работе с базой создание таблиц, со временем, приводит к тому, что подсистема ввода-вывода устройства хранения данных становится узким местом для операций чтения данных. Как результат, чтение в NoSQL-базе происходит медленнее, чем запись, что сводит на нет одно из главных преимуществ нереляционных баз данных. Именно для того, чтобы уменьшить этот эффект, системы NoSQL используют, в фоновом режиме, алгоритмы уплотнения данных, пытаясь объединить множество таблиц в одну. Но и сама по себе эта операция весьма ресурсоёмка, система работает под повышенной нагрузкой.

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

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

Тип хранилища данных Сценарий использования Пример Рекомендации
Хранилище типа ключ-значение Подходит для простых приложений, с одним типом объектов, в ситуациях, когда поиск объектов выполняют лишь по одному атрибуту. Интерактивное обновление домашней страницы пользователя в Facebook. Рекомендовано знакомство с технологией memcached.
Если приходится искать объекты по нескольким атрибутам, рассмотрите вариант перехода к хранилищу, ориентированному на документы.
Хранилище, ориентированное на документы Подходит для хранения объектов различных типов. Транспортное приложение, оперирующее данными о водителях и автомобилях, работая с которым надо искать объекты по разным полям, например — имя или дата рождения водителя, номер прав, транспортное средство, которым он владеет. Подходит для приложений, в ходе работы с которыми допускается реализация принципа «согласованность в конечном счёте» с ограниченными атомарностью и изоляцией. Рекомендуется применять механизм кворумного чтения для обеспечения своевременной атомарной непротиворечивости.
Система хранения данных с расширяемыми записями Более высокая пропускная способность и лучшие возможности параллельной обработки данных ценой слегка более высокой сложности, нежели у хранилищ, ориентированных на документы. Приложения, похожие на eBay. Вертикальное и горизонтальное разделение данных для хранения информации клиентов. Для упрощения разделения данных используются HBase или Hypertable.
Масштабируемая RDBMS Использование семантики ACID освобождает программистов от необходимости работать на достаточно низком уровне, а именно, отвечать за блокировки и непротиворечивость данных, обрабатывать устаревшие данные, коллизии. Приложения, которым не требуются обновления или слияния данных, охватывающие множество узлов. Стоит обратить внимание на такие системы, как MySQL Cluster, VoltDB, Clustrix, ориентированные на улучшенное масштабирование.

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

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

Индексация

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

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

CRM-системы

CRM-приложения — это один из лучших примеров систем, для которых характерны огромные объёмы ежедневно обрабатываемых данных и очень большое количество транзакций. Все разработчики таких приложений используют и SQL, и NoSQL базы данных. И, хотя большая часть данных транзакций всё ещё хранится в SQL-базах, применение находят общедоступные системы класса DBaaS (data-base-as-a-service, база данных как сервис), наподобие AWS DynamoDB и Azure DocumentDB, в результате, серьёзная нагрузка по обработке данных может быть перенесена в облачные NoSQL-базы.

В то время, как использование подобных служб освобождает разработчика от решения задач по обслуживанию хранилищ, это, кроме того, область, где NoSQL базы применяются для того, для чего они, в основном, и были созданы, например, для глубинного анализа данных. Объёмы информации, хранимой в огромных CRM-системах финансовых и телекоммуникационных компаний, было бы практически невозможно проанализировать, используя инструменты вроде SAS или R. Это потребовало бы огромных аппаратных ресурсов.

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

Итоги

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

Вот признаки проектов, для которых идеально подойдут SQL-базы:

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

Источник

Обзор NOSQL баз данных

NoSQL databasesВ последние годы наблюдается стремительный взлет популярно­сти семейства технологий хранения данных, известных как NOSQL (дерзкий акроним от Not Only SQL (Не только SQL), или акроним от еще более категоричного No to SQL (Нет SQL)). Но сам по себе термин NOSQL означает лишь, что такие хранилища данных не явля­ются SQL-ориентированными реляционными базами данных, а ин­тересным и полезным набором разнообразных технологий хранения, имеющих множество эксплуатационных, функциональных и архи­тектурных характеристик.

Что послужило причиной создания этих новых баз данных? Какие задачи они призваны решить? Здесь будут рассмотрены некоторые из проблем обработки данных, которые возникли в течение последне­го десятилетия. Далее будут описаны четыре семейства NOSQL-баз данных, в том числе графовые.

Движение NOSQL

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

Неудивительно, что количество хранимых данных резко возросло, и их объем стал основной движущей силой использования NOSQL- хранилищ. Объем можно определить просто как размер наборов хра­нимых данных.

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

Чтобы избежать соединений и сопутствующих им болезней и тем са­мым улучшить обработку очень больших наборов данных, в NOSQL-мире предложено несколько альтернатив реляционной модели. Хотя они лучше справляются с обработкой очень больших наборов дан­ных, эти альтернативные модели, как правило, менее наглядны, чем реляционная (за исключением графовой модели, которая является даже более наглядной).

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

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

ACID или BASE

Первое знакомство с базами данных NOSQL часто происходит в хо­рошо знакомом контексте реляционных баз данных. Понятно, что данные и модели запросов будут другими (в конце концов, отсутству­ет поддержка SQL), но модели согласования данных, используемые NOSQL-хранилищами, также весьма отличаются от тех, что исполь­зуются реляционными базами данных. Разные NOSQL-базы данных используют разные модели согласования для поддержки разных объемов, скоростей изменения и разнообразия данных, упомянутых выше.

В мире реляционных баз данных общеизвестны ACID-транзакции, некоторое время являвшиеся эталоном. Гарантии ACID обеспечива­ют безопасную среду для обработки данных:

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

Для многих прикладных областей ACID-транзакции являются из­лишне пессимистичными. В мире NOSQL ACID-транзакции вышли из моды, поскольку хранилища смягчили требования к немедленной согласованности, актуальности данных и их точности, чтобы полу­чить другие преимущества, такие как масштабируемость и гибкость. Вместо ACID возник другой популярный подход BASE, описываю­щий принципы более оптимистичной стратегии хранения:

Принципы BASE значительно слабее гарантий ACID, и между ними нет прямого соответствия. Значения в BASE-хранилище до­ступны (потому что это является основой масштабирования), но это не предлагает гарантированной согласованности реплик при запи­си. BASE-хранилища обеспечивают менее строгий контроль: данные будут согласованы позднее, вероятнее всего, во время чтения (как, например, в Riak), или всегда будут согласованы, но только для определенных фиксаций, обработанных последними (как, например, в Datomic).

Разработчики должны учитывать такую свободную поддержку со­гласованности и уделять больше внимания согласованности данных. Им следует познакомиться с методами BASE конкретного храни­лища и научиться работать в рамках его ограничений. На практике в каждом конкретном случае делается выбор, приемлема ли возмож­ная противоречивость данных или же нужно потребовать от базы данных обеспечить непротиворечивость при чтении, согласившись с возникающими при этом задержками. (Чтобы гарантировать не­противоречивое чтение, базе данных необходимо сравнить все реп­лики элемента данных и в случае их несогласованности выполнить корректирующую обработку.) При разработке это добавляет сложно­стей, по сравнению с применением транзакций, которые берут на себя обязанности по достижению согласованности, но это не является не­разрешимой проблемой, просто это требует дополнительных усилий.

Классификация и секторы NOSQL

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

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

nosql sektors

Рис. 1 Секторы NOSQL-хранилищ

Источник

Как объяснить своей бабушке разницу между SQL и NoSQL

image loader

Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (SQL). К ним относятся MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 и многие другие.

За последние 15 лет на рынке появилось много новых баз данных в рамках подхода No-SQL. К ним относятся хранилища ключей-значений, такие как Redis и Amazon DynamoDB, широкие колоночные базы, такие как Cassandra и HBase, хранилища документов, такие как MongoDB и Couchbase, а также графовые базы данных и поисковые системы, такие как Elasticsearch и Solr.

В этой статье мы попробуем разобраться в SQL и NoSQL, не влезая в их функционал.
Кроме того, мы немного повеселимся в процессе.

Объясняем бабушке SQL

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

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

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

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

id name birthday last visit clothing size favorite ice-cream adopted
1 Jimmy L Mint chocolate false
2 Jessica M Rocky road true
…продолжаем список!

Через некоторое время ты во всем разбираешься и мы почти закончили со списком! Однако ты поворачиваешься ко мне и говоришь: «Мы забыли добавить место для супругов, хобби, внуков!» Но нет, мы не забыли! Это следует дальше и требует нового листа бумаги.

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

id grandchild_id name birthday
1 2 John
2 9 Fernanda
…больше супругов!

На этом этапе я объясняю бабушке, что если она хочет знать, кто с кем состоит в браке, то ей нужно только сопоставить id в списке внуков с grandchild_id в списке супругов.

После пары десятков печений мне нужно вздремнуть. «Можешь продолжить, бабуля?» Я ухожу, чтобы вздремнуть.

Я возвращаюсь через несколько часов. А ты крута, бабуля! Все выглядит отлично, за исключением списка хобби. В списке около 1000 хобби. Большинство из них повторяются; что случилось?

grandchild_id hobby
1 biking
4 biking
3 biking
7 running
11 biking
…продолжаем!

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

Общий список внуки хобби

После всей этой работы у бабушки теперь есть крутая система запоминания для слежки за всей ее удивительно большой семьей. А потом — чтобы задержать меня подольше — она задает волшебный вопрос: «Где ты научился все это делать?»

Реляционные базы данных

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

Отличительная черта наиболее популярных реляционных баз данных — язык запросов SQL (Structured Query Language). Благодаря нему, если бабушка перенесет свою систему запоминания в компьютер, она сможет быстро получить ответ на такие вопросы, как: «Кто не посещал меня в прошлом году, женат и не имеет никаких увлечений?»

Одна из наиболее популярных систем управления базами данных SQL это MySQL с открытым исходным кодом. Она реализована в первую очередь как система управления реляционными базами данных (RDBMS) для программных приложений на базе веб-технологий.

Некоторые ключевые особенности MySQL:

Объясняем бабушке NoSQL

Бабушка, у нас огромная семья. В ней 150 внуков! Многие из них женаты, имеют детей, чем-то увлекаются и прочее. В твоем возрасте невозможно помнить все обо всех нас. Что тебе нужно, так это это система запоминания!

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

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

Я: “Кажется все готово!”
Бабушка: “Подожди, а как же остальные внуки?”
Я: “Да, точно. Тогда выделяем по странице на каждого.”
Бабушка: “А мне нужно будет записывать всю ту же самую информация для всех, как я делала для тебя?”
Я: “Нет, только если ты хочешь. Давай покажу.”
Забрав у бабушки ручку, я перелистываю страницу и быстро записываю информацию о моем самом нелюбимом двоюродном брате.

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

Когда все уже сделано, она задает волшебный вопрос: «Где ты научился все это делать?»

Базы данных NoSQL

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

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

Ключевые особенности NoSQL:

Детальное сравнение

MySQL требует определенной и структурированной схемы.
NoSQL позволяет сохранять любые данные в «документе».

MySQL поддерживает огромное сообщество.
У NoSQL есть небольшое и быстро растущее сообщество.

NoSQL отличается простотой масштабирования.
MySQL нуждается в большей управляемости.

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

MySQL использует стандартный язык запросов (SQL).
NoSQL не использует стандартный язык запросов.

MySQL имеет много отличных инструментов отчетности.
В NoSQL есть несколько инструментов отчетности, которые сложно стандартизировать.

MySQL может выдать проблемы с производительностью для больших данных.
NoSQL обеспечивает отличную производительность на больших данных.

Мысли 8base

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

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

Перевод выполнен в компании 8base

8base – это готовый к использованию GraphQL backend-as-a-service, который постепенно превращается в полноценную low code платформу разработки. Наша цель – дать возможность разработчикам, обладающим навыками front-end или мобильной разработки, создавать масштабируемые бизнес-приложения.

Источник

Adblock
detector