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


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

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

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

В данной статье речь пойдёт о популярных СУБД NoSQL, их функциях и целях.

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

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

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

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

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

Термин NoSQL появился более десяти лет назад как название для ещё одной реляционной БД. Однако эта БД основана на другой идее: она отказывается от использования стандартизированного SQL. В последующие годы появляются и другие подобные базы данных, и в результате они объединились под названием «нереляционные базы данных», или NoSQL.

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

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

  • Хранилище «ключ-значение» (Redis, MemcacheDB и т.п.).
  • Хранилище колонок (Cassandra, HBase).
  • Документо-ориентированные СУБД (MongoDB, Couchbase).
  • Графовые СУБД (OrientDB, Neo4J).

Рассмотрим эти модели подробнее

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

Такие СУБД можно считать самой базовой реализацией NoSQL.

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

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

Хранилища колонок

Эти хранилища основаны на подходе «ключ-значение», но расширяют и усложняют его.

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

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

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

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

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

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

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

Графовые СУБД

Графовые базы данных представляют данные совсем иначе, чем предыдущие три модели. Они используют древовидные структуры – графы, которые состоят из узлов и рёбер.

Графовые СУБД соединяют и группируют полученные данные, благодаря чему они намного быстрее справляются с некоторыми операциями.

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

Базы данных NoSQL на основе модели «ключ-значение»

Самыми популярными приложениями данной категории являются:

  • Redis (открытое сетевое хранилище данных).
  • Riak (открытая распределённая система управления базами данных).
  • Memcached / MemcacheDB (распределённая СУБД).
  • Кэширование: быстрое сохранение данных для их дальнейшего использования.
  • Создание очередей: многие хранилища типа «ключ-значение» (например, Redis) поддерживают списки, наборы, очереди и многое другое.
  • Распределение задач и данных: такие СУБД можно использовать для реализации Pub/Sub.

Базы данных NoSQL на основе хранилищ колонок

  • Cassandra: BigTable-подобная база данных, основанная на DynamoDB.
  • HBase: BigTable-подобное хранилище данных для Apache Hadoop.
  • Хранение неструктурированной информации: такие СУБД отлично подходят для длительного хранения больших коллекций атрибутов и значений.
  • Масштабирование: СУБД на основе хранилищ колонок легко масштабировать.

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

  • Couchbase: Memcached-совместимая документо-ориентированная база данных на основе JSON.
  • CouchDB: инновационное документо-ориентированное хранилище данных.
  • MongoDB: широко распространённая и многофункциональная БД.
  • Уплотнение информации: вы можете создавать очень сложные структуры данных.
  • Совместимость с JavaScript и JSON: одна из наиболее важных функциональных возможностей таких СУБД.

Графовые СУБД

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

Реляционные СУБД vs. NoSQL

Чтобы подвести итоги данной статьи, сравним реляционные и NoSQL СУБД.

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

Эволюция 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 с обычной базой данных:

NoSQL подход в хранении данных

February 21, 2020 Jazz Team Технические статьи , 0


В данной статье описан иной, отличающийся от классического RDBMS, подход хранения данных — NoSQL. Описаны их общие отличительные характеристики — ACID, BASE, детали и требования к каждому типу базы данных (БД). Раскрываются типы NoSQL баз, приводятся примеры (реализации) каждого из типов и области их применения. Анализируется несколько видов модели: “один ко многим”, “многие к одному”, — и происходит обоснование для какой модели лучше применять RDBMS или NoSQL решение.

Сравнение NoSQL и RDBMS подхода

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

Основные причины внедрения баз данных NoSQL:

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

Не смотря на обилие реализаций NoSQL, основные отличия от классических RDBMS решений таковы:

Виды NoSQL решений

В зависимости от модели данных, подходов к распределенности репликации, можно выделить несколько типов хранилищ:

  • БД на основе пар “ключ-значение”. Это тип NoSQL базы, в которой данные хранятся как совокупность пар “ключ-значение”. Ключ является уникальным идентификатором. Ключи и значения могут представлять собой любую простую, сложную составную или байтовую информацию (изображения). Этот тип БД имеет большие возможности для горизонтального масштабирования. Примеры БД — DynamoDB, Cassandra, Redis, Riak.
  • Документоориентированная БД. Этот тип БД предназначен для хранения иерархических структур данных в виде документов, которые легко поддаются чтению человеком (например, JSON). В документной базе нет четкого регламента на схемы документов — документы могут иметь одинаковую или разную структуру. Примеры БД — CouchDB, Couchbase, MongoDB.
  • Графовые БД. Эти БД применяются для тех задач, где необходимо хранить и отслеживать взаимосвязи. В графовых БД основными элементами являются узлы и связи (ребра). Узлы используются для хранения сущностей, а ребра — для хранения взаимосвязей между сущностями. Работа с БД представляет собой обход определённых типов ребер или всего графа целиком, что происходит очень быстро по причине хранения этой информации в ребрах. Пример использования — соц. сети, сервисы выявления фрода. Примеры графовых БД — Neo4j, Neptune, AllegroGraph.
  • Поисковые БД. Эти БД используют индексы для классификации общих характеристик для поступающих данных и основная цель этих БД — содействовать быстрому поиску. Поисковые БД оптимизированы для работы (поиска) с информацией, которая может быть велика и быть плохо структурирована. Обычно эти БД предоставляют методы для простого поиска по тексту, по регулярным выражениям и определенную обработку результатов поиска. Примеры БД — Elasticsearch, Splunk.

Проблема выбора: RDBMS или NoSQL. Что выбрать?

Проиллюстрируем возможность выражать некий объект, например, “резюме” — на языке реляционной схемы.

Профиль в целом определяется уникальным идентификатором user_id. Такие поля, как first_name и last_name, встречаются ровно один раз для одного пользователя, так что их можно сделать столбцами в таблице users.

Однако у большинства людей за время карьеры бывает больше одной работы (должности), а также могут меняться периоды обучения и число элементов контактной информации. Между пользователем и этими элементами существует связь “один-ко-многим”. В SQL-модели, в случае наиболее распространенного нормализованного представления “должности”, “образование” и “контактная информация” помещаются в отдельные таблицы со ссылкой на таблицу users в виде внешнего ключа, как показано на (см. Рисунок 1. Представление профиля).

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

Пример 1. Представление профиля в виде JSON документа:

Преимущество данного формата в том, что он намного проще, чем XML, и удобно читаем для человека. Эту модель данных поддерживают документоориентированные БД, такие как Couchbase. У JSON-представления лучшая локальность, чем у многотабличной схемы (см. Рисунок 1. Представление профиля).

Для извлечения профиля в реляционном примере необходимо выполнить несколько запросов (по запросу к каждой таблице по user_id) или запутанное многостороннее соединение (Join) таблицы users с подчиненными ей таблицами.

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

Рисунок 1. Представление профиля

На (см. Рисунок 1. Представление профиля) поля region_id и industry_id представляют собой ссылки на внешние таблицы (foreign key), а не текстовые строки вроде “Seattle Area” или “Philanthropy”.
Сделано это по нескольким причинам:

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

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

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

Заключение

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

  • Скорость. NoSQL базы данных обычно быстрее, а иногда намного быстрее, когда дело доходит до записи. Операции чтения также могут быть довольно быстрыми в зависимости от того, какую именно БД вы используете.
  • Требуется хранить большие объемы неструктурированных данных.
    Безсхемная разработка. Реляционные СУБД требуют четко описанную структуру данных до начала работы. NoSQL решения предлагают более гибкие решения.
  • Автоматизированная (или очень простая) репликация/масштабирование. NoSQL базы данных быстро развиваются — разработчики активно решают основные проблемы, одна из которых — репликация и масштабирование. В отличии от реляционных СУБД, NoSQL решения легко масштабируются и работают с кластерами.
  • Наличие лишь связей one-to-one и one-to-many между сущностями.
  • Экономия на подписке и поддержке, так как большинство NoSQL БД являются open source проектами.

NoSQL, базы данных: обзор, примеры и сферы применения

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

Собственные проприетарные типы – это новая методология разработки нереляционных баз данных NoSQL, выполненная крупными компаниями для удовлетворения корпоративных нужд, такими, например, как BigTable от Google, который считается первой системой NoSQL, и Amazon DynamoDB. Успех этих систем положил начало разработке ряда похожих систем БД с открытым исходным кодом и проприетарных БД, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB,

Эволюция NoSQL

Проблема масштабируемости SQL была признана компаниями Web 2.0 с огромными, растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они нашли собственные решения проблем, внедрив технологии BigTable, DynamoDB и Cassandra. Растущий интерес привел к появлению ряда систем управления базами данных NoSQL (СУБД) с акцентом на производительность, надежность и согласованность. Ряд существующих структур индексации были повторно использованы и улучшены с целью повышения производительности поиска и чтения.

Термин был придуман Калором Строцци еще в 1998 году, а воскрешен в 2009 году сотрудником Rackspace Эриком Эвансом для решения проблем веб-компаний с большим объемом операций и информации.

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

Таким образом NoSQL не имеют фиксированной структуры таблиц, как в реляционной системе. В этой таблице приведено краткое сравнение возможностей NoSQL и SQL.

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

Типы информационных хранилищ

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

