SQL и NoSQL разбираемся в основных моделях баз данных


Оглавление (нажмите, чтобы открыть):

Разница между SQL и NoSQL: MySQL и MongoDB

При выборе базы данных предстоит принять важное решение: остановиться на реляционной (SQL) или нереляционной (NoSQL) структуре БД. Оба этих варианта вполне жизнеспособны, но между ними есть различия, которые пользователи должны учитывать при принятии решения. В этой статье мы рассказываем, в чем состоит разница SQL и NoSQL, а также обсуждаем еще две важные вещи: выбрать MySQL или MongoDB.

Основные различия

Представьте себе город (назовем его А), в котором все говорят на одном языке. На нем строятся все бизнес-процессы, этот язык используется во всех формах общения. Словом, жители этого города понимают друг друга и исследуют окружающий мир только посредством этого языка. Если сменить язык в одном месте, все будут сбиты с толку.

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

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

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

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

  • Можно создавать документы, не определяя их структуру заранее;
  • Каждый документ может обладать собственной уникальной структурой;
  • Синтаксис может различаться в разных базах данных;
  • В процессе работы можно добавлять новые поля.

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

В большинстве случаев SQL БД можно масштабировать вертикально, то есть можно проводить увеличение нагрузки на каждом отдельном сервере, повышая мощности ЦП, ОЗУ, твердотельного диска. А вот NoSQL БД можно масштабировать горизонтально. Это значит, что нагрузка распределяется благодаря разделению данных или добавлению большего количества серверов. Это как если бы вы добавляли больше этажей к зданию либо добавляли больше зданий к району. В последнем варианте система может получиться более крупной и мощной. Именно поэтому для крупных или часто меняющихся БД обычно выбирают NoSQL.

Структура

SQL БД имеют форму таблиц, а в NoSQL БД данные представляются в виде документов, пар «ключ-значение», графов или хранилищ wide-column. Из-за этого реляционные (SQL) базы лучше использовать для приложений, в которых нужно переходить между несколькими записями (например, система бухучета), или для систем устаревшего вида, которые при создании имели реляционную структуру.

Примерами SQL БД являются ySQL, Oracle, PostgreSQL и Microsoft SQL Server, а NoSQL БД — MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.

SQL против NoSQL: MySQL либо MongoDB

Раз уж мы разобрались, в чем состоит разница SQL и NoSQL, рассмотрим ключевые различия между ними на примере MySQL и MongoDB.

MySQL: SQL (реляционная) база данных

Ниже представлены сильные стороны MySQL:

  • Сформированность: MySQL — хорошо известная база данных, то есть она обладает крупным коммьюнити, широкими возможностями тестирования и стабильностью;
  • Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у нее есть адаптеры для таких языков, как Node.js, Ruby, C#, C++, Java, Perl, Python и PHP, то есть эта система не ограничена языком запросов SQL;
  • Экономичность: Система является открытой и бесплатной;
  • Воспроизводимость: Базу данных MySQL можно использовать на разных узлах, что позволяет снизить нагрузку и повысить масштабируемость и доступность приложения;
  • Разделение данных: Несмотря на то что эту процедуру можно проводить на не всех SQL БД, серверы MySQL позволяют это сделать. Это не только экономично, но и может быть полезно для приложения.

MongoDB: NoSQL (нереляционная) база данных

Ниже представлены сильные стороны MongoDB:

  • Динамичность: Как говорилось ранее, динамическая схема гарантирует гибкость, позволяющую менять структуру без редактирования существующих данных;
  • Масштабируемость: MongoDB можно масштабировать горизонтально, благодаря чему уменьшается нагрузка для бизнеса;
  • Легкость в управлении: Для этой базы данных не требуется администратор. Так как она достаточно дружелюбна в отношении юзеров, воспользоваться ей могут как разработчики, так и администраторы;
  • Скорость: Эта БД показывает отличные результаты в работе с короткими запросами;
  • Гибкость: В MongoDB можно добавлять новые столбцы и поля, не влияя на уже существующие записи и производительность приложения.

Какую базу данных выбрать для своего проекта?

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

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

Тенденции баз данных в 2020 – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных

Главное меню » Базы данных » Тенденции баз данных в 2020 – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных

SQL против NoSQL

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

Базы данных SQL

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

Базы данных NoSQL

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

В течение десятилетий SQL значительно опережал нереляционные альтернативы, но NoSQL быстро сокращает разрыв с такими популярными базами данных, как MongoDB, Redis и Cassandra. Хотя многие организации предпочитают переходить с устаревших баз данных, таких как Oracle, не все переходят на NoSQL. Исходя из наших выводов, SQL по-прежнему удерживает 60% при растущем спросе на такие системы, как PostgreSQL:

Использование базы данных SQL: 60,48%

Использование базы данных NoSQL: 39,52%

Самые популярные базы данных

Итак, какие базы данных наиболее популярны в 2020 году? Зная, что SQL использовали более 3/5 респондентов, вы можете предположить, что Oracle украл шоу. Угадай еще раз. MySQL доминировал в этом отчете с 38,9% использования, за ним следуют MongoDB с 24,6%, PostgreSQL с 17,4%, Redis с 8,4% и Cassandra с 3,0%. Oracle отставал от этих репортеров баз данных всего на 1,8%, а пользователи CouchDB, Berkeley DB, Microsoft SQL Server, Redshift, Firebase, Elasticsearch и InfluxDB объединили нашу категорию Other на 2,4%.

Хотя эти цифры могут шокировать, нельзя забывать о росте популярности MySQL, MongoDB и PostgreSQL. Итак, как этот опрос сравнивается с наиболее известным источником тенденций системы управления базами данных? Рейтинг DB-Engines – Отчет о популярности Trend ставит этих лидеров в пятерку лидеров, но Oracle по-прежнему занимает первое место, а Microsoft SQL Server – третье.

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

