Многотенантность и Azure Cosmos DB

  • Статья

На этой странице описаны некоторые функции Azure Cosmos DB, которые полезны при работе с мультитенантными системами. Мы также ссылаемся на рекомендации и примеры использования Azure Cosmos DB в мультитенантном решении.

Функции Azure Cosmos DB, поддерживающие мультитенантность

Секционирование

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

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

Подробнее:

Управление единицами запросов

Модель ценообразования Azure Cosmos DB основана на количестве единиц запросов в секунду, которые вы подготавливаете или используете. Единица запроса — это логическая абстракция стоимости операции базы данных или запроса. Как правило, для рабочей нагрузки подготавливается определенное количество единиц запросов в секунду, которое называется пропускной способностью. Azure Cosmos DB предоставляет несколько вариантов подготовки пропускной способности. В мультитенантной среде выбор влияет на производительность и цену ресурсов Azure Cosmos DB.

Одна модель арендатора для Azure Cosmos DB включает развертывание отдельных контейнеров для каждого клиента в общей базе данных. Azure Cosmos DB позволяет подготавливать единицы запросов для базы данных, а все контейнеры совместно используют единицы запроса. Если рабочие нагрузки клиента обычно не перекрываются, этот подход может помочь сократить операционные затраты. Однако этот подход подвержен проблеме "Шумный сосед", так как контейнер одного клиента может использовать непропорциональное количество общих подготовленных единиц запросов. Чтобы устранить эту проблему, сначала определите шумных клиентов. Затем можно дополнительно задать подготовленную пропускную способность для определенного контейнера. Другие контейнеры в базе данных продолжают делиться пропускной способностью, но шумный клиент потребляет собственную выделенную пропускную способность.

Azure Cosmos DB также предоставляет бессерверный уровень, который подходит для рабочих нагрузок с периодическим или непредсказуемым трафиком. Кроме того, автомасштабирование позволяет настроить политики для указания масштабирования подготовленной пропускной способности. Кроме того, вы можете воспользоваться преимуществами емкости ускорения Azure Cosmos DB, максимизируя использование подготовленной пропускной способности, которая была бы ограничена в противном случае. В мультитенантном решении можно объединить все эти подходы для поддержки различных типов клиента.

Примечание.

При планировании конфигурации Azure Cosmos DB убедитесь, что вы считаете квоты и ограничения службы.

Чтобы отслеживать затраты, связанные с каждым клиентом, и управлять ими, каждая операция с помощью API Azure Cosmos DB включает используемые единицы запросов. Эти сведения можно использовать для агрегирования и сравнения фактических единиц запросов, потребляемых каждым клиентом, и затем можно определить клиентов с разными характеристиками производительности.

Подробнее:

Ключи, управляемые клиентом

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

Подробнее:

Модели изоляции

При работе с мультитенантной системой, используюющей Azure Cosmos DB, необходимо принять решение об уровне изоляции, которую вы хотите использовать. Бизнес-бизнес (B2B) относится к продаже бизнеса. Бизнес-потребитель (B2C) относится к продаже непосредственно клиенту, который использует продукт или услугу. Azure Cosmos DB поддерживает несколько моделей изоляции:

Требуется рабочая нагрузка Ключ секции для каждого клиента Контейнер для каждого клиента (общая пропускная способность) Контейнер для каждого клиента (выделенная пропускная способность) Однотенантная база данных Учетная запись базы данных для каждого клиента
Запросы между клиентами Easy (контейнер выступает в качестве границы для запросов) Необратимая Необратимая Необратимая Необратимая
Плотность клиента Высокая (низкая стоимость для каждого клиента) Средний Низкий Низкая Низкая
Удаление данных клиента Необратимая Простое (удаление контейнера при выходе клиента) Простое (удаление контейнера при выходе клиента) Простота (удаление базы данных при выходе клиента) Простота (удаление базы данных при выходе клиента)
Изоляция безопасности доступа к данным Необходимо реализовать в приложении Контейнер RBAC Контейнер RBAC База данных RBAC RBAC
Георепликация Геоизбыточное реплика для каждого клиента невозможно Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований
Шумная профилактика соседей нет нет Да Да Да
Задержка создания нового клиента Интерпретация Быстро Быстро Средняя Медл.
Преимущества моделирования данных нет совместное размещение сущностей совместное размещение сущностей Несколько контейнеров для моделирования сущностей клиента Несколько контейнеров и баз данных для моделирования клиентов
Ключ шифрования Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Управляемый клиентом ключ для каждого клиента
Требования к пропускной способности >0 единиц запросов на клиент >100 единиц запросов на клиент >100 единиц запросов на каждый клиент (только с автомасштабированием, в противном случае >400 единиц запросов на каждый клиент) >400 единиц запросов на клиент >400 единиц запросов на клиент
Пример (-ы) использования Приложения B2C Стандартное предложение для приложений B2B Предложение "Премиум" для приложений B2B Предложение "Премиум" для приложений B2B Предложение "Премиум" для приложений B2B