Все, что нужно для работы с предметами, хранящимися в базе данных — это ключ. Данные хранятся в виде строки JSON или BLOB (большой двоичный объект). Одним из самых больших недостатков этой формы является отсутствие согласованности на уровне БД. Это может быть добавлено во время разработки базы данных NoSQL программистами со своим собственным кодом, но это также требует больше усилий, из-за сложности реализации и времени. Самая известная БД NoSQL, построенная на хранилище значений ключей — это Amazon DynamoDB.

Хранилища документов (Document) аналогичны хранилищам значений ключей в том, что они не содержат схемы и основаны на модели значений. Следовательно, оба типа имеют одинаковые преимущества и недостатки. И той, и другой не хватает согласованности на уровне базы данных, что не позволяет приложениям предоставлять больше надежных функций. Тем не менее существуют некоторые ключевое различие между ними. В хранилищах документов значения (документы) обеспечивают кодировку для хранимых данных. Такими кодировками могут быть XML, JSON или BSON (двоичный код JSON). Самым популярным приложением БД, использующим хранилище документов, является MongoDB.

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

Хранилища столбцов имеют быстрый доступ для чтения/записи к сохраненным данным. В нем столбцы строки соответствую одному столбцу и хранятся, как одна запись на диске. Это обеспечивает более быстрый доступ во время операций чтения/записи. Наиболее популярные базы данных, которые используют хранилище столбцов баз данных NoSQL, примеры: Google BigTable, HBase и Cassandra.

В БД NoSQL Graph Bd для представления данных используется структура ориентированного графа. Граф состоит из ребер и узлов.

Принцип работы БД

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

  1. Горизонтальной масштабируемости с возможностью увеличения своего размера, увеличения пространства хранения в БД без ущерба для работы.
  2. Облачной технологии. Большинство БД NoSQL базируют свое хранилище в облаке, чтобы освободить больше места. Кроме того, у них есть узлы для репликации информации.
  3. Эффективного использования ресурсов. Компании в настоящее время находятся в процессе технологического перехода, поэтому практически необходимо, чтобы у них была БД, позволяющая им внедрять новые технологические инструменты. Данные NoSQL работают именно для этого — гибкая модель позволяет быстро адаптироваться к новым инструментам.
  4. Свободной схемы функционирования. NoSQL не имеют жесткой системы, поэтому у программистов есть свобода изменять данные по необходимости. Это означает, что если требуется изменить определение поля или типа данных, то в этом нет проблем в отличие от баз SQL, где изменения подобного рода связаны с большими сложностями.
  5. Скоростью отклика. Скорость в БД измеряется задержкой, которая является временем отклика, NoSQL озабочены максимально возможным уменьшением времени задержки.
  6. Использование индексов. SQL и NoSQL нуждаются в индексах, поскольку запросы не могут быть сделаны в миллионах записей, если индекс не был настроен. В NoSQL индексы генерируются в форме B-Tree, то есть узлы сбалансированы, а значит увеличивается скорость поиска.

Системы управления

В следующей таблице приведено краткое сравнение между различными системами управления БД NoSQL.

MongoDB имеет гибкое хранилище схем — это означает, что хранимые объекты не обязательно должны иметь одинаковую структуру или поля. Он также имеет некоторые функции оптимизации, которые распределяют коллекции данных между собой, что приводит к общему улучшению производительности и более сбалансированной системе. Другие системы NoSQL, такие, как Apache CouchDB, также являются БД типа хранилища документов и имеют много общих возможностей с MongoDB, за исключением того, что к БД можно получить доступ с помощью API RESTful.

REST — это архитектурный стиль, состоящий из скоординированного набора архитектурных ограничений, применяемых к компонентам, соединителям и элементам данных в интернете. Он основан на кешируемом коммуникационном протоколе «клиент — сервер» без сохранения состояния, например, HTTP-протокол. Приложения RESTful используют HTTP-запросы для публикации, чтения и удаления данных. Что касается баз данных столбцов, Hypertable — это БД NoSQL, написанная на C ++ и основанная на Google BigTable. Hypertable поддерживает распределение хранилищ данных по узлам для обеспечения максимальной масштабируемости, как MongoDB и CouchDB.

Гибридная система Cassandra

Одна из наиболее широко используемых БД NoSQL — Cassandra, разработанная Facebook. Целью Cassandra было создание СУБД, которая не имеет единой точки отказа и обеспечивает максимальную доступность. Cassandra — это, главным образом, БД хранилища столбцов. В некоторых исследованиях она упоминалась как гибридная система, основанная на Google BigTable, которой является БД хранилища столбцов и Amazon DynamoDB, присущая типу «ключ-значение». Ключи в Cassandra указывают на набор семейств столбцов с опорой на распределенную файловую систему Google BigTable и функции доступности Dynamo (распределенная хеш-таблица).

Основные характеристики Cassandra включают в себя:

  1. Отсутствие единой точки отказа. Для этого она должна работать на кластере узлов, а не на одной машине. Это не означает, что данные на каждом кластере одинаковы. Когда происходит сбой в одном из узлов, данные на нем будут недоступны. Однако другие узлы и данные по-прежнему будут доступны.
  2. Распределенное хеширование — это схема, которая обеспечивает функциональность хэш-таблицы таким образом, что добавление или удаление одного слота не приводит к значительному изменению отображения ключей на слоты. Это позволяет распределять нагрузку на серверы или узлы в соответствии с их емкостью и минимизировать время простоя.
  3. Относительно простой в использовании клиентский интерфейс. Она использует Apache Thrift для своего клиентского интерфейса, который предоставляет RPC-клиент на нескольких языках, но большинство разработчиков предпочитают альтернативы с открытым исходным кодом, созданные на основе Apple Thrift, например, Hector.
  4. Репликация данных. По сути, он отражает данные для других узлов в кластере. Репликация может быть случайной или определенной для максимальной защиты данных, например, путем размещения в узле другого центра обработки данных.
  5. Политика разделения решает, где и на каком узле разместить ключ. Это может быть случайным или упорядоченным процессом. При использовании обоих типов политик разделения Cassandra может найти баланс между нагрузкой и оптимизацией производительности запросов.
  6. Согласованность. Репликация усложняет согласованность. Это связано с тем, что все узлы должны быть обновлены в любой момент времени с самыми последними значениями или во время запуска операции чтения.
  7. Чтение/запись действий. Клиент отправляет запрос одному узлу. Узел, согласно политики репликации, сохраняет данные в кластере. Каждый узел сначала изменяет данные в журнале фиксации и обновляет структуру таблицы, причем оба изменения выполняются синхронно. Запрос на чтение отправляется одному единственному узлу, который содержит данные в соответствии с политикой разделения/размещения.

Структуры индексации

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

Одно из основных отличий от других древовидных структур, таких как AVL, заключается в том, что B-Tree позволяет иметь переменное количество дочерних узлов, что означает меньшую балансировку дерева, но большую потерю пространства. B + Tree — один из самых популярных вариантов B-деревьев. Это улучшение (в отличие от B-Tree) требует, чтобы все ключи находились в листьях.

Структура данных T-Trees была разработана путем объединения функций AVL-Trees и B-Trees. Деревья AVL относятся к типу самобалансирующихся деревьев двоичного поиска, тогда как деревья B — несбалансированы, а у каждого узла может быть разное количество дочерних элементов.

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

T-дерево имеет три типа узлов: с правым и левым дочерним узлом, конечный узел без дочерних узлов и узел с половинным листом только с одним дочерним узлом. Считается, что у T-Trees лучшая общая производительность.

Распространенные ошибки применения БД

Существуют три распространенные ошибки, которые совершают организации, когда дело доходит до NoSQL:

  1. NoSQL — это больше, чем масштабируемость, нельзя приравнивать NoSQL к веб-шкале. Прародителями современных нереляционных баз данных были такие компании, как Google и Amazon, которые сосредоточились на том, чтобы решать проблемы масштабируемости в веб-среде.
  2. Разработчики должны развиваться. В одном высококлассном веб-проекте плохо отобранная команда по интеграции создала огромную проблему, и чтобы устранить ее, потребовались время и миллионы долларов.
  3. Усложненное распространение. Ничто не заменит знания и опыт ни в реализации, ни в процессе администрирования. Случается так, что запрос, который быстро выполняется на локальной машине разработки, не будет масштабироваться горизонтально на сотнях машин. Современное приложение имеет распределенную архитектуру и множество пользователей одновременно, которые требуют быстрых ответов.
Мастер Йода рекомендует:  10 способов учиться намного быстрее и эффективнее

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

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

  1. Имеют простую и гибкую структуру.
  2. Не имеет схем.
  3. Основана на парах «ключ-значение».
  4. Некоторые типы включают хранилище столбцов, документов, значений ключей, графиков, объектов, XML и другие режимы данных.
  5. Обычно каждое значение в БД имеет ключ. Некоторые хранилища позволяют разработчикам хранить сериализованные объекты, а не только простые строковые значения.
  6. NoSQL с открытым исходным кодом не требуют дорогостоящих лицензионных сборов и могут работать на недорогом оборудовании, что делает их развертывание рентабельным.
  7. При работе с NoSQL, независимо от того, являются ли они открытыми или проприетарными, расширение проще и дешевле, чем при работе с реляционными базами данных. Оно выполняется путем горизонтального масштабирования и распределения нагрузки по всем узлам, а не по типу вертикального масштабирования, который обычно выполняется в системах реляционных баз данных и заменяет основной хост более мощным.

