5 важнейших

критериев оценки
баз данных NoSQL
Июнь 2018 г.

Документ переведён и адаптирован

в Яндекс.Облаке в январе 2020 г.
Содержание

Введение 1
Модель данных 2
Документоориентированная модель 2
Графовая модель 3
Модели «ключ-значение» и «семейство столбцов»
(wide column) 3
Модель запросов 3
Документоориентированная база данных 4
Графовая база данных 4
Базы данных «ключ-значение» и «семейство
столбцов» 5
Согласованность данных и транзакционная модель 5
Согласованные системы 6
Системы согласованные в конечном счете 6
API-интерфейсы 7
Идиоматические драйверы 7
RESTful API-интерфейсы 7
SQL-подобные API-интерфейсы 8
Визуализация и отчетность 8
Коммерческая поддержка, ресурсы сообщества
разработчиков, независимость от поставщика 8
Коммерческая поддержка 9
Ресурсы сообщества разработчиков 9
Заключение 11
Мы можем помочь вам – управляемый сервис от
Яндекс.Облака 12
Преимущества 12
Ресурсы 12
Введение
Реляционные базы данных прочно Необходимо принимать во внимание следующие
зарекомендовали себя во многих компаниях, и на факторы:
то есть основания. Реляционные базы данных
§ Разработчики работают с приложениями,
лежат в основе существующих приложений,
создающими новые, быстро меняющиеся типы
отвечающих текущим потребностям бизнеса; они
данных — структурированные,
поддерживаются обширной экосистемой
полуструктурированные,
инструментов; также существует обширный
неструктурированные и полиморфные данные,
контингент профессионалов, обладающих
причем в огромных объемах.
квалификацией в области внедрения и
обслуживания таких систем.
§ Каскадная модель разработки с циклом от 12
до 18 месяцев давно осталась в прошлом.
Тем не менее, компании все чаще пытаются
Современные разработчики работают
подыскать альтернативу унаследованной
небольшими командами в рамках гибких
реляционной инфраструктуре. В каких-то случаях
спринтов, отгружая код небольшими
это стремление носит технический характер —
итерациями 1-2 раза в неделю, а некоторые —
например, когда перед компаниями встает задача
даже по нескольку раз в день.
обработки новых, мультиструктурированных
типов данных, не вписывающихся в табличную
§ Приложения, которые когда-то
модель реляционной БД. В других случаях
предназначались для ограниченного круга
требуется уровень масштабирования, выходящий
пользователей, сегодня предоставляются уже
за пределы возможностей существующих систем.
как услуги. Такие общедоступные сервисы
В других случаях компании пытаются найти
должны работать бесперебойно, быть
жизнеспособные альтернативы дорогостоящему
доступны с устройств разного типа и
проприетарному программному и аппаратному
поддерживать глобальное масштабирование,
обеспечению для СУБД. Третья причина —
которое допускает распределенное хранение
востребованность высоких темпов и гибкости
данных в непосредственной близости к
разработки: компании стремятся быстрее
пользователям с целью снижения задержки
приспособится к условиям на рынке путем
сигнала и соблюдения законодательства о
применения гибких методологий разработки,
суверенитете данных.
процессов DevOps и микросервисов.
§ Современные компании переходят к
Команды разработчиков оказывают сильное использованию масштабируемых архитектур
влияние на процесс выбора технологий. на базе открытого программного обеспечения,
Сообщество разработчиков, как правило, склонно работающего не на крупномасштабных
считать, что реляционная табличная модель монолитных серверах и инфраструктурах
данных не очень хорошо согласуется с хранения данных, а на коммерчески доступных
потребностями приложений. серверах и облачных вычислительных
платформах.