Использование одной базы данных и использование нескольких баз данных

За последние десять лет использование нескольких типов баз данных значительно возросло по сравнению с традиционной стратегией, когда все яйца складываются в одну корзину. Сколько так? Почти половина организаций, с которыми мы говорили, на самом деле используют более одного типа базы данных для своих приложений, чем одну базу данных! 44,3% сообщили, что используют несколько баз данных, а 55,7% работают с одной:

Тенденции баз данных в 2020 году – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных.

SQL и NoSQL несколько комбинаций баз данных

Итак, зная, что почти половина наших респондентов объединяют несколько баз данных для поддержки своих продуктов, какие типы систем управления базами данных они используют вместе? Это меньше шок, 75,6% использования нескольких типов баз данных состоит из комбинации баз данных SQL и NoSQL. Это подтверждает тот случай, что для многих организаций один размер подходит не всем. Хотя у вас может быть предпочтение по сравнению с SQL по сравнению с NoSQL, нельзя отрицать тот факт, что оба они предлагают явные преимущества другого. Вместо того чтобы ограничивать вашу организацию одним типом базы данных, развивайте (или разрабатывайте) свою стратегию данных для совместимости, чтобы эти мощные системы управления базами данных могли дополнять друг друга и заполнять пробелы в ваших потребностях в данных!

Использование базы данных SQL + NoSQL: 75,6%

Использование базы данных SQL + SQL: 14,6%

Использование базы данных NoSQL + NoSQL: 9,8%

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

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

Очевидный победитель с более чем 1/3 использования нескольких типов баз данных – это комбинация MySQL и MongoDB. Хотя MongoDB часто считается альтернативой MySQL, две базы данных хорошо работают вместе при правильном проектировании. Вторым по популярности сочетанием были MySQL и PostgreSQL вместе. Эти две базы данных SQL являются явными конкурентами, но могут совместно использоваться для хранения различных наборов данных. Как вы можете видеть на приведенном выше графике раздела, представление MySQL и PostgreSQL на 9,76% составляет большую часть использования SQL + SQL в нескольких базах данных.

MySQL + MongoDB: 34,15%

MySQL + PostgreSQL: 9,76%

MongoDB + PostgreSQL: 7,32%

MongoDB + Redis: 7,32%

MySQL + MongoDB + PostgreSQL: 4,88%

MySQL + MongoDB + PostgreSQL + Redis: 4,88%

Наиболее трудоемкая задача управления базой данных

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

Мониторинг занял первое место с 12,6% от наших респондентов, едва опередив резервные копии, управляя дисковым пространством, масштабированием и объединением таблиц, которые все заняли второе место с 11,6% каждый. Автономным номером три было поддержание и перераспределение изменений между представлениями и хранимыми программами на уровне 8,7%, и снова связь под номером 4 с 7,2% для каждой очистки и настройки базы данных. Обновления заняли пятое место с 6,5%, а дюжина других задач составила 11,6% в другой категории, включая миграции, запросы, сравнение, настройку и репликацию.

Наиболее важные метрики отслеживаются для производительности базы данных

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

Время ответа на запрос было не только самым отслеживаемым показателем, но и большинством с 51,8% ответов! Мы ожидали, что это приведет к 30,8% из отчета «Задача управления PostgreSQL, который отнимает больше всего времени», который мы составили в октябре 2020 года, но значительно расширился, когда мы расширили этот вопрос до всех систем управления базами данных. Скорость запросов – это чрезвычайно важный показатель, который нужно отслеживать на постоянной основе, чтобы вы могли определить медленные запросы, которые могут повлиять на производительность вашего приложения. Многие администраторы баз данных используют инструмент Slow Query Analyzer для выявления проблемных запросов, просмотра того, с каким запросом он связан, понимания их запросов по временному диапазону и поиска самых популярных запросов, вызывающих нагрузку на чтение в вашей системе, для идентификации тех запросов, которые не проиндексированы.

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

Затем память заняла третье место с 8,2% ответов. Чем больше у вас памяти, тем лучше должна работать ваша база данных. Как понимание, так и мониторинг использования памяти должны занимать важное место в вашем списке, так как нехватка или исчерпание памяти приведет к тому, что ваша база данных будет читать и записывать данные на диск, что значительно медленнее.

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Эволюция NoSQL, основные преимущества перед SQL

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

Проблема масштабируемости SQL была признана интернет-компаниями с огромными растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они придумали свои собственные решения проблемы – такие технологии, как BigTable, DynamoDB и Cassandra.

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

Во-первых, существовали запатентованные (с закрытым исходным кодом) типы баз данных NoSQL, разработанные крупными компаниями для удовлетворения их конкретных потребностей, такие как Bigtable от Google, которая считается первой системой NoSQL, и DynamoDB от Amazon.

Успех этих проприетарных систем положил начало разработке ряда аналогичных систем баз данных с открытым исходным кодом и проприетарных систем, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB, HBase и Redis.

Что отличает NoSQL?

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

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

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

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

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

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

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

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

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

Недостатки NoSQL баз данных

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

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

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

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

NoSQL против реляционных баз данных

Давайте сравним NoSQL с обычной базой данных:

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

NoSQL

NoSQL (англ. not only SQL, не только SQL), в информатике — термин, обозначающий ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемости (англ. scalability) и доступности (англ. availability) за счёт атомарности (англ. atomicity) и согласованности данных (англ. consistency). Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами и, иногда, при обсуждении разговор может идти о разных системах. [Источник 1]

Содержание