Недостатки No-системы

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


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

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

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

Академические работники, инженеры, архитекторы программного обеспечения, дизайнеры приложений и программисты требуют более глубокого знания структур данных, которые ранее не требовались для реляционных баз данных. Лидерами рынка являются — Hadoop и MongoDB, вслед за «Кассандрой», «Редисом», CouchDB и «Риаком». Современные исследования показывают, что есть два продукта NOSQL, которые доминируют над системными инженерами, архитекторами программного обеспечения, разработчиками среди десятка аналогичных технологий – это MongoDB и Hadoop.

Рынок показывает, что крупные компании используют новые методологии разработки баз данных NoSQL и интегрируют их в свои продукты (Oracle, IBM). Рынок БД понемногу превращается в стандарт PasS, Redis и MongoDB, Edlich. Такие продукты, как Neo4j, MongoDb и CouchDb, стали объектом поддержки и инвестирования венчурного капитала.

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

Нереляционные данные и базы данных NoSQL Non-relational data and NoSQL

Нереляционная база данных — это база данных, в которой в отличие от большинства традиционных систем баз данных не используется табличная схема строк и столбцов. A non-relational database is a database that does not use the tabular schema of rows and columns found in most traditional database systems. В этих базах данных применяется модель хранения, оптимизированная под конкретные требования типа хранимых данных. Instead, non-relational databases use a storage model that is optimized for the specific requirements of the type of data being stored. Например, данные могут храниться как простые пары «ключ — значение», документы JSON или граф, состоящий из ребер и вершин. For example, data may be stored as simple key/value pairs, as JSON documents, or as a graph consisting of edges and vertices.

Все эти хранилища данных не используют реляционную модель. What all of these data stores have in common is that they don’t use a relational model. Кроме того, они, как правило, поддерживают определенные типы данных. Процесс запроса данных также специфический. Also, they tend to be more specific in the type of data they support and how data can be queried. Например, хранилища данных временных рядов рассчитаны на запросы к последовательностям данных, упорядоченных по времени, а хранилища данных графов — на анализ взвешенных связей между сущностями. For example, time series data stores are optimized for queries over time-based sequences of data, while graph data stores are optimized for exploring weighted relationships between entities. Ни один из форматов не подходит в полней мере при выполнении задач управления данными о транзакциях. Neither format would generalize well to the task of managing transactional data.

Термин NoSQL применяется к хранилищам данных, которые не используют язык запросов SQL, а запрашивают данные с помощью других языков и конструкций. The term NoSQL refers to data stores that do not use SQL for queries, and instead use other programming languages and constructs to query the data. На практике NoSQL означает «нереляционная база данных», даже несмотря на то, что многие из этих баз данных не поддерживают совместимые с SQL запросы. In practice, «NoSQL» means «non-relational database,» even though many of these databases do support SQL-compatible queries. Однако базовая стратегия выполнения запросов SQL обычно значительно отличается от применяемой в системе управления реляционной базой данных (реляционная СУБД). However, the underlying query execution strategy is usually very different from the way a traditional RDBMS would execute the same SQL query.

В разделах ниже описаны основные категории нереляционных баз данных или баз данных NoSQL. The following sections describe the major categories of non-relational or NoSQL database.

Хранилища данных документов Document data stores

Хранилище данных документов управляет набором значений именованных строковых полей и данных объекта в сущности, которая называется документом. A document data store manages a set of named string fields and object data values in an entity referred to as a document. Обычно данные в этих хранилищах содержатся в виде документов JSON. These data stores typically store data in the form of JSON documents. Каждое значение поля может представлять собой скалярный элемент, например число, или сложный объект, например список или коллекция типа «родитель — потомок». Each field value could be a scalar item, such as a number, or a compound element, such as a list or a parent-child collection. Данные в полях документа можно закодировать разными способами, например в формате XML, YAML, JSON, BSON, или хранить в виде обычного текста. The data in the fields of a document can be encoded in a variety of ways, including XML, YAML, JSON, BSON, or even stored as plain text. Поля документов доступны системе управления хранилищем, что позволяет приложению выполнять запросы и применять фильтры, основанные на значениях этих полей. The fields within documents are exposed to the storage management system, enabling an application to query and filter data by using the values in these fields.

Как правило, документ содержит все данные одной сущности. Typically, a document contains the entire data for an entity. Элементы, составляющие сущность, зависят от конкретного приложения. What items constitute an entity are application-specific. Например, сущность может содержать сведения о клиенте, заказе или и те, и другие. For example, an entity could contain the details of a customer, an order, or a combination of both. Один документ может содержать сведения, которые в реляционной СУБД обычно распределяются по нескольким реляционным таблицам. A single document might contain information that would be spread across several relational tables in a relational database management system (RDBMS). Хранилище документов не обязывает использовать одинаковую структуру для всех документов. A document store does not require that all documents have the same structure. Поддержка свободной формы обеспечивает большую гибкость. This free-form approach provides a great deal of flexibility. Например, приложения могут хранить в документах разные данные в соответствии с текущими требованиями компании. For example, applications can store different data in documents in response to a change in business requirements.

Приложение может получать документы по ключу документа. The application can retrieve documents by using the document key. Это уникальный идентификатор документа. Часто к нему применяется хэширование для равномерного распределения данных. This is a unique identifier for the document, which is often hashed, to help distribute data evenly. Некоторые базы данных документов создают ключ документа автоматически. Some document databases create the document key automatically. Другие позволяют указать, какой атрибут документа следует использовать в качестве ключа. Others enable you to specify an attribute of the document to use as the key. Также приложение может запрашивать документы по значениям одного или нескольких полей. The application can also query documents based on the value of one or more fields. Некоторые базы данных документов поддерживают индексирование, что ускоряет поиск документов по одному или нескольким индексированным полям. Some document databases support indexing to facilitate fast lookup of documents based on one or more indexed fields.

Многие базы данных документов поддерживают обновления «на месте», то есть позволяют приложению изменять значения отдельных полей без перезаписи всего документа. Many document databases support in-place updates, enabling an application to modify the values of specific fields in a document without rewriting the entire document. Операции чтения и записи для нескольких полей в одном документе обычно являются атомарными. Read and write operations over multiple fields in a single document are typically atomic.

Соответствующие службы Azure: Relevant Azure service:

Столбчатые хранилища данных Columnar data stores

Столбчатое хранилище данных или хранилище семейств столбцов упорядочивает данные по столбцам и строкам. A columnar or column-family data store organizes data into columns and rows. Столбчатое хранилище данных в простейшей форме почти неотличимо от реляционной базы данных, по крайней мере организационно. In its simplest form, a column-family data store can appear very similar to a relational database, at least conceptually. Настоящее преимущество столбчатого хранилища данных заключается в способности денормализованно структурировать разреженные данные, что связано со столбцово-ориентированным методом хранения данных. The real power of a column-family database lies in its denormalized approach to structuring sparse data, which stems from the column-oriented approach to storing data.

Столбчатое хранилище данных можно представить как набор табличных данных со строками и столбцами, в которых столбцы разделяются на определенные группы или семейства столбцов. You can think of a column-family data store as holding tabular data with rows and columns, but the columns are divided into groups known as column families. Каждое семейство столбцов включает набор логически связанных столбцов, которые обычно извлекаются или управляются как единое целое. Each column family holds a set of columns that are logically related and are typically retrieved or manipulated as a unit. Другие данные, которые используются в других процессах, хранятся отдельно в других семействах столбцов. Other data that is accessed separately can be stored in separate column families. В семейство столбцов можно динамически добавить новые столбцы, а строки могут быть разреженными (то есть строки не обязаны иметь значение для каждого столбца). Within a column family, new columns can be added dynamically, and rows can be sparse (that is, a row doesn’t need to have a value for every column).

На следующей диаграмме представлен пример таблицы с двумя семействами столбцов: Identity и Contact Info . The following diagram shows an example with two column families, Identity and Contact Info . Данные одной сущности имеют одинаковые ключи строк во всех семействах столбцов. The data for a single entity has the same row key in each column family. Такая структура, в которой строки любого объекта в семействе столбцов могут динамически изменяться, определяет важное преимущество этой категории хранилищ. Семейства столбцов очень хорошо подходят для хранения данных с различными схемами. This structure, where the rows for any given object in a column family can vary dynamically, is an important benefit of the column-family approach, making this form of data store highly suited for storing data with varying schemas.

В отличие от хранилища пар «ключ — значение» и баз данных документов, большинство столбчатых баз данных упорядочивают хранимые данные с помощью самих значений ключей, а не хэш-кодов от них. Unlike a key/value store or a document database, most column-family databases physically store data in key order, rather than by computing a hash. Ключ строки рассматривается как первичный индекс и обеспечивает доступ на основе определенного ключа или их диапазона. The row key is considered the primary index and enables key-based access via a specific key or a range of keys. Некоторые реализации позволяют создавать вторичные индексы по определенным столбцам в семействе столбцов. Some implementations allow you to create secondary indexes over specific columns in a column family. Вторичные индексы позволяют получать данные по значениям столбцов, а не ключам строки. Secondary indexes let you retrieve data by columns value, rather than row key.

Мастер Йода рекомендует:  Как использовать HTML-тег base