1
По сравнению с реляционными базами данных,
многие системы «NoSQL» имеют несколько общих
ключевых характеристик, включая более гибкую
модель данных, более высокую
масштабируемость и отличную
производительность. Тем не менее, большая часть
NoSQL-решений также лишена фундаментальной
основы, благодаря которой реляционные базы
данных принесли столько пользы для множества
поколений приложений — в них, как правило,
отсутствует поддержка выразительного языка
запросов, вторичных индексов и сильной
согласованности данных. По факту термин
«NoSQL» зачастую используется как синоним для
нетабличных баз данных любого рода. Как мы
увидим далее, этот термин определен нечетко и
имеет слишком широкий смысл, чтобы быть
полезным. Специалисты, которые его используют,
часто упускают из вида те компромиссы, на
которые пришлось пойти разработчикам баз
данных NoSQL для достижения требуемой
гибкости, масштабируемости и
производительности.
В данной статье мы постараемся помочь вам
сориентироваться в сложной и быстро
развивающейся области систем NoSQL баз
данных. Мы расскажем о пяти важнейших
измерениях, которые вы сможете использовать
для выбора оптимальной СУБД, отвечающей
требованиям ваших приложений и бизнеса в
целом.
Модель данных
Основным отличием NoSQL баз данных от
реляционных является используемая в них модель
данных. Несмотря на то, что существуют уже
десятки NoSQL баз данных, в целом они делятся
на следующие три категории:
Документоориентированная
модель
В то время как реляционные БД хранят данные в
строках и столбцах, документоориентированные
базы данных хранят данные в документах.
Эти документы обычно используют JSON-
подобную структуру (JavaScript Object Notation) —
популярный среди разработчиков формат
2
представления данных. Документы обеспечивают
интуитивно понятный и естественный способ
моделирования данных, который тесно связан с
объектно-ориентированным программированием
– каждый документ фактически является
объектом. Документы содержат одно или
несколько полей, при этом каждое поле содержит
типизированное значение, например, строку,
дату, двоичное значение, десятичное значение
либо массив. Вместо того чтобы сохранять запись
в нескольких столбцах и таблицах, устанавливая
связи между данными при помощи внешних
ключей, каждая запись и связанные (т.е.
ассоциированные) с ней данные обычно хранятся
все вместе в одном иерархическом документе.
Данная модель повышает скорость разработки,
упрощает доступ к данным, и во многих случаях
устраняет необходимость в дорогостоящих
операциях JOIN и сложных транзакциях с
участием нескольких записей.
В документоориентированной БД схема —
понятие динамическое: каждый документ может
содержать разные поля. Такая гибкость может
быть особенно полезна при моделировании
неструктурированных и полиморфных данных.
Это также упрощает процесс развития
приложений в течение их жизненного цикла,
например, позволяет легко добавлять новые поля.
Кроме того, некоторые
документоориентированные БД поддерживают
выразительные языки запросов, которые, по
мнению разработчиков, являются характерным
признаком реляционных баз данных. В частности,
запросы к данным могут включать любые
комбинации полей документа, а разнообразие
вторичных индексов реализует эффективные пути
доступа, позволяющие поддержать практически
любые варианты запросов.
Особенности применения:
Документоориентированные БД — это
общецелевые базы данных, имеющие широкий
спектр применений в силу гибкости модели
данных, возможности выполнения запросов по
любому полю, а также естественному
соответствию между документной моделью
данных и объектами в современных языках
программирования.
Примеры: MongoDB и CouchDB.
Графовая модель
В графовых базах данных информация
представляется в виде графовых структур,
характеризующихся узлами, ребрами и
свойствами. По сути данные моделируются в виде
сети взаимосвязей между конкретными
элементами. Несмотря на то, что графовая
модель не всегда интуитивно понятна и порой
требуется время, чтобы в ней разобраться, она
может пригодиться для выполнения
определенных видов запросов. Основная
привлекательность этой модели в том, что она
упрощает процесс моделирования сущностей и
отслеживание связей между сущностями в
приложении.
Особенности применения: Графовые базы данных
полезны в тех случаях, когда прослеживание
взаимоотношений между сущностями является
основополагающей задаей приложений, —
например, при отслеживании связей в
социальных сетях, планировании сетевых
топологий или цепочек поставок.
Примеры: Neo4j и AWS Neptune.
Модели «ключ-значение»
и «семейство столбцов» (wide
column)
С точки зрения модели данных хранилища «ключ-
значение» — это самый примитивный вид NoSQL
баз данных. Каждый элемент базы данных
хранится в виде ключа (т.е. имени атрибута) — и
его значения. Значение, однако, полностью
непрозрачно для системы: данные можно
запросить только по ключу. Эта модель может
пригодится для представления полиморфных и
неструктурированных данных, поскольку такая
база данных не накладывает заранее никакой
схемы на набор пар «ключ-значение».
Хранилища семейств столбцов, также
называемые «хранилищами с широкими
столбцами» (wide column), используют, для
хранения данных, разреженное, распределенное
многомерное представление с сортировкой.
Каждая запись может отличаться по числу
хранимых в ней столбцов. Столбцы могут быть
сгруппированы для обеспечения доступа по
3
семействам столбцов. Также столбцы могут быть
распределены по нескольким семействам
столбцов. Данные извлекаются по первичному
ключу, существующему для каждого семейства
столбцов.
Особенности применения: Хранилища «ключ-
значение» и хранилища с широкими столбцами
имеют узкий круг применения — это именно те
случаи, когда требуется запрос данных по
единственному ключу. Привлекательность такого
рода систем заключается в их
производительности и масштабируемости. Их
легко оптимизировать благодаря простоте схем
доступа к данным и непрозрачности значений
данных.
Примеры: Redis и AWS DynamoDB (хранилища
«ключ-значение»).
HBase и Cassandra (хранилища семейств
столбцов).
ВЫВОДЫ
§ Для всех приведенных моделей характерна
гибкая схема данных.
§ Модели данных для хранилищ «ключ-значение»
и хранилищ семейств столбцов непрозрачны
для системы — запрос может осуществляться
только по первичному ключу.
§ Документная модель данных имеет наиболее
широкую применимость.
§ Документная модель данных является
наиболее естественной и продуктивной,
поскольку она напрямую преобразуется в
объекты на современных объектно-
ориентированных языках программирования.
§ Модель хранилищ с широкими столбцами
обеспечивает более детальный доступ к
данным по сравнению с моделью «ключ-
значение». Однако она дает меньшую гибкость,
чем документная модель данных.
Модель запросов
Каждое приложение имеет свои собственные
требования к запросу. В некоторых случаях может
быть приемлема очень простая модель запроса, в
которой приложение обращается к записям
исключительно по их первичному ключу.
Однако для большинства приложений важна
возможность выполнения запросов по различным
значениям в каждой записи. Например, если
приложение хранит данные о клиентах, в нем
может использоваться поиск не только
определенных клиентов, но и конкретных
компаний. Также может потребоваться поиск
клиентов по заданным количественным
характеристикам, а также агрегирование суммы
покупок клиентов по почтовому индексу или
региону.
Кроме того, приложения часто обновляют записи,
изменяя одно или несколько полей. Чтобы
удовлетворять этим требованиям, СУБД должна
иметь возможность запрашивать данные,
используя вторичные индексы. В таких случаях
документоориентированная СУБД зачастую
оказывается наиболее подходящим решением.
Документоориентированная база
данных
Документоориентированные СУБД как правило
предоставляют функционал для запроса и
обновления любого поля в документе, однако
такого рода возможности разнятся в зависимости
от СУБД. Некоторые продукты, например,
MongoDB, предоставляют богатый набор
возможностей индексирования, позволяющих
оптимизировать широкий спектр запросов
(включая текстовые, геопространственные,
составные, разреженные, TTL-запросы (Time-To-
Live)), поддерживать уникальные индексы и т.д.
Кроме того, некоторые из этих продуктов
предоставляют функционал локальной (in-place)
аналитики, не требующей репликации в
специализированные аналитические или
поисковые системы. Например, MongoDB
предоставляет разработчикам систему MongoDB
Aggregation Framework, позволяющую создавать
сложные технологические конвейеры для анализа
и преобразования данных, включая фасетный
поиск, использование оператора JOIN,
геопространственную обработку и обход графов.
Данная система также предоставляет
собственные возможности визуализации при
помощи диаграмм MongoDB Charts, а также
коннекторы для подключения Apache Spark и BI-
инструментария. Для обновления данных
MongoDB предоставляет выразительные методы
4
обновления, позволяющие разработчикам
выполнять сложные манипуляции с
соответствующими элементами документа (в том
числе, с элементами, находящимися во
вложенных массивах) — все это в рамках единой
транзакционной операции update.
Графовая база данных
Графовые СУБД, как правило, предоставляют
полнофункциональные модели запросов,
позволяющие опрашивать простые и сложные
связи между данными и делать прямые и
косвенные выводы о характере данных в системе.
Анализ типа связей, как правило, дает очень
хорошие результаты в этих системах, при этом
другие типы анализа могут оказаться менее
оптимальными. В результате графовые базы
данных редко используются в операционных
приложениях более общего назначения. Вместо
этого они объединяются с обычными
документоориентированными или реляционными
базами данных, где отвечают за материализацию
именно тех структур данных и запросов, где
использование графов может быть особенно
полезным.
Чтобы немного обуздать всю ту сложность,
которая возникает в результате использования
множества технологий хранения данных, отрасль
движется в направлении концепции
«мультимодельных» баз данных. В таких проектах
используется сразу несколько моделей данных и
типов запросов в рамках единой СУБД-
платформы, удовлетворяя таким образом всему
разнообразию требований со стороны
приложений.
Например, MongoDB поддерживает
$graphLookup в качестве стадии агрегирования,
позволяющей вести обработку графов внутри
базы данных. $graphLookup позволяет
эффективно обходить все графы, деревья и
иерархические данные и затем выявлять
закономерности и ранее не идентифицированные
связи.
Базы данных «ключ-значение» и
«семейство столбцов»
Эти системы предоставляют возможность
получать и обновлять данные, используя
единственный ключ или ограниченный набор
ключей. Для выполнения запроса по другим
значениям пользователям рекомендуется
создавать и поддерживать свои собственные
индексы. Некоторые продукты поддерживают
ограниченный функционал вторичных индексов,
однако с определенными оговорками. Для
обновления данных в таких системах может
потребоваться несколько циклов обращения к
данным: сначала найти запись, затем обновить ее,
и затем обновить индекс. В этих системах
обновление может быть реализовано как полная
перезапись всей записи на клиенте, вне
зависимости от того, изменился ли только один
атрибут или вся запись целиком.
ВЫВОДЫ
§ Самое большое различие между NoSQL базами
данных заключается в том, насколько
эффективно выполнение запросов к данным.
§ Документоориентированные БД предоставляют
наиболее полный функционал запросов, что
позволяет им взаимодействовать с широким
спектром операционных и аналитических
приложений в режиме реального времени.
§ Хранилища «ключ-значение» и «семейство
столбцов» обеспечивают единый механизм
доступа к данным, а именно, по первичному
ключу. Такой доступ может быть очень
быстрым, но предлагаемый при этом
функционал запросов чрезвычайно ограничен.
Поэтому если необходимо выйти за рамки
базовых шаблонов запросов, то это может
потребовать дополнительных затрат на
разработку, в том числе, в контексте выработки
новых требований на уровне приложений.
5
Согласованность данных
и транзакционная модель
Большинство NoSQL-систем обычно
поддерживают несколько копий данных для
обеспечения их доступности и
масштабируемости. Такие СУБД могут применять
различные гарантии согласованности данных
между копиями. NoSQL базы данных обычно
подразделяются на сильно согласованные — либо
согласованные в конечном счете.
При использовании сильно согласованных
систем, результаты операций записи данных,
выполненных приложением, сразу же
отображаются в последующих запросах. В случае
же систем согласованных в конечном счете,
записи не всегда оказываются видны сразу:
зависит это от того, какая реплика данных
обслуживает запрос. Например, при
отображении уровней остатков товаров по
каталогу, в согласованной системе каждый
запрос будет видеть текущий уровень остатков
(т.к. остатки обновляются приложением), — а в
случае системы, согласованной в конечном счете,
уровни остатков могут оказаться неточными, если
выполнять запрос на конкретный момент
времени; однако в конце концов они станут
точными, потому что «в конечном счете» они
будут реплицированы по всем узлам кластера
базы данных. По этой причине код приложений,
как правило, несколько отличается для систем,
согласованных в конечном счете, — например,
вместо обновления остатков путем вычитания
единицы из текущего уровня остатков,
разработчики должны формулировать
идемпотентные запросы, в которых явно
указывается уровень остатков. Разработчики
также вынуждены прописывать в своих
приложениях дополнительную логику управления
для обработки потенциально устаревших или
удаленных данных.
Большая часть NoSQL-систем предлагает
гарантии атомарности на уровне отдельной
записи. Поскольку такие СУБД умеют объединять
данные, между которыми существуют связи (в
табличной схеме они бы моделировались
отдельными родительскими и дочерними
таблицами), — то атомарные операции,
затрагивающие одну запись, обеспечивают
транзакционную семантику, удовлетворяющую
требованиям целостности данных для
большинства приложений.
Тем не менее, некоторые разработчики и
администраторы баз данных за 40-летнюю
историю моделирования реляционных БД
привыкли считать, что транзакции с участием
нескольких записей являются обязательным
требованием для любой СУБД, независимо от
модели данных, на которой она построена.
Некоторые разработчики обеспокоены тем, что
несмотря на то, что транзакции с участием
нескольких документов не востребованы их
приложениями на сегодняшний день, они вполне
могут понадобиться в будущем. Также при
некоторых видах рабочих нагрузок требуется
поддержка ACID-транзакций, охватывающих
несколько записей.
Именно по этим причинам в MongoDB была
добавлена поддержка многодокументных ACID-
транзакций. Таким образом разработчикам
оказывается еще проще охватить весь спектр
вариантов использования баз данных при помощи
MongoDB. Для разработчиков все выглядит
абсолютно так же, как и при транзакционной
разработке в реляционных базах данных:
возможность использования сразу нескольких
операторов, похожий синтаксис и простота
добавления в любое приложение. Благодаря
snapshot-изоляции транзакции обеспечивают
согласованное представление данных и
выполняются по принципу «все или ничего». СУБД
MongoDB относительно уникальна в том, что она
предоставляет транзакционные гарантии на
уровне, сравнимом с традиционными
реляционными базами данных, сохраняя гибкость
и возможности масштабирования, характерные
для NoSQL баз данных.
Согласованные системы
Приложения могут предъявлять разные
требования к согласованности данных. Для
многих приложений крайне важно, чтобы данные
всегда были согласованными. Поскольку команды
разработчиков десятилетиями использовали
реляционные СУБД, основанные на модели
согласованности данных, такой подход является
более естественным и привычным для них. В ряде
других случаев согласованность в конечном счете
— это приемлемая плата за гибкость на уровне
доступности системы.
6
Документоориентированные и графовые базы
данных могут быть как согласованными, — так и
«согласованными в конечном счете». MongoDB
предоставляет настраиваемые уровни
согласованности данных. По умолчанию данные
являются согласованными — все операции записи
и чтения данных обращаются к первичной копии
данных. Также доступен вариант, когда запросы
на чтение обращаются к вторичным копиям
данных. При этом данные окажутся согласованы в
конечном счете, когда операция записи будет
синхронизирована со вторичной копией. Выбор
варианта согласованности осуществляется на
уровне запроса.
Системы согласованные
в конечном счете
В случае систем согласованных в конечном счете,
существует период времени, в течение которого
все копии данных еще не успели
синхронизироваться. Такая ситуация может быть
приемлема для приложений, занимающихся
только чтением данных, а также хранилищ,
которые меняются не так часто (например,
архивов исторических данных). Аналогичным
образом такой подход целесообразен для
сценариев интенсивной записи данных. При этом
база данных собирает информацию, например, в
виде журналов, а чтение данных будет
проводиться уже позже. Хранилища «ключ-
значение» и «семейство столбцов» обычно
являются в конечном счете согласованными.
Системы согласованные в конечном счете
должны уметь обрабатывать конфликты
обновлений на уровне отдельных записей.
Поскольку операции записи данных могут
применяться к любой копии данных, весьма
вероятно, что они будут достаточно часто
конфликтовать друг с другом, если один и тот же
атрибут будет обновляться на разных узлах.
Некоторые системы используют векторные часы
для определения порядка событий: это позволяет
гарантировать, что самая последняя операция в
случае конфликта выиграет. Тем не менее, может
оказаться, что более старое значение возможно
уже было отдано в приложение. Другие системы
сохраняют все конфликтующие значения и
перекладывают ответственность за разрешение
конфликта на пользователя. По этим причинам
операции вставки данных, как правило, работают
быстро на системах согласованных в конечном
счете. Однако в операциях обновления и
удаления данных зачастую необходимо
предусмотреть компромиссы, значительно
усложняющие логику приложения.
ВЫВОДЫ
§ Согласно требованиям большинства
прикладных программ и команд разработчиков
системы должны быть строго согласованы.
§ Различные модели согласованности
используют различные модели с точки зрения
компромиссов согласованности и доступности
данных приложений.
§ MongoDB обеспечивает несколько уровней
согласованности, которые настраиваются на
уровне запроса.
§ Системы согласованные в конечном счете
имеют ряд преимуществ с точки зрения вставки
данных. Однако операции чтения, обновления и
удаления данных при этом усложняются. Также
из-за необходимости разрешения конфликтов
при чтении, а также уплотнения данных, обычно
страдает производительность.
§ Большинство NoSQL баз данных обеспечивает
атомарность на уровне одной записи. Этого
обычно достаточно для многих приложений,
однако далеко не для всех. MongoDB
предоставляет гарантии для многодокументных
ACID-транзакций, что упрощает решение
целого ряда задач с использованием единой
платформы данных.
API-интерфейсы
Не существует единого стандарта для интерфейса
с NoSQL-системами. Каждая система
предоставляет различные конструкции и
возможности для команд прикладной разработки.
Зрелость API-интерфейса может играть
серьезную роль с точки зрения временных и
финансовых затрат, необходимых для разработки
и текущей поддержки приложений и баз данных.
7
Идиоматические драйверы
Существует несколько популярных языков
программирования, и каждый из них использует
различные парадигмы для работы с данными и
сервисами. Идиоматические драйверы создаются
командами разработчиков-экспертов по
конкретному языку. Эти специалисты отлично
разбираются в особенностях общепринятых
стилей разработки на этом языке. Польза такого
подхода еще и в том, что при этом задействуются
конкретные возможности языка
программирования, способные обеспечить
эффективность доступа к данным и их обработки.
Программистам легче выучить и затем
использовать идиоматические драйверы: при
этом сокращается время ознакомления команд
разработчиков с функционалом новой СУБД, — и
они могут быстро начать с ней работать.
Например, идиоматические драйверы
предоставляют прямые интерфейсы для задания и
получения как документов целиком, так и
отдельных полей в документах. В других типах
интерфейса, если нужно задать или получить
значение поля, то может потребоваться полное
извлечение документа с последующим его
разбором и переходом к конкретному полю.
MongoDB поддерживает идиоматические
драйверы более чем для десяти языков: Java, .NET,
Ruby, Node.js, Perl, Python, PHP, C, C++, C#,
Javascript и Scala. Десятки других драйверов
поддерживаются силами сообщества
разработчиков.
RESTful API-интерфейсы
Некоторые системы предоставляют RESTful API-
интерфейсы. Такой подход, безусловно, многим
знаком и привлекателен своей простотой, однако
ему присущи задержки, обусловленные
использованием протокола HTTP. Он также
перекладывает задачу создания интерфейса на
плечи разработчиков. Также, скорее всего, этот
интерфейс окажется несовместимым с
остальными разрабатываемыми программными
интерфейсами.
SQL-подобные API-интерфейсы системы или использовать сторонние
инструменты. Поскольку MongoDB Charts
изначально понимает документную модель
Разработчики ряда нереляционных СУБД
MongoDB, пользователи могут создавать
попытались добавить SQL-подобный уровень
диаграммы, используя данные, которые имеют
доступа к базе данных в надежде, что это
различный формат или содержат вложенные
сократит кривую обучения для тех разработчиков
документы и массивы. При этом не нужно
и администраторов, которые знакомы с SQL.
предварительно приводить данные к плоской
Важно провести оценку всех этих вариантов
табличной структуре.
реализации еще до начала серьезной разработки,
принимая во внимание следующие факторы:
ВЫВОДЫ
§ Большинство этих реализаций значительно
уступают SQL по мощи и выразительности и
§ Зрелость и функциональность API-
требуют, чтобы пользователи, работающие с
интерфейсов существенно различаются в
SQL, изучили функционально-ограниченный
разных нереляционных продуктах.
диалект языка SQL.
§ Идиоматические драйверы MongoDB
§ Средства BI, отчетности и ETL, использующие
сокращают время освоения технологий
язык SQL, не будут совместимы с диалектной
новыми разработчиками и упрощают
реализацией SQL.
разработку приложений.
§ Притом что некоторые синтаксические
§ Не все SQL-системы созданы равными.
элементы могут оказаться знакомы SQL-
Тщательно оцените SQL-подобные API-
разработчикам, этого нельзя сказать о
интерфейсы, предлагаемые нереляционными
моделировании данных. Попытка навязать
базами данных и убедитесь в том, что они в
реляционную модель любой NoSQL базе
самом деле смогут удовлетворить
данных нанесет катастрофический урон
потребностям вашего приложения и ваших
производительности и текущему
разработчиков.
обслуживанию приложений.