История

Этот термин стал использоваться в конце 90-х, но реальный смысл в том виде, как он используется сейчас, приобрел только в середине 2009 года. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII файлы и использовала шелловские скрипты вместо SQL для доступа к данным. Термин “NoSQL” имеет абсолютно стихийное происхождение и не имеет общепризнанного определения или научного учреждения за спиной. Это название скорее характеризует вектор развития ИТ в сторону от реляционных баз данных. Расшифровывается как Not Only SQL, хотя есть сторонники и прямого определения No SQL.

Причины появления

  1. Первый тренд — увеличение объемов хранимых данных. Сегодня хранилища достигли таких невероятных размеров, что даже трудно себе представить. Только за 2009 и 2010 годы в базах было сохранено больше информации, чем за всю предыдущую историю человечества.
  2. Второй тренд — взаимосвязанность данных. Информация перестала быть изолированной. Каждый кусочек знаний как-то связан с данными в других хранилищах информации. Страницы в интернете ссылаются на другие страницы. Тэги связывают помеченную информацию из разных источников. Онтологии устанавливают взаимосвязи между различными терминами, и тд
  3. Третий тренд — использование слабоструктурированной информации. Возьмем простой пример: описание товара в магазине. Если раньше было достаточно 5-6 полей, чтобы описать мужскую сорочку (размер, цвет, материал, фотография товара, …), то теперь количество параметров может доходить до нескольких десятков. Причем, для разных сорочек будет использован разный набор параметров. В таких условиях становится крайне сложно заранее определить структуру таблицы, в которой хранится описание товара.
  4. Четвертый тренд — архитектура. В 80-х годах прошлого века типичная архитектура использовала один большой компьютер (mainframe) и одну базу данных. В 90-х, распространение получила клинт-серверная архитектура. В новом веке активно используются web-сервисы, каждый со своим backend-ом (грубо говоря, со своей базой данных) и другие распределенные решения.

В таких условиях у реляционных баз данных резко падает производительность. И если для большинства web-сайтов производительности еще хватает, то для таких приложений как современные социальные сети или поисковые сервисы, SQL базы данных оказались несостоятельны.

Основные черты

Традиционные реляционные СУБД основаны на принципах ACID:

  1. Atomicity — атомарность
  2. Consistency — согласованность
  3. Isolation — изолированность
  4. Durability — надежность

NoSQL основаны на принципах BASE, данный термин был предложен Эриком Брюером:

  1. Basic Availability — базовая доступность — каждый запрос гарантированно завершается (успешно или безуспешно).
  2. Soft State — гибкое состояние — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных.
  3. Eventual Consistency — согласованность в конечном счёте — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.

Cпособы доступа к данным

  1. RESTful интерфейсы. В рамках данного подхода предполагается, что каждый объект, которым мы можем манипулировать, имеет свой уникальный адрес. Обращаясь по этому адресу, мы можем запрашивать, создавать, редактировать или удалять указанный объект. При этом на сервере не сохраняется никакого состояния, то есть каждый запрос обрабатывается независимо от других запросов.
  2. Отличные от SQL языки запросов: GQL (SQL-подобный язык для Google BigTable), SPARQL (язык запросов Семантического Веба), Gremlin (язык обхода графов), Sones Graph Query Language (язык запросов к Sones Graph)
  3. API запросов: Google BigTable DataStore API, Neo4j Traversal API

Основные типы данных

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

В своей основе оно использует ассоциативные массивы, данные представлены как набор пар ключ-значение. Является наиболее простой моделью, ключи могут сортироваться в лексикографическом порядке, что еще больше повышает производительность. Такие хранилища используются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в системах, спроектированных с прицелом на масштабируемость.
Примеры — Oracle NoSQL Database, Redis, Amazon DynamoDB.

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

Эти СУБД служат для хранения иерархических структур данных. Основной идеей является введение понятия «документ». Хотя все базы данных имеют чем-то отличающиеся определения, все они полагают, что документ хранит и инкапсулирует данные в каких-либо стандартных форматах, например XML или JSON. Каждому документу присваивается свой уникальный ключ, для каждой базы данных такого типа есть свой язык запросов или API для доступа к данным. Обычно в базах данных такого типа присутствует богатая структура документа.
Примеры — CouchDB, Couchbase Server, MarkLogic, MongoDB.

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

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

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

Сильной стороной колоночных баз данных является способность хранить большое количество данных с большим количеством атрибутов. В отличие от РБД, которые хранят данные по строкам, колоночные БД хранят данные в колонках. Колонки хранятся в отдельных файлах. Это способствует улучшенному сжатию за счет информации о типе данных колонки. Также это ускоряет запросы.
Примеры — Apache HBase, Apache Cassandra, Apache Accumulo. [Источник 2]

Методы хранения данных

Есть базы данных, которые вообще никак данные не хранят, у них все содержится в памяти. Соответственно, любая перезагрузка процесса влечет за собой потерю данных. Другие базы данных используют такие методы как snapshot, запись данных в лог и in-place updates.

  • Snapshot – слепок базы данных на текущий момент. Минусом этого способа является необходимость наличия дополнительной памяти. В зависимости от активности, которая происходит на сервере, может понадобиться до двукратного запаса памяти.
  • Запись данных в лог – когда базе данных приходит команда на запись, происходит запись в лог и продолжается работа. Данные, которые попали в лог, не подлежат изменению.
  • In-place updates – база данных имеет свою копию, которая обновляется при каких-либо изменениях в базе данных. Такая модель не безопасна, так как при возможном отключении питания во время обновления копии данные потеряются.

CAP теорема

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

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