Все столбцы одного семейства хранятся на диске в одном файле. Каждый файл содержит определенное число строк. On disk, all of the columns within a column family are stored together in the same file, with a certain number of rows in each file. При использовании больших наборов данных этот подход позволяет повысить производительность за счет снижения объема данных, которые необходимо считывать с диска, когда отправляется запрос на получение нескольких столбцов за раз. With large data sets, this approach creates a performance benefit by reducing the amount of data that needs to be read from disk when only a few columns are queried together at a time.

Операции чтения и записи для строки обычно являются атомарными в пределах одного семейства столбцов, хотя некоторые реализации обеспечивают атомарность по всей строке, охватывающую несколько семейств столбцов. Read and write operations for a row are typically atomic within a single column family, although some implementations provide atomicity across the entire row, spanning multiple column families.

Соответствующие службы Azure: Relevant Azure service:

Хранилище пар «ключ — значение» Key/value data stores

Хранилище пар «ключ — значение» по сути представляет собой большую хэш-таблицу. A key/value store is essentially a large hash table. Каждое значение сопоставляется с уникальным ключом, и хранилище ключей использует этот ключ для хранения данных, применяя к нему некоторую функцию хэширования. You associate each data value with a unique key, and the key/value store uses this key to store the data by using an appropriate hashing function. Выбор функции хэширования должен обеспечить равномерное распределение хэшированных ключей по хранилищу данных. The hashing function is selected to provide an even distribution of hashed keys across the data storage.

Большинство хранилищ пар «ключ — значение» поддерживают только самые простые операции запроса, вставки и удаления. Most key/value stores only support simple query, insert, and delete operations. Чтобы частично или полностью изменить значение, приложение всегда перезаписывает существующее значение целиком. To modify a value (either partially or completely), an application must overwrite the existing data for the entire value. В большинстве реализаций атомарной операцией считается чтение или запись одного значения. In most implementations, reading or writing a single value is an atomic operation. Запись больших значений занимает относительно долгое время. If the value is large, writing may take some time.


Приложение может хранить в наборе значений произвольные данные, но некоторые хранилища пар «ключ — значение» накладывают ограничения на максимальный размер значений. An application can store arbitrary data as a set of values, although some key/value stores impose limits on the maximum size of values. Программное обеспечение хранилища ничего не знает о значениях, которые в нем хранятся. The stored values are opaque to the storage system software. Все сведения о схеме поддерживаются и применяются на уровне приложения. Any schema information must be provided and interpreted by the application. Эти значения по существу являются большими двоичными объектами, которые хранилище извлекает и сохраняет по соответствующему ключу. Essentially, values are blobs and the key/value store simply retrieves or stores the value by key.

Хранилища пар «ключ — значение» рассчитаны на приложения, выполняющие простые операции поиска на основе значения ключа или диапазона ключей, но не очень подходят для систем, которым нужно запрашивать данные из нескольких таблиц хранилищ пар «ключ — значение», например присоединенные данные в нескольких таблицах. Key/value stores are highly optimized for applications performing simple lookups using the value of the key, or by a range of keys, but are less suitable for systems that need to query data across different tables of keys/values, such as joining data across multiple tables.

Кроме того, хранилища пар «ключ — значение» неудобны в сценариях, где могут выполняться запросы или фильтрация по значению, а не только по ключам. Key/value stores are also not optimized for scenarios where querying or filtering by non-key values is important, rather than performing lookups based only on keys. Например, с помощью реляционной базы данных можно найти запись, используя предложение WHERE для фильтрации неключевых столбцов, но в хранилищах «ключ-значение» обычно отсутствует возможность поиска в значениях, или, если они есть, требуется медленный Просмотр всех значений. For example, with a relational database, you can find a record by using a WHERE clause to filter the non-key columns, but key/values stores usually do not have this type of lookup capability for values, or if they do, it requires a slow scan of all values.

Одно хранилище пар «ключ — значение» очень легко масштабируется, поскольку позволяет удобно распределить данные среди нескольких узлов на разных компьютерах. A single key/value store can be extremely scalable, as the data store can easily distribute data across multiple nodes on separate machines.

Соответствующие службы Azure: Relevant Azure services:

Хранилища данных графов Graph data stores

Хранилища данных графов управляют сведениями двух типов: узлами и ребрами. A graph data store manages two types of information, nodes and edges. Узлы в этом случае представляют сущности, а ребра определяют связи между ними. Nodes represent entities, and edges specify the relationships between these entities. Узлы и грани имеют свойства, которые предоставляют сведения о конкретном узле или грани, примерно как столбцы в реляционной таблице. Both nodes and edges can have properties that provide information about that node or edge, similar to columns in a table. Грани могут иметь направление, указывающее на характер связи. Edges can also have a direction indicating the nature of the relationship.

Хранилища данных графов позволяют приложениям эффективно выполнять запросы, которые проходят через сеть узлов и ребер, а также анализировать связи между сущностями. The purpose of a graph data store is to allow an application to efficiently perform queries that traverse the network of nodes and edges, and to analyze the relationships between entities. На схеме ниже представлены данные персонала организации, структурированные в виде графа. The following diagram shows an organization’s personnel data structured as a graph. Сущностями здесь являются сотрудники и отделы, а грани определяют отношения подчинения и отдел, в котором работает каждый сотрудник. The entities are employees and departments, and the edges indicate reporting relationships and the department in which employees work. На этом графе грани имеют строгое направление, которое на схеме обозначено стрелками. In this graph, the arrows on the edges show the direction of the relationships.

Такая структура позволяет легко выполнять такие запросы, как «найти всех сотрудников, которые прямо или косвенно подчиняются Светлане» или «найти всех, кто работает в одном отделе с Дмитрием». This structure makes it straightforward to perform queries such as «Find all employees who report directly or indirectly to Sarah» or «Who works in the same department as John?» Для больших диаграмм с большим количеством сущностей и связей можно быстро выполнять сложный анализ. For large graphs with lots of entities and relationships, you can perform complex analyses quickly. Многие базы данных графов предоставляют язык запросов, который можно использовать для эффективного обхода сети связей. Many graph databases provide a query language that you can use to traverse a network of relationships efficiently.

Соответствующие службы Azure: Relevant Azure service:

Хранилища данных временных рядов Time series data stores

Данными временных рядов называются наборы значений, которые упорядочены по времени. Соответственно хранилища данных временных рядов оптимизированы для хранения данных именно такого типа. Time series data is a set of values organized by time, and a time series data store is optimized for this type of data. Хранилища данных временных рядов должны поддерживать очень большое число операций записи, так как обычно в них в режиме реального времени собирается большой объем данных из большого количества источников. Time series data stores must support a very high number of writes, as they typically collect large amounts of data in real time from a large number of sources. Эти хранилища также хорошо подходят для хранения данных телеметрии. Time series data stores are optimized for storing telemetry data. Например, для сбора данных от датчиков Интернета вещей или счетчиков в приложениях или системах. Scenarios include IoT sensors or application/system counters. Обновления в таких базах данных выполняются редко, а удаление чаще всего является массовой операцией. Updates are rare, and deletes are often done as bulk operations.

Размер отдельных записей в базе данных временных рядов обычно невелик, но их очень много, а значит общий размер данных быстро увеличивается. Although the records written to a time series database are generally small, there are often a large number of records, and total data size can grow rapidly. Хранилища данных временных рядов также обрабатывают данные, полученные вне очереди или несвоевременно, автоматически индексируют точки данных и оптимизируют запросы, полученные в течение определенного промежутка времени. Time series data stores also handle out-of-order and late-arriving data, automatic indexing of data points, and optimizations for queries described in terms of windows of time. Эта последняя возможность позволяет быстро выполнять запросы к миллионам точек данных и нескольким потокам данных, что, в свою очередь, обеспечивает поддержку визуализации временных рядов (стандартный способ потребления данных временных рядов). This last feature enables queries to run across millions of data points and multiple data streams quickly, in order to support time series visualizations, which is a common way that time series data is consumed.

Дополнительные сведения см. в статье Решения для временных рядов. For more information, see Time series solutions

Соответствующие службы Azure: Relevant Azure services:

Хранилище данных объектов Object data stores

Хранилища данных объектов оптимизированы для хранения и извлечения больших двоичных объектов, например изображений, текстовых файлов, видео- и аудиопотоков, объектов данных и документов приложений большого размера, образы дисков виртуальных машин. Object data stores are optimized for storing and retrieving large binary objects or blobs such as images, text files, video and audio streams, large application data objects and documents, and virtual machine disk images. Объект состоит из сохраненных данных, метаданных и уникального идентификатора доступа к объекту. An object consists of the stored data, some metadata, and a unique ID for accessing the object. Хранилища объектов поддерживают отдельные большие файлы, а также позволяют управлять всеми файлами за счет внушительного общего объема хранилища. Object stores are designed to support files that are individually very large, as well provide large amounts of total storage to manage all files.

Некоторые хранилища данных объектов реплицируют определенный большой двоичный объект между несколькими узлами кластера, что обеспечивает быстрое параллельное чтение. Some object data stores replicate a given blob across multiple server nodes, which enables fast parallel reads. Это, в свою очередь, позволяет реализовать масштабируемую архитектуру запроса данных, хранящихся в больших файлах, так как несколько процессов, обычно выполняющихся на разных серверах, могут одновременно запрашивать большие файлы данных. This in turn enables the scale-out querying of data contained in large files, because multiple processes, typically running on different servers, can each query the large data file simultaneously.