Визуализация и отчетность Коммерческая поддержка,

Многие компании формируют визуализацию
данных, аналитику и отчетность, используя такие
платформы BI на базе SQL, которые изначально не
способны интегрироваться с NoSQL
технологиями. Чтобы решить эту проблему,
организации обращаются к драйверам OBDC,
которые применяют индустриальные стандарты
для подключения сторонних аналитических
инструментов к NoSQL базам данных. Например,
использование коннектора «MongoDB Connector
for BI» позволяет аналитикам, исследователям
данных и бизнес-пользователям легко применять
наиболее популярные средства BI для
одновременной визуализации
полуструктурированных и неструктурированных
данных из баз MongoDB и традиционных данных
из SQL-баз. Система MongoDB Charts позволяет
пользователям быстро и легко создавать и
обмениваться визуализациями своих данных
MongoDB в режиме реального времени, без
необходимости перемещать данные в другие
ресурсы сообщества
разработчиков,
независимость от
поставщика
Выбор СУБД — это серьезная инвестиция ваших
ресурсов. После того как приложение было
построено на конкретной СУБД, его перенос на
другую СУБД является дорогостоящим, сложным
и рискованным делом.
Компании обычно инвестируют свои ресурсы в
небольшое количество базовых технологий,
чтобы иметь возможность наращивать опыт,
проводить интеграцию и развивать наработки,
которые можно будет затем успешно применять
во многих проектах. NoSQL-системы по-
прежнему являются относительно молодыми,

