Зачем выбирать NoSQL — почему успешные предприятия доверяют NoSQL

Чтобы наилучшим образом объяснить, что такое NoSQL, в этой статье мы рассмотрим следующие вопросы:

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

Технология баз данных NoSQL позволяет хранить информацию в документах JSON, а не в столбцах и строках, как это делается в реляционных БД. Сам термин NoSQL при этом означает не «вообще без SQL», а «не только SQL». То есть, с одной стороны, база данных NoSQL на основе JSON может хранить и извлекать данные совершенно не используя SQL; с другой – в такой БД можно объединить гибкость JSON с мощностью SQL, таким образом сочетая лучшие свойства того и другого. Базы данных NoSQL отличаются гибкостью, масштабируемостью и способностью быстро реагировать на потребности современного бизнеса в области управления данными. Ниже приведены четыре наиболее популярных типа баз данных NoSQL:

Так называемый «пользовательский опыт» (UX, user experience), то есть характер взаимодействия пользователя с продуктом и пользовательские впечатления от такого взаимодействия, быстро стал важнейшим конкурентным преимуществом на рынке, знаменуя колоссальные перемены в мире бизнеса. В ходе этой самой настоящей революции предприятия взаимодействуют в цифровом формате не только с клиентами, но и с собственными сотрудниками, партнерами, поставщиками и даже со своими продуктами. Это взаимодействие происходит в беспрецедентных масштабах и реализуется с помощью Интернета и других технологий XXI века. Основу «революции NoSQL» составляют приложения, которые используются той или иной компанией для работы с большими данными, ее облако, продукты для мобильных устройств, соцсети и приложений для Интернета вещей (IoT-приложений).

Чем же эти приложения отличаются от традиционных корпоративных ERP-систем, приложений для HR и финансового учета? Они должны:

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

Так, компании из списка Forbes Global 2000 стремительно внедряют базы данных NoSQL для обеспечения работы своих критически важных приложений. В их числе:

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

• Масштабирование для поддержки тысяч и даже миллионов пользователей

• Удовлетворение требований UX-дизайна и обеспечение неизменно высокой производительности

• Поддержание доступа 24 часа в сутки и 7 дней в неделю

• Поддержка множества различных элементов (вещей) с различными структурами данных

• Поддержка обновлений аппаратного/программного обеспечения, генерация различных данных

• Поддержка непрерывных потоков данных в реальном времени

• Хранение неструктурированных или слабоструктурированных данных, генерируемых клиентами

• Хранение различных типов данных из разных источников в одном месте

• Хранение данных, генерируемых тысячами/миллионами клиентов/вещей

• Масштабирование по запросу для поддержки большего числа клиентов и хранения большего объема данных

• Работа с приложениями в глобальном масштабе с клиентами по всему миру

• Минимизация затрат на инфраструктуру, ускорение выхода на рынок

• Создание оффлайн-приложений, работающих автономно и не требующих подключения к сети

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

• Поддержка нескольких мобильных платформ с помощью единого бэкенда

Некоторые реляционные БД называют «базами данных SQL», поскольку в них для извлечения необходимой информации используется SQL (structured query language, то есть «язык структурированных запросов»). SQL появился в 1979 году, но и сегодня используется разработчиками и аналитиками данных по всему миру для поиска и составления отчетов по данным, хранящимся в реляционных системах наподобие Oracle.

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

Базы данных NoSQL появились в результате стремительного роста интернета и появления веб-приложений. В 2006 году корпорация Google выпустила систему Bigtable, а в 2007 году Amazon представила Dynamo. Эти базы данных были созданы для удовлетворения нового набора корпоративных требований: гибкой разработки, удовлетворения меняющихся требований и отказа от преобразования данных.

Чтобы сохранять конкурентоспособность в современной цифровой экономике, ориентированной на пользовательский опыт, предприятиям приходится внедрять инновации – и делать это быстрее, чем когда-либо прежде. А поскольку эти инновации основаны на разработке современных веб-, мобильных и IoT-приложений, то и разработчики, в свою очередь, создают приложения и сервисы в более сжатые сроки. Скорость и гибкость оказываются крайне важны, поскольку такие приложения развиваются гораздо быстрее, чем устаревшие приложения, такие как ERP-системы. Реляционные БД в данном случае представляют собой главное узкое место, поскольку из-за своей фиксированной модели данных они не слишком хорошо поддерживают гибкую разработку.

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

База данных NoSQL, напротив, в полной мере поддерживает гибкую

разработку и не предполагает фиксированной модели данных.

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

Приложения и сервисы моделируют данные как объекты (пример: объект-пользователь «сотрудник»), многозначные данные – как коллекции (пример: роли), а связанные данные – как вложенные объекты или коллекции (пример: менеджер). Реляционные же БД моделируют данные как таблицы из строк и столбцов, связанные данные – как строки в разных таблицах, многозначные данные – как строки в одной таблице.

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

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

Хранение резюме потребует от приложения вставить шесть строк в три таблицы, как показано на Рисунке 3.

А его чтение потребует от приложения считывания шести строк из трех таблиц, как показано на Рисунке 4.

При этом в документоориентированной базе данных, являющейся, напомним, одним из типов БД NoSQL, форматом для хранения данных де-факто является JSON. К счастью, этот же формат де-факто служит стандартом потребления и производства данных для веб-, мобильных и IoT-приложений. JSON не только «снимает» это несоответствие между объектной и реляционной моделями, но и устраняет лишние затраты на фреймворки для объектно-реляционного отображения данных, а также упрощает разработку приложений: объекты считываются и записываются без пресловутого «расщепления» (т. е. один объект может быть считан или записан как один документ), как показано на Рисунке 5.

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

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

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

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

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

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

Все большая доля взаимодействия между предприятием и клиентом сегодня происходит онлайн через мобильные или веб-приложения, в связи с чем доступность становится крайне существенным аспектом – если не главным. Эти критически важные для бизнеса приложения должны быть доступны 24 часа в сутки и 7 дней в неделю – без исключений. Для реляционных БД обеспечение доступа в режиме 24/7 – задача сложная: они развернуты на одном физическом сервере или используют кластеры с общим хранилищем. Если откажет единственный сервер, на котором развернута БД, или – в случае кластерной организации – выйдет из строя общее хранилище, база данных окажется недоступной.

В отличие от реляционных хранилищ, распределенная БД NoSQL разделяет и распределяет данные по нескольким копиям БД без использования общих ресурсов. Кроме того, копии данных могут передаваться в один или несколько экземпляров БД для повышения доступности (межкластерная репликация). Если для реляционных БД, таких как Oracle, для репликации данных требуется специальное программное обеспечение (например, Oracle Active Data Guard), то у баз данных NoSQL такого ограничения нет: копирование встроено и автоматизировано. А автоматическое преодоление отказа гарантирует, что в случае сбоя одного из узлов БД сможет продолжить считывать и записывать данные, отправляя запросы на другой узел.

По мере перехода клиентов в «онлайн» возникает необходимость обеспечить доступность сразу в нескольких странах и/или регионах. Развертывание базы данных в нескольких центрах обработки данных не только повышает доступность и упрощает восстановление после сбоев, но и увеличивает производительность: все операции чтения и записи могут выполняться на ближайшем центре обработки данных, благодаря чему снижается время отклика.

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

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

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

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

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