На самом деле, выбор только из двух вариантов — либо доступность, либо согласованность, потому что устойчивость к разрывам сети везде есть по умолчанию. Если система называет себя CP (т.е. consistency и partition tolerance), то при разрыве, если мы обращаемся на узел, и узел видит, что он не может надежно обеспечить эту запись, что у него нет, то он просто откажет приложению в этой записи, и она не удастся. Если система называет себя AP, то она будет всеми силами стараться удовлетворить запросы приложения путем отдачи ему устаревших данных. Она может принять себе запрос на запись и куда-то ее себе записать, чтобы потом выполнить на всем кластере. В AP системах есть термин Eventual consistency (Возможная согласованность) — если не было конфликтующих записей, то когда-нибудь позже кластер придет в согласованное состояние. Конфликты можно разрешить по времени, использовать счетчики, использовать тип данных «множество». [Источник 3]

Мастер Йода рекомендует:  До свидания, копипаст Google тестирует в Chrome для Android функцию Copyless Paste

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствие SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сентябрь 29, 2020

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


Определим, что в данной статье речь пойдёт о 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 решений на серьёзном уровне мало кто увлекается — это значит, что многие специфические моменты оператору базы данных придется осваивать “на ходу”.
Мастер Йода рекомендует:  SEO-копирайтинг в вопросах и ответах

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

От SQL к NoSQL и обратно

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

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

Как известно, задача разработки СУБД в ИТ-индустрии изначально не стояла, но были актуальны прикладные задачи, требующие обработки массивов структурированной информации. Постепенно выяснилось, что во многих случаях алгоритмы накопления, поиска и анализа данных одинаковы, а следовательно, их можно сделать универсальными и выделить в виде отдельных инструментальных средств — систем управления базами данных. К прикладному ПО обработки больших объемов информации всегда предъявляются одни и те же требования — скорость работы и стоимость разработки, которые трансформируются в требования к используемой СУБД. Чем гибче и богаче возможности СУБД, тем проще разработчику прикладной системы приспосабливать их для своих нужд, а значит, тем меньше оказывается стоимость создаваемого ПО.

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

За многолетнюю историю развития СУБД было выработано несколько моделей представления структурированной информации: иерархическая, сетевая, реляционная, объектно-реляционная и т. д. Наибольшее распространение получила реляционная модель, предложенная Эдгаром Коддом в 1970 году, которая надолго стала стандартом представления структурированной информации. Причины этого вытекают из сформулированных требований к СУБД. Во-первых, реляционная модель оказалась достаточно простой, с точки зрения прикладного программиста. Во-вторых, она обладает достаточной гибкостью и позволяет представлять информацию из самых разных предметных областей. В-третьих, в рамках этой модели используется мощный и удобный подход к манипулированию данными (реляционная алгебра), впоследствии оформленный в виде языка SQL. В-четвертых, простота и естественность реляционной алгебры позволили создать высокопроизводительные и универсальные алгоритмы выполнения запросов, удовлетворяющие большую часть потребностей разработчиков прикладных систем. Наконец, к сегодняшнему дню создано множество инструментальных средств, ориентированных на обработку реляционных данных, что дает еще одно преимущество реляционных СУБД.

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

Реляционная модель предполагает оперирование только атомарными данными и исключает обработку какой-либо неструктурированной информации, а это приводит к тому, что хранение графических, аудио- или видеоданных становится невозможным. Более того, невозможно даже хранение текстовых документов произвольной длины. Поэтому, первым отступлением от классической реляционной модели в сторону удобства разработки прикладного ПО можно считать введение типа BLOB (Binary Large Object — «бинарные данные большого объема»), который сегодня поддерживается большинством современных СУБД и закреплен в стандартах языка SQL. Каждая СУБД, помимо BLOB, может иметь свои собственные «дополнительные» типы данных, которые обычно требуют введения дополнительных поисковых операций (например, полнотекстовый поиск по BLOB). Это еще дальше уводит от классической реляционной модели.

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

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

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

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

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

Возможна существенная оптимизация рассмотренного примера: скажем, вместо текстового представления слова можно хранить его целочисленный код, а вместо кода документа хранить BLOB, где будут содержаться коды всех документов, имеющих отношение к данному слову. Дальнейшая оптимизация в рамках реляционного подхода невозможна, но ее можно провести посредством так называемого инвертированного индекса. Коды документов сортируются по возрастанию, и в полученном списке вычисляются разницы между кодами соседних документов. Получается последовательность, состоящая из кода первого документа и множества чисел небольшой величины. Она хорошо сжимается алгоритмами энтропийной компрессии (например, алгоритмом Лемпеля — Зива-Велча), в результате чего значительно сокращается объем ввода/вывода, ускоряется загрузка информации с диска и в конечном счете растет скорость полнотекстового поиска.

Задача не для реляционной СУБД

Имеется набор из 10 тыс. датчиков, один раз в секунду отправляющих показатели (вещественные числа). Показатели датчиков стабильны и изменяются плавно. Необходимо в интерактивном режиме анализировать месячные данные и определять, приводит ли резкое изменение одного показателя больше чем на фиксированную пороговую величину к изменению другого показателя больше чем на другую пороговую величину. Желательно использовать обычный ПК, не привлекая специальные решения (RAID-массивы и т. п.).

Если каждый датчик генерирует значение раз в секунду, то за месяц объем данных составит 96 Гбайт, и если использовать РСУБД, то потребуется примерно такой же объем дискового пространства плюс расход на хранение индексов «время -> показания датчиков», количество которых зависит от логической структуры базы. Если потребуется хранить данные за несколько месяцев, то реляционная СУБД уже не подходит.

Показания датчиков можно представить в виде матрицы: строки соответствуют моментам времени, а столбцы — номерам датчиков. Проектирование реляционной базы сводится к представлению этой матрицы в виде реляционных таблиц. Самым простым и логичным с точки зрения реляционного подхода способом организации является использование таблицы с полями «время – код датчика – значение», но это решение неприменимо на практике из-за огромного размера таблицы (2 592 000 секунд x 10 тыс. значений).

Указанную матрицу можно «разворачивать» в реляционные таблицы по горизонтали или по вертикали. В первом случае записи реляционных таблиц будут соответствовать моментам времени, а поля реляционных таблиц — номерам датчиков. Для оценки изменения значения датчика нужно взять запись, соответствующую данному моменту времени, получить запись для следующего момента и вычислить разницу значений в одном и том же поле. Поскольку первичным ключом таблицы является значение времени, то первые два шага будут выполняться достаточно медленно, и даже поиск моментов, когда датчик изменил свои показания больше чем на пороговую величину, на практике работать не будет. Это объясняется тем, что для каждой из 2 592 000 записей нужно будет найти «следующую» из тех же 2 592 000 записей. Если в целях оптимизации таблицы разбить по дням, то каждая из них будет содержать 24 x 60 x 60 = 86 400 записей, и, соответственно, нужно будет делать 30 (количество дней) поисков, каждый из которых будет анализировать 86 400 записей и для каждой искать «следующую» из 86 400 записей.

Если матрицу показаний разворачивать по вертикали, то записи реляционных таблиц будут соответствовать номерам датчиков, а поля — моментам времени. В общей сложности получится совокупность из 2 592 000 полей, разбитых по таблицам. Очевидно, что работать с такой базой очень сложно.

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

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

Основные концепции NoSQL

Важной вехой для высоконагруженных систем стало развитие Интернета, ряд сервисов которого (DNS-серверы, поисковые машины, социальные сети и т.д.) изначально должны обрабатывать большие массивы информации и отвечать на огромное число запросов. Это требует не только максимального учета любой специфики обрабатываемой информации, но и перехода на распределенные вычисления. Никакой сколь угодно мощный сервер в принципе не способен в одиночку обеспечить нужную производительность. В итоге основными принципами NoSQL стали отказ от реляционной модели для учета специфики обрабатываемых данных, а также хорошая горизонтальная масштабируемость до сотен и тысяч серверов для обеспечения скорости работы. Однако это выявило еще одну проблему, сформулированную в виде теоремы CAP (Consistence, Availability, Partition tolerance — «согласованность, доступность, устойчивость к разделению»): в распределенной вычислительной системе невозможно одновременно выполнить требования по согласованности данных, доступности системы и устойчивости к разделению. Под последним требованием понимается то, что система не распадается на несколько изолированных секций, внутри которых выполняются требования по согласованности и доступности.

Нестрогое доказательство теоремы CAP основано на простых рассуждениях. Пусть распределенная система состоит из N серверов, каждый из которых обрабатывает запросы некоторого числа клиентских приложений (рис. 1). При обработке запроса сервер должен гарантировать актуальность информации, содержащейся в отсылаемом ответе на запрос, для чего предварительно нужно выполнить синхронизацию содержимого его собственной базы с другими серверами. Таким образом, серверу необходимо ждать полной синхронизации либо генерировать ответ на основе не синхронизированных данных. Возможен и третий вариант, когда по каким-либо причинам синхронизация производится только с частью серверов системы. В первом случае оказывается не выполненным требование по доступности, во втором — по согласованности, в третьем — по устойчивости к разделению.

Рис. 1. Выполнение запроса к распределенной системе

Иногда распределенные системы классифицируют по видам выполняемых требований CAP: CA — система удовлетворяет требованиям по согласованности и доступности, CP — по согласованности и устойчивости, AP — по доступности и устойчивости. В любом из трех случаев не будет выполнено свойство ACID (Atomicity, Consistency, Isolation, Durability — «атомарность, согласованность, изолированность, долговечность»), обычно строго соблюдаемое в реляционных СУБД, а ему противопоставляется свойство BASE (Basically Available, Soft State, Eventually consistent). При сбое в некоторых узлах системы отказ получает только часть приложений, взаимодействующих с вышедшими из строя узлами. В ходе взаимодействия используются протоколы без состояния, что снижает нагрузку на отдельные узлы и позволяет ее перераспределять. Наконец, допустима временная несогласованность данных в разных узлах системы при условии, что информация будет синхронизирована через некоторый обозримый промежуток времени. BASE используется для наиболее общего описания требований к распределенным NoSQL-системам, подпадающих под утверждение теоремы CAP и не удовлетворяющих требованиям ACID.

Системы NoSQL

Существует множество различных NoSQL-систем обработки данных, в котором можно выделить следующие основные классы: хранение XML-документов, хранение пар «ключ – значение», хранение графов, хранение кортежей произвольной длины, Triple Storages, многомерные данные и т. д.

Хранилища XML-документов (BaseX, eXist) представляют собой средства для работы с большим количеством XML-документов или с документами большого размера. Информация содержится не в текстовом виде, а в некотором внутреннем формате, позволяющем быстро выполнять операции поиска (запросы XPath и XQuery) и изменения документов (XSLT, eXtensible Stylesheet Language Transformations). При загрузке документа проводится его синтаксический анализ, результаты которого помещаются в базу, а при извлечении документа его текст восстанавливается на основе содержимого внутренних структур базы.

Формат XML — не единственный способ текстового представления структурированной информации: по аналогии с XML-хранилищами существуют СУБД (Apache Couch DB и MongoDB) для работы с данными, представленными в виде JSON (Java Script Object Notation ) или BSON (Binary JSON).