8
и хотя на рынке существует много вариантов,
только узкий круг технологий и поставщиков
выдержит испытание временем.
Коммерческая поддержка
При оценке базы данных пользователи должны
учитывать жизнеспособность проекта СУБД и
компании-поставщика. Важно не только, чтобы
продукт продолжил существование в будущем:
также важно иметь гарантию, что он будет
развиваться и предоставлять все новый
функционал. Еще один важный фактор — наличие
сильной, опытной службы поддержки, способной
оказывать услуги по всему миру.
Ресурсы сообщества
разработчиков
Наличие у технологии мощного сообщества
экспертов дает ей значительные преимущества,
особенно в случае СУБД. Если у СУБД мощное
сообщество пользователей, вам будет проще
найти и нанять разработчиков, уже знакомых с
продуктом. Также гораздо проще найти готовые
наработки, документацию и примеры кода, что
снижает риск для новых проектов. Это также
помогает компаниям удержать ключевые
технические кадры. Наконец, сильное сообщество
поощряет поставщиков других технологий к
развитию интеграции со своей стороны и
участию в работе экосистемы.
Независимость от поставщика
Многие организации пали в прошлом жертвой
зависимости от поставщика СУБД и не вполне
добросовестных коммерческих практик ряда
поставщиков унаследованного корпоративного
программного обеспечения. Использование
открытого программного обеспечения и
коммерчески доступного оборудования стало
палочкой-выручалочкой для многих компаний, не
избавив их от опасения, что при переходе в
облако они могут, в конечном итоге, попасть из
одной зависимости в другую.
Важно оценить систему лицензирования и
доступность любых крупных инвестиций в новое
программное обеспечение. Кроме того, важно
иметь возможность свободно запускать базу
9
данных везде, где это необходимо – на ноутбуке
разработчика на ранней стадии внедрения, на
вашей собственной инфраструктуре при
внедрении в промышленную эксплуатацию и т.д.
Также очень важна возможность использования
базы данных в качестве сервиса от любого
публичного облака.
MongoDB предоставляет разработчикам и
командам DevOps свободу загружать и запускать
базу данных на своей собственной
инфраструктуре. При использовании облачного
сервиса MongoDB Atlas, СУБД MongoDB также
доступна в виде полностью управляемого
облачного сервиса с поддержкой всех ведущих
облачных поставщиков. Где бы вы ни решили
запустить MongoDB, вы получаете полную
переносимость платформы – вы используете одну
и ту же базу кода, API-интерфейсы и инструменты
управления.
ВЫВОДЫ
§ Размер сообщества пользователей и
коммерческая стабильность поставщика
являются важным компонентом оценки
нереляционных баз данных.
§ MongoDB — одна из немногих компаний-
поставщиков нереляционных баз данных, акции
которой котируются на бирже. MongoDB
обладает самым крупным и самым активным
сообществом пользователей; группы
технической поддержки работают по всему
миру и обеспечивают круглосуточное
обслуживание; группы пользователей работают
в большинстве крупных городов; также имеется
подробная документация.
§ Вы можете запустить MongoDB на вашей
собственной инфраструктуре или в качестве
полностью управляемого облачного сервиса на
ведущих публичных облачных платформах,
в том числе в Яндекс.Облаке.
Почему именно MongoDB?
СУБД MongoDB разработана для удовлетворения
потребностей современных приложений на базе
технологической платформы, позволяющей вам:
Найти оптимальный способ работы с данными
§ Простота: Работайте с данными естественным,
интуитивно понятным способом, обеспечивая
целостность данных благодаря ACID-гарантиям
§ Быстрота: Получите отличную
производительность без больших усилий
§ Гибкость: Быстро адаптируйтесь к новым
условиям и вносите изменения
§ Универсальность: Поддержка широкого
спектра типов данных и запросов
10
Разумно разместите свои данные там, где вы
хотите
§ Доступность: Предоставляйте своим
пользователям глобально устойчивые
платформы с использованием проработанных
механизмов репликации и восстановления
после сбоев
§ Масштабируемость: Расширяйте свои
хранилища горизонтально благодаря
встроенным механизмам шардирования
§ Изоляция рабочей нагрузки: Выполнение
операционных и аналитических рабочих
нагрузок на едином кластере
§ Локальность: Размещение данных на
конкретных устройствах и в определенных
географических зонах с целью обеспечения
управляемости, класса обслуживания и
доступа с низкой задержкой
 Интеллектуальная операционная
