Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Концепция многотенантности в Azure Data Explorer относится к обслуживанию разных клиентов и хранению данных в одном кластере.
Это важно
Мультитенантное решение также можно создать в Microsoft Fabric Real-Time Intelligence с помощью баз данных KQL в Eventhouse.
Клиент может представлять клиента, группу пользователей или любые классификации пользователей, в которых данные должны быть разделены по границам клиентов. Вы также можете использовать многоуровневый мультитенантный сценарий, например несколько приложений, у которых есть несколько клиентов. Эта статья не охватывает этот сценарий, но аналогичные принципы применяются.
Важным фактором является способ доступа конечных пользователей к данным клиента. Когда конечные пользователи напрямую осуществляют доступ к Azure Data Explorer, управление доступом должно быть настроено в Azure Data Explorer, чтобы ограничить представление пользователя только их собственными данными. Когда прокси-приложение обращается к своим данным в Azure Data Explorer, приложение может выполнить изоляцию.
В этой статье описываются некоторые архитектуры развертывания и предоставляются характеристики для каждого из них. Вы можете использовать характеристики, которые помогут вам решить, какая архитектура подходит для вашего решения.
Шумный сосед
Как правило, совместное использование кластера между многими клиентами независимо от используемой архитектуры означает, что разные клиенты совместно используют ресурсы кластера. Это может привести к антипаттерну шумного соседа.
Например, если клиент выполняет много вычислительно-интенсивных запросов или загрузок, работа других клиентов, скорее всего, будет затронута дефицитом ресурсов. Это можно устранить с помощью групп рабочей нагрузки. Вы также можете использовать политики для управления кэшированием и общим хранилищем.
Общие сведения об архитектурах
В следующих разделах подробно рассматриваются архитектуры развертывания. В этом разделе сравниваются архитектуры для упрощения принятия решений.
| Architecture | Strengths |
|---|---|
| Один клиент для каждой базы данных | — изоляция клиентов: не требуется прокси-сервер — Могут иметь разные политики, такие как политики хранения, для каждого клиента — гибкость в эволюции схемы для каждого клиента — простое и быстрое удаление данных клиента |
| Одна таблица для многих арендаторов | — эффективная консолидация данных и управление экстентами — упрощенная эволюция схемы - Лучше всего подходит для материализованных представлений — Идеально подходит для секционирования |
| Один клиент на таблицу в одной базе данных | Не рекомендуется |
Архитектура: один клиент для каждой базы данных
Это популярная и простая архитектура. Каждый клиент получает собственную базу данных. Каждая база данных имеет одну и ту же схему.
Характеристики этой архитектуры:
Подготовка нового клиента. Требуется создать базу данных и развернуть сущности схемы на нем.
Удаление клиента. Требуется удаление базы данных. Удаление базы данных может выполняться через несколько секунд. Использует небольшие и постоянные ресурсы, которые не являются линейными с объемом данных клиента.
Обновления схем базы данных: каждый клиент может быть независимо обновлен в разное время. Приложения, обращаюющиеся к базам данных, должны учитывать версию каждой базы данных, с которыми они взаимодействуют.
Политики хранения и кэширования. Каждый клиент может иметь собственные уникальные политики, которые позволяют предоставлять пользовательские политики хранения и кэширования клиентам.
Граница безопасности для каждого клиента:
- Для мультитенантного приложения (прокси): настройте приложение для целевой базы данных. Используйте ограничение доступа к запросам, чтобы запретить запросы между базами данных.
- Для пользователей с прямым доступом: пользователям можно предоставить доступ на уровне базы данных. Предоставление пользователям прямого доступа к базе данных создает зависимость для сведений о реализации, что затрудняет изменение реализации. Поэтому настоятельно рекомендуется использовать подход прокси для доступа к базе данных.
Агрегирование данных из нескольких арендаторов в крупном масштабе: используйте оператор объединения для объединения данных между базами данных. Однако этот метод может стать громоздким по мере увеличения числа клиентов. Несмотря на то, что агрегирование данных из нескольких арендаторов может быть целью проектирования с точки зрения арендатора, это может быть интересно владельцу решения для агрегирования данных со всех арендаторов для сбора статистики.
Фрагментация экстентов: каждый клиент, который отправляет несколько записей на таблицу базы данных, приводит к созданию небольших экстентов , которые позже необходимо объединить. Это приводит к повышению затрат на управление экстентами. Поэтому настоятельно рекомендуется использовать прием потоковой передачи, например центры событий или прием сетки событий. Чтобы использовать прием потоковой передачи, необходимо убедиться, что он включен в кластере и таблице.
Материализованные представления и политика разделения на разделы. По мере увеличения числа тенантов важно помнить, что есть ограничения по количеству материализованных представлений и политик разбиения, которые кластер может эффективно выполнять.
Подключения к данным Сетки событий и Центров событий: эти подключения к данным создаются для каждой базы данных. Поэтому для этой архитектуры требуется подключение к данным и экземпляр Службы Event Grid или экземпляр Службы Event Hubs для каждого клиента, что усложняет управление. Рекомендуется использовать маршрутизацию событий для Центров событий и сетки событий.
Архитектура: одна таблица для многих арендаторов
Эта архитектура более агрессивна в своей консолидации, используя одну базу данных для всех клиентов. Каждая таблица в базе данных содержит столбец идентификатора клиента или эквивалент, который позволяет фильтровать данные одного клиента. Таблицы можно секционировать по клиенту, чтобы повысить производительность запросов, так как большинство запросов, скорее всего, фильтруются по клиенту. По возможности следует рассмотреть разбиение с использованием другого столбца и составного ключа раздела. Например, можно создать составной ключ секции, объединяющий идентификатор клиента и значения других столбцов.
Характеристики этой архитектуры:
Подготовка нового клиента. Подготовка нового клиента не требует никакой настройки базы данных или схемы. Новый идентификатор клиента используется в новых записях.
Удаление арендатора: Требуется мягкое удаление или полное удаление данных арендатора. Вы можете сгруппировать несколько очисток, например, в конце недели, чтобы ограничить влияние на потребление ресурсов.
Обновление схем базы данных: Схемы всех арендаторов обновляются одновременно. Поскольку все арендаторы совместно используют таблицу, изменение схем таблиц затрагивает всех арендаторов одновременно.
Политики хранения и кэширования: политики одинаковы для всех клиентов, так как они используют одну и ту же таблицу.
Граница безопасности для каждого клиента:
- Для мультитенантного приложения (прокси): используйте инструкцию "Ограничить"
- Для пользователей с прямым доступом : используйте политику безопасности на уровне строк и ознакомьтесь с ее ограничениями. Предоставление пользователям прямого доступа к базе данных создает зависимость для сведений о реализации, что затрудняет изменение реализации. Поэтому настоятельно рекомендуется использовать подход прокси для доступа к базе данных.
Агрегирование данных из нескольких клиентов в масштабе: пользователи с достаточными разрешениями доступа могут выполнять стандартный запрос агрегирования для данных нескольких клиентов.
Фрагментация данных в экстентах. Поскольку все клиенты инжестируют данные в одну таблицу, данные обычно можно консолидировать и эффективно инжестировать в один или несколько экстентов.
Материализованные представления и политика секционирования: их можно использовать в мультитенантной таблице. Вы можете повысить производительность, секционируя идентификатор арендатора или эквивалентный столбец. Дополнительные сведения см. в разделах "Сценарии" для политик секционирования.
Подключения к данным Event Grid и Event Hubs: вы объединяете подключения к данным, так как данные для всех клиентов заканчиваются одной таблицей.
Архитектура: один клиент на таблицу в одной базе данных
Эта архитектура представляет собой комбинацию предыдущих архитектур, в которых данные всех арендаторов в конечном итоге размещаются в одной базе данных, но в отдельных таблицах. Эта архитектура не позволяет захватывать все преимущества других архитектур.
Хотя данные каждого клиента разделены, все они находятся в одном контексте безопасности одной и той же базы данных. Как и архитектура с несколькими базами данных, эта архитектура может привести к фрагментации экстентов. Имя таблицы отличается для каждого клиента, поэтому запросы должны быть настроены для каждого клиента.