Хранение пар «ключ – значение» заключается в реализации двух операций: запись информации по ключу и чтение по ключу — при этом одному ключу может соответствовать сразу несколько значений. Востребованность данной функциональности при построении высоконагруженных систем привела к тому, что появилось целое множество соответствующих СУБД, которые, в зависимости от способа реализации, можно разделить на постоянные (CDB), редко изменяющиеся (Appache Cassandra, membase, MemcacheDB) и часто изменяющиеся (memcached).

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

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

Часть хранилищ пар «ключ – значение» основаны на хэш-таблицах, а часть — на B-деревьях (BerkleyDB и MemcacheDB), что помимо выполнения операции поиска дает возможность упорядочивать ключи по возрастанию или убыванию.

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

Системы хранения графов и Triple Storages ориентированы на работы с семантическими данными, представленными в виде узлов и дуг. Отличительной чертой Triple Storages является то, что они ориентированы на поддержку стандартов SemanticWeb.

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

В 2011 году был сделан первый шаг в направлении стандартизации — анонсирован язык запросов UnQL (Unstructured Query Language) для работы с неструктурированной информацией. Для удобства прикладных разработчиков синтаксис и семантика языка во многом схожи с SQL, что вполне естественно — благодаря поддержке UnQL каждая NoSQL-СУБД может стать гибким, удобным и легко используемым инструментом, и она по-прежнему будет основываться на собственных технических решениях, дающих преимущество в каких-либо условиях эксплуатации.

В качестве примера можно указать систему для хранения пар «ключ – значение». Если все СУБД поддерживают UnQL, то прикладной разработчик может подобрать оптимальную, практически не меняя кода приложения. Например, если необходима организация кэширования, то лучше использовать СУБД, ориентированную на работу в памяти (например, membase). Если необходима работа с редко изменяющимися данными, то имеет смысл выбрать СУБД, предназначенную для работы именно в таких условиях (например, CDB). Если помимо поиска необходима сортировка ключей, то подойдет система, основанная на B-деревьях (например, BerkleyDB).

Что лучше?

Реляционные СУБД не спешат мириться со своими недостатками и поддерживают все новые типы данных, используемые в системах NoSQL. Простейшие примеры такого развития (поддержка типов BLOB и полнотекстового поиска) уже упоминались, а более сложный пример — поддержка XML-документов и XPath-запросов. Эта функциональность ключевая для специализированных СУБД (BaseX, eXist), ориентированных на работу с XML, но она же почти полностью присутствует в некоторых реляционных СУБД (например, в Oracle).

Рис. 2. Движение SQL и NoSQL

Таким образом, SQL и NoSQL движутся навстречу друг другу, а со временем могут слиться в единый подход SQL+NoSQL к разработке СУБД (рис. 2). Возникает вопрос: что лучше использовать — NoSQL или SQL? Широко распространенная и хорошо изученная реляционная СУБД дает массу дополнительных преимуществ: интеграция с уже существующими решениями на базе реляционных СУБД, отказоустойчивость, наличие более богатого инструментария и т. д. Сейчас наблюдается тенденция применения NoSQL вместо SQL, но не исключено, что по мере развития SQL начнется обратное движение. Со временем, чем ближе будут становиться SQL и NoSQL, тем больше будет «метаний» от одного подхода к другому.

Мастер Йода рекомендует:  Каким был ваш любимый пет-проект Поделитесь в комментариях

При объединении SQL и NoSQL в единое решение из-за многообразия используемых методов хранения информации СУБД может превратиться в огромный черный ящик со сложными и разветвленными настройками, что сильно затруднит работу с ней. Похожая ситуация уже происходила с некоторыми языками программирования (например, Алгол-68, PL/1), когда их семантика оказалась сильно перегружена и вместо удобного инструмента разработчики получили плохо управляемого «монстра». Кроме того, если будет разработан стандарт на системы SQL+NoSQL, то он может оказаться слишком сложным и перегруженным.

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

Современные реляционные СУБД включают в себя все необходимые подсистемы управления данными (накопление, контроль целостности, кэширование, оптимизация и выполнение запросов, репликация и т. д.). После слияния SQL с NoSQL новые СУБД будут предоставлять только «низкоуровневые» модули работы с данными, а все остальное (например, распараллеливание сложных запросов или стратегия кэширования) программист должен либо настроить самостоятельно, либо использовать типовую конфигурацию. В результате для каждого применения будет создаваться целевая СУБД. Уже сейчас для многих практических задач (полнотекстовый поиск, хранение словарей) гораздо эффективнее реализовать собственное узкоспециализированное решение вместо использования СУБД.

NoSQL в работе

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

Каждый датчик изменяет свое значение плавно, и последовательность его показаний имеет смысл хранить по аналогии с инвертированными индексами в поисковых системах. Так, история показаний разбивается на дни, а для каждого дня хранится начальное показание датчика и последовательность дельт. В итоге за один день будет накапливаться 24 x 60 x 60 = 86 400 чисел, но 86 399 из них окажутся близки к нулю (так как датчик меняет значения плавно) и будут очень хорошо сжиматься. Если сжатие будет 10-кратным, то для хранения показаний одного датчика за один день понадобится 24 x 60 x 60 = 86 400 чисел, что потребует примерно 350 Мбайт без сжатия и 35 Мбайт со сжатием. Соответственно, вся база будет занимать около 10 Гбайт, при этом ее можно разбить на файлы, содержащие показания набора датчиков за некоторый промежуток времени. Это позволяет подобрать оптимальные параметры разбиения базы на файлы и добиться чтения информации в интерактивном режиме.