платформа обработки данных

Найти оптимальный Разумно Свобода двигаться

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

Рисунок 1: Интеллектуальная операционная платформа обработки данных на базе MongoDB

Свобода двигаться в любом выбранном

направлении
§ Переносимость данных: База данных, которая
везде работает одинаково
§ Независимость от выбранного облака:
Используйте преимущества многооблачной
стратегии, гарантирующей независимость от
провайдера
§ Глобальный охват: Поддержка всех основных
облачных провайдеров более чем в 50
регионах
Дополнительные подробности — в руководстве
по архитектуре MongoDB (англ.яз).
Заключение
По мере развития технологического ландшафта
организации все чаще сталкиваются с
необходимостью оценки новых СУБД с целью
поддержки непрерывно меняющихся прикладных
и бизнес-требований. Рекламная шумиха вокруг
NoSQL баз данных создает определенную
неясность на рынке. Тем важнее компаниям
понимать различия между имеющимися
решениями. В этой статье мы обсудили ключевые
критерии, которые следует учитывать при оценке
таких технологий, а именно: модель данных,
модель запросов, согласованность данных и
транзакционная модель, наличие API-
интерфейсов, а также коммерческой поддержки и
мощного сообщества пользователей. Многие
компании убедились в том, что
документоориентированные базы данных, такие
как MongoDB, лучше всего удовлетворяют этим
критериям. Тем не менее, мы рекомендуем, чтобы
лица, принимающие технологические решения в
вашей компании, провели самостоятельную
оценку указанных выше факторов.

