Cómo diseñar una solución multiinquilino con Azure Data Explorer

El concepto de multiinquilino en Azure Data Explorer hace referencia a servir a diferentes inquilinos y almacenar sus datos en un único clúster.

Importante

Una solución multitenant también se puede diseñar en la carga de trabajo de Microsoft Fabric Real-Time Intelligence, utilizando bases de datos KQL dentro de un Eventhouse.

Un inquilino puede representar a un cliente, un grupo de usuarios o cualquier clasificación de usuarios en los que los datos deban segregarse a lo largo de los límites de los inquilinos. También puede tener un escenario multiinquilino de varios niveles, como varias aplicaciones que tienen varios inquilinos. En este artículo no se trata este escenario, pero se aplican principios similares.

Un factor importante es la forma en que los usuarios finales acceden a sus datos de inquilino. Cuando los usuarios finales acceden directamente a Azure Data Explorer, el control de acceso debe configurarse en Azure Data Explorer para aislar la vista del usuario a sus propios datos. Cuando una aplicación proxy accede a sus datos en Azure Data Explorer, la aplicación puede realizar el aislamiento.

En este artículo se describen algunas arquitecturas de implementación y se proporcionan características para cada una. Puede usar las características para ayudarle a decidir qué arquitectura funciona mejor para la solución.

Vecino ruidoso

En general, compartir un clúster entre muchos inquilinos, independientemente de la arquitectura utilizada, significa que los distintos inquilinos comparten los recursos del clúster. Esto puede conducir al antipatrón vecino ruidoso.

Por ejemplo, si un inquilino realiza muchas consultas o ingestas de proceso intensivo, es probable que otros inquilinos se vean afectados por el colapso de recursos. Esto se puede mitigar mediante grupos de cargas de trabajo. También puede usar directivas para controlar el almacenamiento en caché y el almacenamiento general.

Introducción a las arquitecturas

En las secciones siguientes se exploran detalladamente las arquitecturas de implementación. En esta sección se contrastan las arquitecturas para facilitar la toma de decisiones.

Architecture	Strengths
Un inquilino por base de datos	- Aislamiento de inquilinos: no es necesario el proxy. - Puede tener directivas diferentes, como directivas de retención, por inquilino. - Flexibilidad en la evolución del esquema por inquilino - Eliminación fácil y rápida de datos de inquilinos
Una tabla para muchos inquilinos	- Administración eficaz de la consolidación y extensión de datos - Evolución simplificada del esquema - Más adecuado para vistas materializadas - Ideal para la creación de particiones
Un inquilino por tabla en una base de datos única	No se recomienda

Arquitectura: un inquilino por base de datos

Esta es una arquitectura popular y directa. Cada inquilino tiene su propia base de datos. Cada base de datos tiene el mismo esquema.

Las características de esta arquitectura son:

• Aprovisionamiento de un nuevo inquilino: requiere crear una nueva base de datos e implementar entidades de esquema en él.

• Quitar un inquilino: requiere eliminar la base de datos. La eliminación de una base de datos se puede realizar en unos segundos. Consume recursos poco y constantes que no son lineales con el volumen de datos del inquilino.

• Actualizaciones de esquemas de base de datos: cada inquilino se puede actualizar de forma independiente en momentos diferentes. Las aplicaciones que tienen acceso a las bases de datos deben tener en cuenta la versión de cada base de datos con la que interactúan.

• Directivas de retención y almacenamiento en caché: cada inquilino puede tener sus propias directivas únicas, lo que le permite proporcionar directivas personalizadas de retención y almacenamiento en caché a los clientes.

• Límite de seguridad por inquilino:

  • Para la aplicación multiinquilino (proxy): configure la aplicación para que se dirija a la base de datos pertinente. Use la restricción de acceso en las consultas para prohibir las consultas entre bases de datos.
  • Para los usuarios con acceso directo: se puede conceder acceso a los usuarios en el nivel de base de datos. Proporcionar a los usuarios acceso directo a su base de datos crea una dependencia para los detalles de implementación, lo que dificulta el cambio de la implementación. Por lo tanto, se recomienda encarecidamente usar el enfoque de proxy para acceder a la base de datos.

• Agregación de datos de varios inquilinos a escala: use el operador union para agregar datos entre bases de datos. Sin embargo, este método puede resultar complicado a medida que aumenta el número de inquilinos. Aunque la agregación de datos de varios inquilinos podría ser un objetivo de diseño desde la perspectiva del inquilino, podría ser de interés para que el propietario de la solución agregue datos de todos los inquilinos para recopilar estadísticas.