Часто хранилища данных объектов используют как сетевые общие папки. One special case of object data stores is the network file share. Доступ к файлам, хранящимся в этих папках, можно получить через компьютерную сеть с использованием стандартных сетевых протоколов, например SMB. Using file shares enables files to be accessed across a network using standard networking protocols like server message block (SMB). Учитывая соответствующие механизмы обеспечения безопасности и параллельного управления доступом, совместное использование данных позволяет распределенным службам обеспечить высокую масштабируемость доступа к данным для базовых операций низкого уровня, таких как простые запросы на чтение и запись. Given appropriate security and concurrent access control mechanisms, sharing data in this way can enable distributed services to provide highly scalable data access for basic, low-level operations such as simple read and write requests.

Соответствующие службы Azure: Relevant Azure services:

Хранилища данных внешних индексов External index data stores

Хранилища данных внешних индексов позволяют искать информацию, содержащуюся в других хранилищах данных и службах. External index data stores provide the ability to search for information held in other data stores and services. Внешний индекс выступает в роли вторичного индекса любого хранилища данных. Кроме того, с его помощью можно индексировать большие объемы данных и предоставлять доступ к этим индексам почти в реальном времени. An external index acts as a secondary index for any data store, and can be used to index massive volumes of data and provide near real-time access to these indexes.

Например, в файловой системе могут храниться текстовые файлы. For example, you might have text files stored in a file system. По пути файл можно найти быстро, но поиск на основе содержимого выполняется медленно, так как сканируются все файлы. Finding a file by its file path is quick, but searching based on the contents of the file would require a scan of all of the files, which is slow. Внешний индекс позволяет создавать вторичные индексы, а затем быстро искать путь к файлам, соответствующим заданным условиям. An external index lets you create secondary search indexes and then quickly find the path to the files that match your criteria. Рассмотрим еще один пример использования внешнего индекса. Предположим, что хранилища пар «ключ — значение» поддерживают индексирование только по ключу. Another example application of an external index is with key/value stores that only index by the key. Вы можете создать вторичный индекс на основе значений данных и быстро найти ключ, однозначно определяющий каждый соответствующий элемент. You can build a secondary index based on the values in the data, and quickly look up the key that uniquely identifies each matched item.

Индексы создаются в процессе индексирования, The indexes are created by running an indexing process. который может выполняться по модели извлечения, то есть по требованию хранилища данных, или по модели передачи, то есть по команде из кода приложения. This can be performed using a pull model, triggered by the data store, or using a push model, initiated by application code. В некоторых системах поддерживаются многомерные индексы и полнотекстовый поиск по большим объемам текстовых данных. Indexes can be multidimensional and may support free-text searches across large volumes of text data.

Хранилища данных внешнего индекса часто используются для поддержки полнотекстового поиска. External index data stores are often used to support full text and web-based search. В этих случаях поддерживается точный или нечеткий поиск. In these cases, searching can be exact or fuzzy. Нечеткий поиск находит документы, которые соответствуют набору условий, и вычисляет для них коэффициент совпадения с этим набором. A fuzzy search finds documents that match a set of terms and calculates how closely they match. Некоторые внешние индексы также поддерживают лингвистический анализ, который возвращает соответствия с учетом синонимов, категорий (например, при поиске по запросу «собаки» соответствием считается «питомцы») и морфологии (например, при поиске по запросу «бег» соответствием считается «бегущий»). Some external indexes also support linguistic analysis that can return matches based on synonyms, genre expansions (for example, matching «dogs» to «pets»), and stemming (for example, searching for «run» also matches «ran» and «running»).

Соответствующие службы Azure: Relevant Azure service:

Стандартные требования Typical requirements

Часто архитектура нереляционных хранилищ данных отличается от архитектуры реляционных баз данных. Non-relational data stores often use a different storage architecture from that used by relational databases. В частности, они обычно не имеют фиксированной схемы. Specifically, they tend toward having no fixed schema. а также не поддерживают транзакции или ограничивают их область. Из соображений масштабируемости они обычно не включают вторичные индексы. Also, they tend not to support transactions, or else restrict the scope of transactions, and they generally don’t include secondary indexes for scalability reasons.

В таблице ниже приведено сравнение требований каждого нереляционного хранилища данных. The following compares the requirements for each of the non-relational data stores:

Тестирование производительности NoSQL БД

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

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

За счет чего достигается скорость в NoSQL? В первую очередь, это следствие совсем другой парадигмы хранения данных. Парсинг и трансляция SQL-запросов, работа оптимизатора, объединение таблиц и прочее сильно увеличивают время ответа. Если взять и выкинуть все эти слои, упростить запросы, читать с диска прямо в сеть или хранить все данные в оперативной памяти, то можно выиграть в скорости. Уменьшается как время обработки каждого запроса, так и количество запросов в секунду. Так появились key-value БД, самым типичным и широко известным представителем которых является memcached. Да, этот кеш, широко применяемый в веб-приложениях для ускорения доступа к данным, тоже является NoSQL.

Типы NoSQL

Можно выделить четыре основные категории NoSQL-систем:

  • Ключ — значение (key-value). Большая хеш-таблица, где допустимы только операции записи и чтения данных по ключу.
  • Колоночные (column). Таблицы, со строками и колонками. Вот только в отличие от SQL количество колонок от строки к строке может быть переменным, а общее число колонок может измеряться миллиардами. Также каждая строка имеет уникальный ключ. Можно рассматривать такую структуру данных как хеш-таблицу хеш-таблицы, первым ключом является ключ строки, вторым — имя колонки. При поддержке вторичных индексов возможны выборки по значению в колонке, а не только по ключу строки.
  • Документо-ориентированные (document-oriented). Коллекции структурированных документов. Возможна выборка по различным полям документа, а также модификация частей документа. К этой же категории можно отнести поисковые движки, которые являются индексами, но, как правило, не хранят сами документы.
  • Графовые (graph). Специально предназначены для хранения математических графов: узлов и связей между ними. Как правило, позволяют задавать для узлов и связей еще и набор произвольных атрибутов и выбирать узлы и связи по этим атрибутам. Поддерживают алгоритмы обхода графов и построения маршрутов.

Для теста мы взяли представителей первых трех категорий:

    Aerospike (в девичестве Citrusleaf). Очень быстрая key-value БД (а с версии 3.0 — еще и частично документо-ориентированная). В явном виде поддерживает SSD, использует их напрямую, без файловой системы, как блочные устройства. Создавалась для рынка онлайн-рекламы (в том числе для так называемого RTB — Real Time B >

Как проводился тест

В распоряжении у нас было четыре серверных машинки. В каждой: восьмиядерный Xeon, 32 Гб ОЗУ, четыре интеловских SSD по 120 Гб каждый.

Тестировали мы с помощью YCSB (Yahoo! Cloud Serving Benchmark). Это специальный бенчмарк, выпущенный командой Yahoo! Research в 2010 году под лицензией Apache. Бенчмарк специально создан для тестирования NoSQL баз данных. И сейчас он остается единственным и довольно популярным бенчмарком для NoSQL, фактически стандартом. Написан, кстати, на Java. Мы добавили к оригинальному YCSB драйвер для Aerospike, слегка обновили драйвер для MongoDB, а также несколько подшаманили с выводом результатов.

Кроме YCSB, тестировать производительность NoSQL БД можно с помощью, например, JMeter.

Для создания нагрузки на наш маленький кластер потребовалось восемь клиентских машин. По четырехъядерному i5 и 4 Гб ОЗУ на каждой. Одного (и двух, и трех, и четырех. ) клиентов оказалось недостаточно, чтобы загрузить кластер. Может показаться странным, но факт.

Все это шевелилось в одной гигабитной локальной сети. Пожалуй, было бы интереснее в десятигигабитной сети, но такого железа у нас не было. Интереснее, потому что, когда количество операций в секунду начинает измеряться сотнями тысяч, мы утыкаемся в сеть. При пропускной способности в гигабит в секунду (10^9 бит/c) сеть может пропустить килобайтных пакетов (

10^4 бит) лишь около 100 000 (10^5) штук. То есть получаем лишь 100k операций в секунду. А нам вообще-то хотелось получить миллион :).

Сетевые карты тоже имеют значение. Правильные серверные сетевухи имеют несколько каналов ввода-вывода, соответственно, каждый с собственным прерыванием. Вот только по умолчанию в линуксе все эти прерывания назначены на одно ядро процессора. Только ребята из Aerospike озаботились этой тонкостью, и их скрипты настройки БД раскидывают прерывания сетевых карт по ядрам процессора. Посмотреть прерывания сетевых карт и то, как они распределены по ядрам процессора, можно, например, такой командой: «cat /proc/interrupts | grep eth».

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

Настраиваем SSD

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