Ключ секции для каждого клиента

При использовании одного контейнера для нескольких клиентов можно использовать поддержку секционирования Azure Cosmos DB. С помощью отдельных ключей секций для каждого клиента можно легко запрашивать данные для одного клиента. Вы также можете запрашивать несколько клиентов, даже если они находятся в отдельных секциях. Однако запросы между секциями имеют более высокую стоимость единицы запроса (ЕЗ), чем запросы с одним разделом.

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

Важно учитывать пропускную способность контейнера. Все клиенты будут совместно использовать пропускную способность контейнера, поэтому проблема "Шумный сосед " может вызвать проблемы с производительностью, если у клиентов есть высокие или перекрывающиеся рабочие нагрузки. Эта проблема иногда может быть устранена путем группировки подмножества клиентов в разные контейнеры и обеспечения совместимости шаблонов использования каждой группы клиентов. Кроме того, можно рассмотреть гибридную модель с несколькими и одним клиентом. Группировать небольшие клиенты в общие секционированные контейнеры и предоставлять крупным клиентам выделенные контейнеры. Кроме того, существуют функции, которые могут помочь управлять шумной проблемой соседа при моделировании клиента по секциям, таким как перемещение пропускной способности, емкость всплеска и управление пропускной способностью в пакете SDK для Java.

Также важно учитывать объем данных, которые вы храните в каждой логической секции. Azure Cosmos DB позволяет каждому логическому разделу увеличиваться до 20 ГБ. Если у вас есть один клиент, который должен хранить более 20 ГБ данных, рассмотрите возможность распространения данных по нескольким логическим секциям. Например, вместо одного ключа Contosoсекции можно солить ключи секций, создавая несколько ключей секций для клиента, например Contoso1, Contoso2и т. д. При запросе данных для клиента можно использовать WHERE IN предложение для сопоставления всех ключей секций. Иерархические ключи секций также можно использовать для поддержки крупных клиентов с хранилищем размером более 20 ГБ без использования искусственных ключей секций или нескольких значений ключей секции на каждый клиент.

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

Контейнер для каждого клиента

Вы можете подготовить выделенные контейнеры для каждого клиента. Выделенные контейнеры хорошо работают, если данные, которые хранятся для вашего клиента, можно объединить в один контейнер. Эта модель обеспечивает большую изоляцию производительности, чем описанная выше модель секционирования для каждого клиента, а также обеспечивает повышенную изоляцию доступа к данным через Azure RBAC.

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

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

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

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

Однотенантная база данных

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

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

Учетная запись базы данных для каждого клиента

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

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

Если вы используете эту модель, следует учитывать, насколько быстро приложение должно создавать новые клиенты. Создание учетной записи в Azure Cosmos DB может занять несколько минут, поэтому вам может потребоваться создать учетные записи заранее. Если этот подход не подходит, рассмотрите модель базы данных на клиент.

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

Гибридные подходы

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

  • Подготовьте всех клиентов бесплатной пробной версии в общем контейнере и используйте идентификатор клиента или ключ секции искусственного ключа.
  • Предлагайте платный уровень Бронза , который развертывает выделенный контейнер для каждого клиента, но с общей пропускной способностью в базе данных.
  • Предлагайте более высокий уровень Silver , который подготавливает выделенную пропускную способность для контейнера клиента.
  • Предложите самый высокий уровень Gold и укажите выделенную учетную запись базы данных для клиента, которая также позволяет клиентам выбирать географию для их развертывания.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Основные авторы:

  • Пол Берпо | Главный инженер клиента, FastTrack для Azure
  • Джон Даунс | Главный инженер клиента, FastTrack для Azure

Другие участник:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Просмотрите подходы к хранилищу и данным для мультитенантности.

Дополнительные сведения о мультитенантности и Azure Cosmos DB:

  • Azure Cosmos DB и мультитенантные системы: запись блога, которая описывает, как создать мультитенантную систему, использующую Azure Cosmos DB.
  • Мультитенантные приложения с Помощью Azure Cosmos DB (видео)
  • Создание мультитенантной saaS с помощью Azure Cosmos DB и Azure (видео): реальное исследование того, как Whally, мультитенантный запуск SaaS, построил современную платформу с нуля в Azure Cosmos DB и Azure. Whally показывает решения по проектированию и реализации, которые они приняли, связанные с секционированием, моделированием данных, безопасной мультитенантностью, производительностью, потоковой передачей в режиме реального времени из канала изменений в SignalR и многое другое. Все эти решения используют ASP.NET Core в службах приложение Azure.

Ознакомьтесь с некоторыми из других сценариев архитектуры Cosmos DB: