Microsoft DocumentDB: статья первая, введение

в 11:31, , рубрики: json, Microsoft Azure, rdbms, Блог компании Microsoft, облако, Облачные вычисления

Привет,
В августе мы зарелизили большое количество новых вещей на Microsoft Azure (пруфлинк), причем совершенно закономерно одной из самых интересных для нашей аудитории оказался сервис Document NoSQL Database по имени DocumentDB. Время пришло, и мы начинаем про неё писать — первая статья, как водится, введение:

  • Что это такое? Базовые концепции.
  • Как создать аккаунт?

Что такое Azure DocumentDB?

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

Microsoft Azure DocumentDB — это документоориентированная, NoSQL база данных, специально спроектированная для приложений в вебе и на мобильных устройствах — с гарантированно-быстрыми операциями чтения и записи, гибкостью схемы и возможностью быстро разворачивать и масштабировать базу вниз и вверх. Еще в DocumentDB есть сложные запросы с привлечением SQL-диалекта, поддержка JavaScript, обработка транзакций с многими документами и много еще хорошего. По умолчанию DocumentDB поддерживает для операций со схемой JSON, и глубокая интеграция с JavaScript помогает выполнять бизнес-логике прямо внутри движка с учетом транзакций.

Azure DocumentDB — это:

  • Запросы с SQL-синтаксисом: хранение гетерогенных документов JSON внутри DocumentDB, запросы к ним.
  • Highly-concurrent, lock-free технология индексирования с автоматическим индексированием содержимого документа (соответственно, без необходимости указывать schema hints, вторичные индексы или представления).
  • JavaScript внутри базы — логика как хранимые процедуры, триггеры и UDF, что значит, что можно логику класть поверх JSON без опасности получить рассинхронизацию между приложением и схемой базы.
  • Полноценное транзакционное выполнение логики на JavaScript в движке (INSERT, REPLACE, DELETE, SELECT в JavaScript как изолированная транзакция)
  • Настраиваемые уровни консистентности в количестве четырех — Strong, Bounded-Staleness, Session и Eventual.
  • Полная управляемость: нет необходимости в управлении базы и ресурсами машины, так как DocumentDB предоставляется как сервис. Каждая база автоматически резервируется и защищается от региональных ошибок.
  • Простое масштабирование через юниты хранилища и пропускной способности.

Ресурсы Azure DocumentDB

В Azure DocumentDB данные реплицируются и адресуются URI — для всех ресурсов выставлена простая RESTful-доступ. У вас есть аккаунт для базы, и он является уникальным глобальным пространством имен. Все ресурсы внутри пространства хранятся в JSON-документах с метаданными и коллекциями вещей. На картинке — отношения между ресурсами DocumentDB.

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

Разработка с Azure DocumentDB

Раз Azure DocumentDB выставляет операции с ресурсами с REST API, запросы можно выполнять с любым языком, который умеет HTTP/HTTPS. Для нескольких языков есть специальные библиотеки, упрощающие работу с DocumentDB:

Транзакции и исполнение JavaScript

Как уже писалось, в Azure DocumentDB можно писать логику в виде JavaScript, «программы» затем регистрируются на коллекции и поддерживают операции на документах внутри этих коллекций. Приложение на JS можно зарегистрировать на исполнение для триггеров, хранимых процедур и UDF, триггеры и хранимые процедуры умеют CRUD, тогда как UDF не имеют доступа на запись. Вся логика JS исполняется внутри ambient ACID transaction со snapshot isolation, причем логика на JS считается как бы современной заменой для T-SQL. Если же во время исполнения JS выкинет исключение, то вся транзакция откатывается.

Посмотрим на пример! MSN.com. MSN — это огромный портал, который посещает полмиллиарда пользователей в месяц. Отсюда необходимость в большом масштабируемом распределенном хранилище со свободной схемой. В определенный момент команда разработки решила перенести всё в Azure и создать там единую распределенную систему хранилища User Data Store со следующими требованиями:

  1. Масштабирование до +425 миллионов уникальных пользователей +100 миллионов уже аутентифицировавшихся в системе пользователей
  2. 20 терабайт хранилища
  3. Латентность на запись — до 15 мс
  4. Отсутствие фиксированной схемы
  5. Поддержка транзакций
  6. Hadoop-аналитика поверх данных
  7. Географическая распределенность и доступность

 
Выбор пал на Azure DocumentDB. Одна из частей системы, Health and Fitness, состоит из следующих компонентов:
 

  • Diet Tracker: мониторинг ежедневной диеты — каждая запись содержит данные о калориях, жирах, протеине и др.
  • Exercise Tracker: мониторинг упражнений.
  • GPS Tracker: трекинг GPS. Метаданные о происходящем хранятся в DocumentDB.
  • Pedometer: Шаги.
  • Weight Tracker. Вес.
  • Analysis: Исторические данные по диете, упражнениям, GPS и др.
  • Favorites and custom: закладки на любимую еду, упражнения, метаданные и др.

 

Новый портал MSN хранит данные пользователей в DocumentDB с 150 юнитами пропускной способности с SSD и тремя географическими регионами.

Размер документов варьируется от 1 до 10 килобайт, и не обладают никакой общей схемой. Большинство коллекций настроены таким образом, чтобы давать оптимальные значения пропускной способности, минимальный оверхед на индексирование.
 
Microsoft DocumentDB: статья первая, введение
 
UDS распределяет пользовательскую информацию по коллекциям, данные каждого пользователя хранятся в документах. В процессе происходит горизонтальное масштабирование и распределение по пользовательским ID.

Создаем аккаунт DocumentDB

Заходим на новый портал управления Microsoft Azure
Нажимаем New -> DocumentDB Account.
Microsoft DocumentDB: статья первая, введение

Либо можно сделать то же самое, дойдя до категории “Data, storage, + backup” и выбрав DocumentDBand.

Microsoft DocumentDB: статья первая, введение

В New DocumentDB (Preview) выберем нужную конфигурацию.

Microsoft DocumentDB: статья первая, введение

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

Создание аккаунта занимает несколько минут.

Microsoft DocumentDB: статья первая, введение
 
Microsoft DocumentDB: статья первая, введение

Аккаунт создан и готов к использованию. Режим консистентности по умолчанию выставляется в Session.

Microsoft DocumentDB: статья первая, введение

Посмотреть, что происходит с аккаунтами DocumentDB, можно в окне Browse.

Microsoft DocumentDB: статья первая, введение

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

Полезные ссылки

Автор: ahriman

Источник

Поделиться

* - обязательные к заполнению поля