Для ускорения скорости анализа нужно хранить дополнительную битовую матрицу, строки которой соответствуют датчикам, а столбцы — моментам времени. Элемент матрицы равен 1, если в данный момент времени данный датчик меняет свое значение больше чем на указанную фиксированную пороговую величину. Суммарно вся матрица будет состоять из 2 592 000 x 10 000 ячеек, что потребует 3 Гбайт памяти, но поскольку датчики меняют свое значение плавно и редко, то матрица будет сильно разреженной и при сжатии займет не более 300 Мбайт.

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

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

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

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

Логическим завершением подхода построения целевых СУБД вместо использования классических серверных архитектур является движение в сторону RAD (Rapid Application Development), при котором программист формально описывает качественные и количественные требования к создаваемой СУБД, получает предварительное решение, а затем оптимизирует его отдельные элементы вплоть до самостоятельной реализации отдельных блоков. Созданная таким образом целевая СУБД может быть впоследствии развернута на любой инфраструктуре, включая и облака.

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

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

Константин Селезнев (skostik@relex.ru) — старший инженер-программист НПП «РЕЛЭКС» (Воронеж).

Поделитесь материалом с коллегами и друзьями

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

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

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

Движение NOSQL

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

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

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

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

Но объем — это не единственная проблема, с которой сталкива­ются современные веб-системы. Помимо своего большого объема, со­временные данные обычно очень быстро изменяются. Скорость — это темп изменения данных с течением времени.

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

Существует еще один аспект скорости — скорость изменения струк­туры данных. Другими словами, вдобавок к изменению значений определенных свойств может меняться общая структура элементов, определяющих эти свойства. Это обычно происходит по двум при­чинам. Первой является динамизм прикладной области. При изме­нениях в прикладной области меняются и потребности в данных. Во- вторых, сбор данных часто является экспериментальным процессом. Некоторые свойства создаются «на всякий случай», другие добав­ляются позднее в связи с изменением требований. Те, что оказались нужными, остаются, прочие выбрасываются. Оба этих аспекта в реля­ционном мире вызывают проблемы, поскольку большой объем запи­си привносит высокие расходы обработки, а высокая изменчивость схем сопровождается высокими эксплуатационными затратами.

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

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

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

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

  • атомарность (Atomic) — все операции в транзакции либо успеш­ны, либо для всех них выполняется откат;
  • согласованность (Consistent) — по окончании транзакции база данных является структурно согласованной;
  • изолированность (Isolated) — транзакции не мешают друг другу. Спорные ситуации разрешаются базой данных так, что транзакции выполняются последовательно;
  • долговечность (Durable) — результаты применения транзакции не должны теряться, даже при сбоях.

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

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

  • обычно доступно (Basicavailability) — хранилище доступно большую часть времени;
  • гибкое состояние (Soft-state) — хранилища не обязаны соблю­дать очередность записей, и разные реплики не должны посто­янно согласовываться;
  • отложенная согласованность (Eventualconsistency) — храни­лища достигают согласованности с некоторой задержкой по времени (например, позже, во время чтения).

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

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

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

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

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

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

Понимание 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.

Учебные материалы

Spring data и поддержка NoSQL

Ниже приведены ссылки на Spring NoSQL проекты:

Каждый из этих проектов предоставляет упрощенный API для взаимодействия с соответствующим хранилищем. Они также используют Spring Data Commons для возможности написания базовых методов, таких как save(), delete(), update() и findXxxYyyZzz(), с автоматической генерацией запросов.

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

Реляционные СУБД – сравнение MySQL и SQL сервер

Вступление

База данных играет важную роль для каждого современного веб-приложения. Благодаря динамической природе веб-приложений сейчас, даже простейшие приложения требуют некоторых механизмов хранения, доступа и изменения данных (вот почему в Hostinger мы предлагаем неограниченные Базы данных MySQL для наших клиентов с премиум и бизнес аккаунтами). Естественно, поскольку важность баз данных стремительно растёт, реляционные системы управления базами данных или реляционные СУБД набирают свою популярность (Relational Database Management Systems – RDBMS)

Две из них MySQL и SQL Server. Обе выполняют одинаковую функцию, хотя имею различные варианты использования. Они различаются некоторыми особенностями, но обе системы базируются на SQL или Structured Query Language (структурированный язык запросов). В связи с этим, разработчики могут обнаружить несколько схожестей между MySQL и SQL сервер, таких как использование таблиц для сохранения данных, ссылки на первичные и внешние ключи, также как несколько баз данных в одной среде или на одном сервере.

Не будет ошибкой сказать, что MySQL и SQL сервер – это две наиболее популярные реляционные СУБД среди существующих, хотя Oracle и Postgres найдётся, что сказать по этому поводу. Не смотря на то, что мы постепенно становимся свидетелями перехода с SQL на NoSQL, первые всё же продолжают доминировать. Это означает, что сейчас всё ещё актуально изучить как MySQL, так и SQL сервер.

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

MySQL и SQL сервер – сравнение

Что такое MySQL?

Разработанная в середине 90х (позже приобретённая Oracle), MySQL была одной из первый баз данных с открытым исходным кодом и остаётся таковой и до сегодня. Это значит, что существует несколько альтернатив MySQL. Но различия между этими вариантами не слишком явные; синтаксис и основная функциональность остаётся одинаковой.

А что является отличительной чертой MySQL, так это её популярность среди стартап-сообществ. Открытый код и бесплатность даёт возможность разработчикам легко начать с MySQL и изменять свой код, когда понадобится. MySQL обычно используется вместе с PHP(англ.) и Веб-сервером Apache, в дистрибутивах Linux, что и привело к известной аббревиатуре LAMP (Linux, Apache, MySQL, PHP).

Что такое SQL сервер?

SQL сервер также известен, как Microsoft SQL Сервер, появился значительно раньше, чем MySQL. Microsoft разработал SQL сервер в 80х, с обещанием разработать надёжную и расширяемую реляционную СУБД. Они остаются ядром качества SQL сервера по прошествии всех этих лет, и предоставляют незаменимое решение для крупномасштабного корпоративного программного обеспечения.

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

Ключевые различия между MySQL и SQL сервером

Теперь, после краткого знакомства с системами, давайте посмотрим на несколько ключевых различий между MySQL и SQL сервером:

  • Среда
    Как упоминалось ранее, SQL сервер лучше работает с .NET, в то время как MySQL может был использован с практически любыми другими языками, наиболее распространённая связка с PHP. Не лишним будет также сказать, что SQL сервер может быть запущен только лиш под ОС Windows, но за последние годы это условие изменилось, когда Microsoft анонсировала поддержку Linux для SQL сервера. Версия для Linux всё ещё зреет и имеет незавершённых вид, что значит мы рекомендуем вам использовать ОС Windows при работе с SQL сервером и переключатся на Linux, если работаете с СУБД MySQL.
  • Синтаксис
    Для большинства людей это наиболее важное различие в этих двух системах. Знакомство с одним набором правил синтаксиса может значительно повлиять на ваше решение относительно того, какая система подходит вам больше. Хотя MySQL и SQL сервер базируются на SQL, различия синтаксиса всё же ощутимы и заслуживают внимания. Например, давайте посмотрим на этот фрагмент:

MySQL

Microsoft SQL Server

Обе цепочки кода достигают одного и того же результата – возвращают 3 записи со значением самого молодого возраста из таблицы имён людей. Но синтаксис сильно отличается. Конечно, синтаксис – это субъективный параметр оценки, поэтому мы не может тут давать рекомендацию; выбирайте то, что кажется вам более интуитивно понятным. Полный список описательных различий между MySQL и SQL сервером можно найти здесь (англ.).

  • SQL сервер больше, чем реляционная СУБД
    Главное преимущество платного ПО в сравнении с бесплатным – это особая поддержка, которую вы получаете. В данном случае, преимущество ещё более значимое, так как SQL сервер поддерживается одной из самых больших компаний в мире. Microsoft создало дополнительный инструменты для SQL сервера, которые привязываются к реляционной СУБД, включая инструменты для анализа данных. Система также имеет сервер отчётов – Служба отчётов SQL Сервера, равно как и инструмент ETL. Это делает SQL сервер швейцарским армейский ножом среди реляционных СУБД. Вы можете получить подобные функции и в MySQL, но вам придётся искать в интернете сторонние решения – что многим не подойдёт.
  • Система хранения данных
    Другим большим различием между MySQL и SQL сервером, которое иногда упускают, это система хранения данных. SQL сервер использует единую систему, разработанную Microsoft, в сравнении с множеством движков, предлагаемых MySQL. Это даёт разработчикам, использующим MySQL больше гибкости, поскольку они могут выбирать разные системы для разных таблиц, основываясь на скорости, надёжности или каких-то других параметрах. Популярный движок MySQL – это InnoDB, который немного теряет в скорости, но обеспечивает усиленную надёжность. Другой известный – MyISAM.
  • Отмена запроса
    Немногие это знают, но кардинальным различием между MySQL и SQL сервером является то, что MySQL не позволяет вам отменить запрос в середине его выполнения. Это значит, что, как только команда запущена на выполнение, вам лучше надеяться, что любой ущерб, который она может сделать, является обратимым. SQL сервер, с другой стороны, позволяет вам отменить запрос на пол пути его выполнения. Это различие может быть несущественным для администраторов, так как они обычно выполняют скрипты команд, и это редко требует отмены во время их выполнения, чего не всегда скажешь о разработчиках.
  • Безопасность
    Очевидно не требуется тщательного рассмотрения вопроса, когда идёт речь о сравнении различий в безопасности в MySQL с SQL сервера. Обе системы совместимы с EC2, что означает вы в безопасности, выбирая любую из двух. Нужно отметить, что величие Microsoft сказалось и здесь наличием в SQL сервере собственной, ультрасовременной системы безопасности. Выделенный инструмент безопасности – анализатор Microsoft Baseline Security Analyzer (MBSA) – гарантирует надёжную защиту для SQL сервера. Поэтому, если безопасность имеет ключевое значение для вас, выбор очевиден.
  • Стоимость
    Здесь SQL сервер становится гораздо менее привлекательным, и MySQL зарабатывает большие очки. Microsoft требует, чтобы вы покупали лицензии для запуска нескольких баз данных на SQL сервер, есть бесплатная версия, но она предназначена только для ознакомления с реляционной СУБД. Напротив, MySQL использует лицензию GNU, что делает её полностью свободной. Однако, если вам нужна поддержка или помощь для MySQL, вам нужно будет заплатить за нее.
  • Поддержка сообщества
    Что переносит нас к следующей точке. За поддержка MySQL вам вряд ли придётся платить, за исключением, быть может, редких случаев, благодаря вкладу большого сообщества в его поддержку. Преимущество огромного сообщества в том, что большинству людей не нужно обращаться за специальной помощью – можно просто искать в Интернете и находить массу решений.
  • IDE
    Важно отметить, что обе реляционные СУБД поддерживаются различными интегрированными средами разработки ( >Заключение

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

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

В конечном счёте, выбор за вами. Как правило, если вы разрабатываете приложения среднего и малого размера и преимущественно используете PHP, переходите к MySQL. Принимая во внимание, что если вы заинтересованы в создании крупномасштабных, безопасных, устойчивых корпоративных приложений, SQL сервер может вам подойти куда больше.

Добавить комментарий