Свободные блоки могут получиться несколькими способами. Можно с помощью команды hdparm (с ключом ‘-N’) указать количество секторов диска, видимых операционной системой. Остальное будет в полном распоряжении контроллера. Однако это работает не на всяком железе (в AWS EC2, например, не работает). Другой способ — оставить не занятое разделами место на диске (имеются в виду разделы, создаваемые, например, fdisk). Контроллер достаточно умен, чтобы задействовать это место. Третий способ — использовать файловые системы и версии ядра, которые умеют сообщать контроллеру о свободных блоках. Это та самая команда TRIM. На нашем железе хватило hdparm, мы отдали на растерзание контроллеру 20% от общего объема дисков.

Для SSD важен также планировщик ввода-вывода. Это такая подсистема ядра, которая группирует и переупорядочивает операции ввода-вывода (в основном записи на диск) с целью повысить эффективность. По умолчанию линукс использует CFQ (Completely Fair Queuing), который старается переставить операции записи так, чтобы записать как можно больше блоков последовательно. Это хорошо для обычных вращающихся (так и говорят — spinning :)) дисков, потому что для них скорость линейного доступа заметно выше доступа к случайным блокам (головки нужно перемещать). Но для SSD линейная и случайная запись — одинаково эффективны (теоретически), и работа CFQ только вносит лишние задержки. Поэтому для SSD-дисков нужно включать другие планировщики, например NOOP, который просто выполняет команды ввода-вывода в том порядке, в каком они поступили. Переключить планировщик можно, например, такой командой: «echo noop > /sys/block/sda/queue/scheduler», где sda — твой диск. Справедливости ради стоит упомянуть, что свежие ядра сами умеют определять SSD-накопители и включать для них правильный планировщик.

Любая СУБД любит интенсивно писать на диск, а также интенсивно читать. А Linux очень любит делать read-ahead, упреждающее чтение данных, — в надежде, что, раз ты прочитал этот блок, ты захочешь прочитать и несколько следующих. Однако с СУБД, и особенно при случайном чтении (а этот как раз наш вариант), этим надеждам не суждено сбыться. В результате имеем никому не нужное чтение и использование памяти. Разработчики MongoDB рекомендуют по возможности уменьшить значение read-ahead. Сделать это можно командой «blockdev —setra 8 /dev/sda», где sda — твой диск.

Любая СУБД любит открывать много-много файлов. Поэтому необходимо заметно увеличить лимиты nofile (количество доступных файловых дескрипторов для пользователя) в файле /etc/security/limits.conf на значение сильно больше 4k.

Также возник интересный вопрос: как использовать четыре SSD? Если Aerospike просто подключает их как хранилища и как-то самостоятельно чередует доступ к дискам, то другие БД подразумевают, что у них есть лишь один каталог с данными. (В некоторых случаях можно указать и несколько каталогов, но это не предполагает чередования данных между ними.) Пришлось создавать RAID 0 (с чередованием) с помощью утилиты mdadm. Я полагаю, что можно было бы поиграть с LVM, но производители СУБД описывают только использование mdadm.

Естественно, на всех машинах кластера (как серверных, так и клиентских) часы должны быть синхронизированы с помощью ntpd. Ntpdate тут не годится, потому что требуется бóльшая точность синхронизации. Для всех распределенных систем жизненно важно, чтобы время между узлами было синхронизировано. Например, Cassandra и Aerospike хранят время изменения записи. И если на разных узлах кластера найдутся записи с разным таймстампом, то победит та запись, которая новее.

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

Проще всего настраивается Couchbase. У него есть веб-консоль. Достаточно запустить сервис на всех узлах кластера. Затем на одном из узлов создать bucket («корзину» для ключей-значений) и добавить другие узлы в кластер. Все через веб-интерфейс. Особо хитрых параметров настройки у него нет.

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

Сложнее всего с MongoDB. У других БД все узлы равнозначны. У Mongo это не так. Мы хотели поставить все БД по возможности в одинаковые условия и выставить у всех replication factor в 2. Это означает, что в кластере должно быть две копии данных, для надежности и скорости. В других БД replication factor — это лишь настройка хранилища данных (или «корзины», или «семейства колонок»). В MongoDB количество копий данных определяется структурой кластера. Грамотно настроить кластер MongoDB можно, только дважды прочтя официальную документацию, посвященную этому :). Говоря кратко, нам нужны shards or replica-sets. Шарды (ну ты наверняка слышал термин «шардинг») — это подмножества всего набора данных, а также узлы кластера, где каждое подмножество будет хранится. Реплика-сеты — это термин MongoDB, обозначающий набор узлов кластера, хранящих одинаковые копии данных. В реплика-сете есть главный узел, который выполняет операции записи, и вторичные узлы, на которые осуществляется репликация данных с главного узла. В случае сбоев роль главного узла может быть перенесена на другой узел реплика-сета. Для нашего случая (четыре сервера и желание хранить две копии данных) получается, что нам нужно два шарда, каждый из которых представляет собой реплика-сет из двух серверов с данными. Кроме того, в каждый реплика-сет нужно добавить так называемый арбитр, который не хранит данные, а нужен для участия в выборах нового главного узла. Число узлов в реплика-сете для правильных выборов должно быть нечетным. Еще нужна маленькая конфигурационная БД, в которой будет храниться информация о шардах и о том, какие диапазоны данных на каком шарде хранятся. Технически это тоже MongoDB, только (по сравнению с основными данными) очень маленькая. Арбитры и конфигурационную БД мы разместили на клиентских машинах. И еще на каждом клиенте нужно запустить демон mongos (mongo switch), который будет обращаться к конфигурационной БД и маршрутизировать запросы от каждого клиента между шардами.

Хакер #180. 2014: люди, вирусы, баги, релизы

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

Набор данных, которыми оперирует YCSB, — это ключ и значение. Ключ — это строка, в которую входит 64-битный хеш. Таким образом, сам YCSB, зная общее количество записей в БД, обращается к ним по целочисленному индексу, а для БД множество ключей выглядит вполне случайным. Значение — десяток полей случайных бинарных данных. По умолчанию YCSB генерирует записи килобайтного размера, но, как ты помнишь, в гигабитной сети это ограничивает нас лишь в 100k операций в секунду. Поэтому в тестах мы уменьшили размер одной записи до 100 байт.

Операции над этими данными YCSB осуществляет тоже простейшие: вставка новой записи с ключом и случайными данными, чтение записи по ключу, обновление записи по ключу. Никаких объединений таблиц (да и вообще подразумевается лишь одна «таблица»). Никаких выборок по вторичным ключам. Никаких множественных выборок по условию (единственная проверка — совпадение первичного ключа). Это очень примитивно, но зато может быть произведено в любой БД.

Мастер Йода рекомендует:  SEO оптимизация картинок для сайта

Непосредственно перед тестированием БД нужно наполнить данными. Делается это самим YCSB. По сути, это нагрузка, состоящая лишь из операций вставки. Мы экспериментировали с двумя наборами данных. Первый гарантированно помещается в оперативную память узлов кластера, 50 миллионов записей, примерно 5 Гб чистых данных. Второй гарантированно не помещается в ОЗУ, 500 миллионов записей, примерно 50 Гб чистых данных.

Сам тест — выполнение определенного набора операций — производится под нагрузкой разного типа. Важным параметром является соотношение операций — сколько должно быть чтений, а сколько обновлений. Мы использовали два типа: интенсивная запись (Heavy Write, 50% чтений и 50% обновлений) и в основном чтение (Mostly Read, 95% чтений и 5% обновлений). Какую операцию выполнить, каждый раз выбирается случайно, проценты определяют вероятность выбора операции.

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

Как работает YCSB

YCSB стартует с несколькими потоками, запуская цикл выполнения операций в каждом из них, и все это на одной машине. Имея лишь четыре ядра на одной клиентской машине, довольно грустно пытаться запускать там более четырех потоков. Поэтому мы запускали YCSB на восьми клиентских машинах одновременно. Для автоматизации запуска мы использовали fabric и cron (точнее, at). Небольшой скрипт на Python формирует необходимые для запуска YCSB команды на каждом клиенте, эти команды помещаются в очередь at на одно и то же время на ближайшую минуту в будущем на каждом клиенте. Потом срабатывает at, и YCSB успешно (или не очень, если ошиблись в параметрах) запускается в одно и то же время на всех восьми клиентах. Чтобы собрать результаты (лог файлы YCSB), снова используется fabric.

Результаты

Итак, исходные результаты — это логи YCSB, с каждого клиента. Выглядят эти логи примерно так (показан финальный кусочек файла):

Как видишь, здесь есть количество операций определенного типа (в данном примере — чтения), средняя, минимальная и максимальная задержки, задержка, в которую уложились 95 и 99% операций, количество успешных операций (код возврата 0), общее время теста, общее количество всех операций и среднее количество операций в секунду. Нас больше всего интересует средняя задержка (AverageLatency) и количество операций в секунду (Throughput).

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

Скорость вставки на SSD Скорость вставки в память Производительность при интенсивной записи на SSD Производительность при интенсивной записи в памяти Производительность при 95% чтения на SSD Производительность при 95% чтения в памяти

Выводы

NoSQL БД разделились на две группы: быстрые и медленные. Быстрыми, как, собственно, и ожидалось, оказались key-value БД. Aerospike и Couchbase сильно опережают соперников.

Aerospike действительно очень быстрая БД. И нам почти получилось дойти до миллиона операций в секунду (на данных в памяти). Aerospike весьма неплохо работает и на SSD, особенно если учитывать, что Aerospike в этом режиме не использует кеширование данных в памяти, а на каждый запрос обращается к диску. Значит, в Aerospike действительно можно поместить большое количество данных (пока хватит дисков, а не ОЗУ).