• Fragmentación de extensiones: cada inquilino que ingiere algunos registros por tabla de base de datos conduce a la creación de pequeñas extensiones que posteriormente deben combinarse. Esto da como resultado un mayor costo para la administración de extensiones. Por lo tanto, se recomienda encarecidamente usar la ingesta de streaming, como Event Hubs o la ingesta de Event Grid. Para usar la ingesta de streaming, debe asegurarse de que está habilitada en el clúster y la tabla.

• Vistas materializadas y directiva de creación de particiones. A medida que aumenta el número de inquilinos, es importante recordar que hay límites para el número de vistas materializadas y directivas de partición que un clúster puede ejecutar de forma eficaz.

• Conexiones de datos de Event Grid y Event Hubs: estas conexiones de datos se crean por base de datos. Por lo tanto, esta arquitectura requiere una conexión de datos y una instancia de Event Grid o Event Hubs por inquilino, lo que agrega complejidad de administración. Considere la posibilidad de usar el enrutamiento de eventos para Event Hubs y Event Grid.

Arquitectura: una tabla para muchos inquilinos

Esta arquitectura es más agresiva en su consolidación, mediante una base de datos única para todos los inquilinos. Cada tabla de la base de datos tiene una columna Id. de inquilino, o equivalente, que permite filtrar los datos de un solo inquilino. Puede crear particiones de tablas por inquilino para mejorar el rendimiento de las consultas, ya que es probable que la mayoría de las consultas filtren por inquilino. Siempre que sea posible, debe considerar la posibilidad de crear particiones con otra columna mediante una clave de partición compuesta . Por ejemplo, puede crear una clave de partición compuesta concatenando el identificador de inquilino y otros valores de columnas.

Las características de esta arquitectura son:

• Aprovisionamiento de un nuevo inquilino: el aprovisionamiento de un nuevo inquilino no requiere ningún ajuste de esquema ni creación de base de datos. El nuevo identificador de inquilino se usa en nuevos registros.

• Quitar un inquilino: requiere una eliminación temporal o purga de los datos del inquilino. Puede procesar por lotes varias purgas juntas, por ejemplo, al final de la semana para limitar el impacto en el consumo de recursos.

• Actualizaciones de esquemas de base de datos: el esquema de todos los inquilinos se actualiza al mismo tiempo. Dado que todos los inquilinos comparten la tabla, el cambio de esquemas de tabla cambia todos los inquilinos a la vez.

• Directivas de retención y almacenamiento en caché: las directivas son las mismas para todos los inquilinos, ya que todas comparten la misma tabla.

• Límite de seguridad por inquilino:

  • Para la aplicación multiinquilino (proxy): use la instrucción Restrict.
  • Para los usuarios con acceso directo: use la directiva de seguridad de nivel de fila y familiarícese con sus limitaciones. Proporcionar a los usuarios acceso directo a su base de datos crea una dependencia para los detalles de implementación, lo que dificulta el cambio de la implementación. Por lo tanto, se recomienda encarecidamente usar el enfoque de proxy para acceder a la base de datos.

• Agregación de datos de varios inquilinos a escala: los usuarios con los permisos de acceso suficientes pueden ejecutar una consulta de agregación estándar en los datos de varios inquilinos.

• Fragmentación de extensiones: dado que todos los inquilinos ingieren datos en la misma tabla, los datos normalmente se pueden consolidar y ingerir de forma eficaz en una o varias extensiones.

• Vistas materializadas y directiva de creación de particiones: se pueden usar en una tabla multitenant. Puede mejorar el rendimiento mediante la creación de particiones en la columna Id. de inquilino o equivalente. Para obtener más información, consulte Escenarios para directivas de partición.

• Conexiones de datos de Event Grid y Event Hubs: las conexiones de datos consolidadas desde que los datos de todos los inquilinos terminan en una tabla.

Arquitectura: un inquilino por tabla en una base de datos única

Esta arquitectura es una combinación de las arquitecturas anteriores en las que los datos de todos los inquilinos terminan en una base de datos única, pero tablas independientes. Esta arquitectura no puede capturar todas las ventajas de las otras arquitecturas.

Aunque los datos de cada inquilino están separados, todos residen en el mismo contexto de seguridad de la misma base de datos. Al igual que la arquitectura de varias bases de datos, esta arquitectura puede provocar una fragmentación en la medida. El nombre de la tabla es diferente para cada inquilino y, por tanto, las consultas deben personalizarse para cada inquilino.

Contenido relacionado

• Grupos de carga de trabajo
• Control de acceso basado en roles
• Seguridad de nivel de fila
• Instrucción de restricción
• Política de partición