Брайан Раш, старший инженер-программист, Capax Global

NoSQL — это запрашиваемые данные; он просто решает проблемы по-другому, а в некоторых случаях и лучше…

Как разработчиков программного обеспечения, нас просят построить систему, которая решает целый ряд проблем. С опытом инженеры будут сталкиваться с похожими проблемами в разных проектах или даже в разных компаниях. Иногда мы подходим к решению проблемы с помощью проверенной, верной и проверенной модели. Думаем: зачем изобретать велосипед? В этой статье я попытаюсь расширить ваше представление о традиционных системах управления реляционными базами данных (RDBMS). В частности, о том, как можно использовать базы данных NoSQL для решения проблем, которые традиционно решались с помощью реляционной базы данных.

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

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

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

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

Бизнес-проблема

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

На этапе исследования и разработки мы определили некоторые основные качества и характеристики каталога продукции:

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

Мы могли бы пройти этап исчерпывающего анализа и разработать реляционную модель, в которой все продукты и атрибуты могут вписываться в четко определенную реляционную схему. Это выполнимо, но сложно. Чтобы изменения производителя не оказали серьезного влияния на схему продукта, вариантов в реляционном мире немного. Лучшим реляционным инструментом была бы модель Entity-attribute-value (EAV), которая тяжела и имеет серьезные недостатки в производительности. Это тот момент в проекте, что если мы рассмотрим подход NoSQL, мы увидим очень значительную ценность.

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

  • Мы можем создавать документы, представляющие каждый из наших продуктов без схемы. Это означает, что по мере изменения наших продуктов и атрибутов могут изменяться и наши документы; без суеты и сложностей.
  • Все наши продукты по-прежнему можно легко запросить. В частности, Cosmos DB поддерживает запросы к документам с использованием стандартного синтаксиса SQL.
  • Базы данных NoSQL и Cosmos DB позволяют масштабировать чрезвычайно большие объемы данных одним нажатием кнопки.
  • Базы данных NoSQL работают быстро, а у Cosmos даже есть гарантированные соглашения об уровне обслуживания.
  • Можно утверждать, что несоответствие объектно-реляционного импеданса решается за счет использования возможностей NoSQL.

Конкретные примеры

Давайте немного углубимся в детали нашего каталога продуктов, чтобы показать, какие преимущества имеет хранение и запросы нашего каталога документов в базе данных NoSQL, такой как CosmosDB. Возьмите этот пример JSON-представления продукта:

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

Первое важное преимущество NoSQL заключается в том, что подобные изменения не создают проблем. В мире NoSQL наш каталог продуктов может быть без схемы. У этого есть явное преимущество перед РСУБД, так как когда появляется новый атрибут options, нам не нужно менять наше хранилище данных, чтобы хранить эти данные. Точно так же эти новые данные сразу доступны для запроса. В случае Azure Cosmos DB мы можем запросить этот продукт с помощью API SQL, используя очень похожий синтаксис SQL.

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

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

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

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

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

  • Интернет вещей и телематические системы
  • Системы розничной торговли и маркетинга
  • Игры
  • Социальные приложения
  • Механизмы рекомендаций

Резюме

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

Просмотреть все сообщения от brianmrush

Опубликовано 24 октября 2018 г.