Couchbase быстр, но быстр только на операциях в памяти. На графиках с тестами SSD показана скорость работы Couchbase на объеме данных лишь чуть больше объема ОЗУ — всего 200 миллионов записей. Это заметно меньше 500 миллионов, с которыми тестировались другие БД. В Couchbase просто не удалось вставить больше записей, он отказывался вытеснять кеш данных из памяти на диск и прекращал запись (операции записи завершались с ошибками). Это хороший кеш, но лишь для данных, помещающихся в ОЗУ.

Cassandra — единственная БД, которая пишет быстрее, чем читает :). Это оттого, что запись в ней успешно завершается (в самом быстром варианте) сразу после записи в журнал (на диске). А вот чтение требует проверок, нескольких чтений с диска, выбора самой свежей записи. Cassandra — это надежный и довольно быстрый масштабируемый архив данных.

MongoDB довольно медленна на запись, но относительно быстра на чтение. Если данные (а точнее, то, что называют working set — набор актуальных данных, к которым постоянно идет обращение) не помещаются в память, она сильно замедляется (а это именно то, что происходит при тестировании YCSB). Также нужно помнить, что у MongoDB существует глобальная блокировка на чтение/запись, что может доставить проблем при очень высокой нагрузке. В целом же MongoDB — хорошая БД для веба.

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


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

К NewSQL причисляют VoltDB, TokuDB, MemDB и другие. Запомни эти имена, возможно, скоро о них тоже будут говорить на каждой ИТ-конференции.

Как создать и выполнить SQL запрос к базе данных. Обзор основных инструментов

Приветствую Вас на сайте Info-Comp.ru! Сегодня я продолжаю рассказ о языке SQL, и в этом материале я немного расскажу о том, как создаются и выполняются SQL запросы к базе данных, а точнее какие инструменты (программы) для этого используются.

Как создать SQL запрос? Где писать SQL код?

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

Обычный случай, когда человек только что установил себе какую-нибудь СУБД (например, для изучения SQL) и не знает, что делать дальше, где писать SQL код? какую программу запустить?

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

Поэтому сегодня, специально для начинающих SQL программистов, я расскажу о том, какие инструменты нужны для того, чтобы создавать и выполнять SQL запросы к базе данных, иными словами, где писать SQL запросы. При этом я расскажу про инструменты для всех популярных СУБД: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL. Так как для каждой СУБД используются отдельные инструменты, но есть, конечно же, и универсальные инструменты, которые умеют работать одновременно практически со всеми из вышеперечисленных баз данных.

Если у Вас возникает вопрос, как послать SQL запрос к базе данных из приложения при его разработке (например, Вы начинающий программист Java, C# или других языков), то это делается непосредственно из самой IDE (среды программирования), используя специальные драйверы для подключения к БД. Устанавливать перечисленные в данной статье инструменты необязательно, они нужны для прямой работы с базой данных: разработка и отладка SQL инструкций, выполнение административных задач и так далее.

Инструменты для создания SQL запросов

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

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

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

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

Microsoft SQL Server

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

Инструментов для работы с Microsoft SQL Server много, однако самый распространённый и популярный вариант – это, конечно же, SQL Server Management Studio.

SQL Server Management Studio

SQL Server Management Studio (SSMS) — это бесплатная графическая среда для управления инфраструктурой SQL Server, разработанная компанией Microsoft. С помощью Management Studio Вы можете разрабатывать и выполнять инструкции T-SQL, а также администрировать Microsoft SQL Server.

Среда SQL Server Management Studio – это основной, стандартный инструмент для работы с Microsoft SQL Server.

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

Более подробно про SQL Server Management Studio, включая то, как установить данную среду, я рассказывал в статье – Обзор и установка SQL Server Management Studio.

SQL Server Data Tools

SQL Server Data Tools – это еще один инструмент для работы с Microsoft SQL Server, разработанный компанией Microsoft. Данный инструмент входит в состав Visual Studio, и устанавливается он как отдельная рабочая нагрузка. Предназначен SQL Server Data Tools в первую очередь для разработчиков приложений.

Если Вы разрабатываете программы с помощью Visual Studio, при этом у Вас возникла необходимость работы с Microsoft SQL Server, то SQL Server Data Tools будет для Вас очень удобным и привычным инструментом.

dbForge Studio for SQL Server

dbForge Studio for SQL Server – это мощная среда для разработки и администрирования баз данных в Microsoft SQL Server. Разработчиком данной среды является компания Devart, у которой, кстати, есть много инструментов для работы с Microsoft SQL Server, про один инструмент я уже рассказывал в статье – Как сравнить и синхронизировать две базы данных в Microsoft SQL Server? Кроме того, у Devart есть и инструменты для работы с другими СУБД, про некоторые я сегодня еще расскажу.

Red Gate SQL Prompt

Red Gate SQL Prompt – еще один мощнейший инструмент для работы с Microsoft SQL Server. С помощью него также можно разрабатывать SQL инструкции и администрировать SQL сервер. Данную среду разрабатывает компания Redgate Software, которая специализируется на работе с данными, у нее есть инструменты и для работы с другими СУБД, но основным направлением является Microsoft SQL Server.

Navicat for SQL Server

Navicat for SQL Server – это графический инструмент для разработки и администрирования баз данных в Microsoft SQL Server. С помощью него можно создавать, редактировать и удалять любые объекты базы данных, разрабатывать и выполнять SQL запросы и инструкции, а также просматривать данные в таблицах, включая двоичные и шестнадцатеричные данные.

EMS SQL Management Studio for SQL Server

EMS SQL Management Studio for SQL Server – это комплексное решение для разработки и администрирования баз данных в Microsoft SQL Server. Разработкой занимается компания EMS, которая специализируется на разработке инструментов администрирования баз данных и приложений для управления данными. У нее много инструментов для работы с разными СУБД.

DataGrip

DataGrip – это универсальный инструмент для работы с базами данных, он умеет работать с Microsoft SQL Server, PostgreSQL, MySQL, Oracle, Sybase, DB2 и другими. Разработчиком DataGrip выступает JetBrains.

SQL Enlight

SQL Enlight – еще одно приложение для разработки T-SQL кода. Разработкой занимается компания Ubitsoft.

SQLCMD

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

Oracle Database

Oracle Database – это система управления базами данных от компании Oracle. Это также очень популярная СУБД, и также среди крупных компаний.

Инструментов для работы с Oracle Database также много, вот некоторые из них.

Oracle SQL Developer

Oracle SQL Developer – это стандартный, бесплатный и основной инструмент для разработчика баз данных Oracle.

Разработкой занимается компания Oracle. С помощью Oracle SQL Developer можно разрабатывать инструкции на PL/SQL и выполнять SQL запросы.

SQL Navigator for Oracle

SQL Navigator for Oracle – это удобный и не менее популярный инструмент для работы с Oracle Database.

Navicat for Oracle

Navicat for Oracle – это инструмент для разработки и администрирования баз данных Oracle Database. Этот инструмент имеет широкий набор функций для облегчения управления данными, таких как инструмент моделирования данных, синхронизация данных, импорт и экспорт данных.

EMS SQL Management Studio for Oracle

EMS SQL Management Studio for Oracle – это комплексное решение для разработки и администрирования баз данных Oracle Database. Разработкой занимается компания EMS, продукты которой я уже упоминал сегодня.

dbForge Studio for Oracle

dbForge Studio for Oracle – еще один продукт компании Devart, который предназначен для разработки и обслуживания баз данных Oracle Database, он также имеет очень мощный функционал.

MySQL

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

Для работы с MySQL существует очень много инструментов, вот самые популярные и функциональные.

MySQLWorkbench

MySQL Workbench – это основной и стандартный инструмент для работы с MySQL.

Он позволяет осуществлять разработку на SQL и администрировать MySQL сервер.

PHPMyAdmin

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

  • Страница продукта – https://www.phpmyadmin.net/
  • Пример установки PHPMyAdmin на Linux Mint

Navicat for MySQL

Navicat for MySQL – это инструмент для администрирования и разработки баз данных MySQL и MariaDB. Navicat for MySQL позволяет подключаться и работать с базами данных в MySQL и MariaDB одновременно.

dbForge Studio for MySQL

dbForge Studio for MySQL – это мощное решение для разработки и управления базами данных MySQL и MariaDB. Данный инструмент позволяет создавать и выполнять SQL запросы, разрабатывать и отлаживать процедуры и функции, а также управлять объектами баз данных MySQL с помощью удобного графического пользовательского интерфейса.

EMS SQL Management Studio for MySQL

EMS SQL Management Studio for MySQL – это еще одно комплексное и мощное решение от компании EMS, на этот раз для разработки и администрирования баз данных MySQL. Данный инструмент содержит все необходимые компоненты для работы с MySQL: редактор SQL запросов, средство импорта, экспорта и сравнения данных и много других, предназначенных не только для разработчиков, но и для администраторов и аналитиков данных.

SQL Maestro for MySQL

SQL Maestro for MySQL – это еще один инструмент разработки и администрирования баз данных MySQL и MariaDB.

PostgreSQL

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

Для работы с PostgreSQL можно использовать следующие инструменты.

pgAdmin

pgAdmin – это основное, стандартное средство для разработки баз данных PostgreSQL, которое распространяется бесплатно.

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


EMS SQL Management Studio for PostgreSQL

EMS SQL Management Studio for PostgreSQL – это комплексное решение для разработки и администрирования баз данных PostgreSQL. Данный инструмент так же, как все остальные продукты компании EMS, имеет очень широкий функционал от простого редактора SQL запросов до инструмента сравнения данных.

Navicat for PostgreSQL

Navicat for PostgreSQL – это простой графический инструмент для разработки баз данных PostgreSQL. Он позволяет писать и выполнять SQL запросы любой сложности.

dbForge Studio for PostgreSQL

dbForge Studio for PostgreSQL – это еще один мощный инструмент от компании Devart, на этот раз для работы с PostgreSQL. Он позволяет разрабатывать и выполнять запросы, редактировать код в удобном интерфейсе, формировать отчеты, модифицировать данные, а также осуществлять импорт и экспорт данных.

psql

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

DataGrip

Также осуществлять разработку баз данных PostgreSQL можно и с помощью уже упомянутого в этой статье универсального инструмента DataGrip от компании JetBrains.

Выводы

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

Основы создания баз данных MySQL

Дельфины всегда вызывали доверие у людей. Они ассоциируются у нас с добротой и радостью. Хоть дельфин и является символом MySQL , но это никак не объясняет той популярности, которой она пользуется во всем мире:

Согласно актуальной статистике MySQL занимает первое место по распространенности в интернете среди всех систем реляционных БД.

Особенности MySQL

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

Особенности СУБД MySQL :

  • Чаще всего используется в качестве удаленного сервера;
  • Включает в себя большое количество типов таблиц;
  • Поставляется со специальным типом EXAMPLE , показывающим принцип создания новых таблиц;
  • Высокая степень масштабируемости за счет поддержки большинства популярных платформ;
  • Открытый исходный код – благодаря этому данная СУБД постоянно совершенствуется и модернизируется множеством разработчиков по всему миру;
  • Создано большое количество API , обеспечивающих взаимосвязь MySQL c основной частью всех программных языков;
  • Максимальный размер файла таблицы базы данных ограничивается лишь возможностями используемой операционной системы.

У ближайшего конкурента MySQL системы MS SQL Server в бесплатной редакции Express ограничение на размер базы данных составляет 10 ГБ.

  • Последняя версия СУБД 5.7.5m15 ( тестовая ) вышла в сентябре 2014.

Создание базы данных MySQL

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

Среда PHPMyAdmin является одной из самых популярных оболочек для работы с MySQL . Ее интерфейс во многом облегчает администрирование баз данных.

Для создания базы данных MySQL через PHPMyAdmin делаем следующее:

  • Заходим в оболочку;
  • Переходим на вкладку « Базы данных »;
  • В первое поле вводим название создаваемой базы данных, а из выпадающего списка выбираем нужную кодировку. В нашем случае это utf8_genegal_ci .

Длина имени базы данных не должна превышать 64 символа.

  • Затем нажимаем на кнопку « Создать »:
  • После этого имя созданной БД MySQL должно появиться в списках слева и внизу:

Теперь создадим в нашей базе данных первую таблицу. Делаем следующее:

  • В списке слева находим имя нашей базы данных и нажимаем на него:
  • В следующем окне вводим название таблицы и задаем количество столбцов;
  • Затем нажимаем на кнопку « Ok ».

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

  • Следующим шагом задаем структуру нашей таблицы. Прописываем имена и типы данных, которые будут храниться в столбцах таблицы;
  • После этого нажимаем на кнопку « Сохранить »:
  • Таблица нашей БД MySQL создана и готова для заполнения данными:

Но это не единственный способ, как можно создать базу данных в PHPMyAdmin . Аналогичный эффект можно получить, если воспользоваться SQL запросом. Для этого применяется команда CREATE . Ее синтаксис:

  • IF NOT EXISTS – служит для отслеживания уникальности имени базы данных. Если не указывать этот параметр, то в случае создания базы с одинаковым названием может возникнуть ошибка выполнения запроса;
  • db_name – указывается имя создаваемой базы данных;
  • CHARACTER SET charset – устанавливается кодировка базы данных. Если не указано, то используется значение по умолчанию;
  • COLLATE collation – задается порядок сортировки данных. Необязательный параметр.

Теперь создадим базу данных с помощью SQL запроса через оболочку PHPMyAdmin :

  • Переходим на вкладку « SQL »;
  • В появившемся окне редактора вводим запрос на создание базы данных;
  • Или жмем на иконку « Окно запроса ». Она находится слева над списком баз данных:
  • Внизу нажимаем на « Ok »:
  • После этого название нашей базы данных отобразится в списке слева:

Для удаления sql базы данных используйте команду DROP DATABASE «my_db» .

  • Запрос для создания базы данных с указанием необязательных параметров будет выглядеть следующим образом:

Настройка резервного копирования базы данных

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

Настраиваем резервное копирование базы данных в PHPMyAdmin . Порядок действий:

  • В списке слева выбираем нужную нам базу данных;
  • Жмем на вкладку « Экспорт »;
  • Нажимаем « Ок ».

Если в разделе « Способ экспорта » выбрать значение « Обычный », то перед вами раскроется большое окно с множеством параметров для настройки:

Теперь попытаемся восстановить сохраненную копию базы. Но для начала удалим уже существующий экземпляр. Переходим во вкладку « Операции » и нажимаем ссылку « Удалить базу данных »:

Для восстановления базы MySQL в PHPMyAdmin переходим на вкладку « Импорт ». В разделе « Импортируемый файл » в зависимости от места, где вы сохраняли копию базы данных, выбираем источник. После этого жмем на кнопку « ОК », расположенную в нижней части экрана:

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

Сжатие баз данных в MySQL

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

Также для уменьшения размеров базы данных рекомендуется сохранять ее резервные копии в виде архивов. Сжатие ( компрессия ) резервных копий настраивается в одноименном пункте на вкладке « Экспорт » в разделе « Вывод »:

Еще одним способом уменьшения размера БД MySQL является следующий набор действий:

  • Создание дампа ( копии ) через командную строку с использованием команды mysqldump ;
  • Удаление всех баз данных;
  • Остановка всех службы MySQL ;
  • Последующее восстановление удаленных баз данных из дампа:

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

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

Как видите, MySQL является оптимальной СУБД для построения движков на основе php. А PHPMyAdmin – основным средством администрирования баз данных MySQL в интернете.

NoSQL базы данных

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

В последнее время наметились 4 тренда (тенденции) в развитии технологий хранения данных:

1) увеличение объемов хранимых данных. Сегодня хранилища данных достигли невероятных размеров. Только за 2009 и 2010 годы в базах было сохранено больше информации, чем за всю предыдущую историю человечества;

2) взаимосвязанность данных. Информация перестала быть изолированной. Каждый кусочек знаний как-то связан с данными в других хранилищах информации. Страницы в интернете ссылаются на другие страницы. Тэги связывают помеченную информацию из разных источников и т.д.;

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

4) архитектура. В 80-х годах прошлого века типичная архитектура использовала один большой компьютер (mainframe) и одну базу данных. В 90-х распространение получила клинт-серверная архитектура. В новом веке активно используются web-сервисы, каждый со своей базой данных, и другие распределенные решения. Оказалось, что в таких условиях у реляционных баз данных резко падает производительность. И если для большинства web-сайтов производительности еще хватает, то для таких приложений как современные социальные сети или поисковые сервисы SQL базы данных оказались несостоятельны.

Существует четыре категории NoSQL БД:

1) Key-Value (Ключ-Значение) базы данных. Это очень простые по своей идее хранилища. Фактически это очень большие хэш-таблицы, где каждому ключу поставлено в соответствие значение. Такие базы могут очень быстро оперировать колоссальными объемами информации, но они имеют серьезные ограничения в языке запросов (например, Dynomite, Voldemort, Tokyo, Redis);

2) клоны BigTable. BigTable — это база данных разработанная компанией Google для собственных нужд. Эта база представляет собой большую таблицу с тремя измерениями: колонки, строки и временны’е метки. Такая архитектура позволяет добиться очень высокой производительности, кроме того, она хорошо масштабируется на множество компьютеров. Но это не реляционная база, и она не поддерживает многие возможности реляционных баз. В частности в BigTable нет операции объединения Join, нет сложных запросов и т.д. Компания Google не распространяет BigTable, поэтому на рынке появилось несколько независимо разработанных клонов этой базы (например, Hadoop, Hypertable и Cassandra);

3) документо-ориентированные базы данных. Такие базы немного напоминают Key-Value базы, но в данном случае, база данных знает, что из себя представляют значения. Обычно, значением является некоторый документ или объект, к структуре которого можно делать запросы (например, CouchDB и MongoDB);

4) базы данных, построенные на графах. Такие базы ориентированы на поддержку сложных взаимосвязей между объектами, и основываются на теории графов. Структура данных в таких базах представляет собой набор узлов, связанных между собой ссылками. При этом и узлы и ссылки могут обладать некоторым количеством атрибутов (например, Neo4j, AllegroGraph, Sones graphDB).

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Сдача сессии и защита диплома — страшная бессонница, которая потом кажется страшным сном. 8769 — | 7143 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

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