11
Мы можем помочь вам
Платформа Яндекс.Облако стала первым
официальным партнёром MongoDB в России и
представила удобный сервис Managed Service for
MongoDB на основе актуальной версии 4.2,
поддерживающей ACID-транзакции на уровне
шардированного кластера и другие возможности.
Управляемый сервис MongoDB позволит вам
сосредоточиться на приложениях, а не на
операциях. Используя Managed Service for
MongoDB, вы платите только за фактически
использованные ресурсы, исходя из удобной
почасовой модели оплаты. Одним нажатием
кнопки вы можете масштабироваться, когда
удобно, без простоев и с гарантией безопасности
и высокой производительности.
Преимущества
Устойчивость к сбоям:
Технологии автоматической репликации и
шардирования позволяют значительно повысить
отказоустойчивость кластера. При
проектировании сервиса учитывался
многолетний опыт эксплуатации MongoDB внутри
Яндекса.
Лёгкость в обслуживании:
Обслуживание СУБД, включая своевременные
обновления, автоматизировано на стороне
платформы Яндекс.Облако, и вы получаете
готовую к эксплуатации базу данных. Вы можете
легко настраивать базы, восстанавливать их из
резервных копий, просматривать логи и следить
за ключевыми показателями на графиках.
Шифрование и изоляция:
В Yandex Managed Service for MongoDB все
соединения с СУБД и резервные копии
содержимого баз шифруются при помощи
протокола TLS и технологией GPG соответственно.
Кроме того, базы разных клиентов Яндекс.Облака
полностью изолированы друг от друга.
Материалы разработаны командой MongoDB, переведены на русский язык и адаптированы командой
Яндекс.Облака в январе 2020 г.
12
Выбор типа хранилища:
Легко выбрать способ хранения данных:
стандартное сетевое, быстрое сетевое и
локальное хранилища. Сетевые более надёжные и
гибкие, а локальное обеспечивает более высокую
скорость.
Копии в разных зонах доступности:
При любых изменениях будут меняться и копии
баз данных, в том числе в разных зонах
доступности.
Быстрая обработка данных:
В Yandex Managed Service for MongoDB
применяются быстрые твердотельные
накопители с поддержкой технологии NVMe. Они
обеспечивают высокую производительность
даже при обработке больших объёмов данных.
Техническая поддержка:
Яндекс.Облако как официальный партнёр имеет
прямой доступ к технической поддержке
MongoDB и оказывает техподдержку клиентам в
России.
Ресурсы
Посетите сайт cloud.yandex.ru или отправьте
письмо в отдел продаж: cloud-sales@yandex-
team.ru.
§ Истории успеха
(cloud.yandex.ru/cases)
§ Вебинары и мероприятия
(cloud.yandex.ru/events)
§ Документация Яндекс.Облака
(cloud.yandex.ru/docs/managed-mongodb/)
§ Запись вебинара с обзором сервиса
(youtube.com/watch?v=Y9x66DDnhsU&t=47s)
§ Бесплатное онлайн-обучение от MongoDB
(university.mongodb.com - англ. яз.)
§ Документация (docs.mongodb.com - англ. яз.)