Multiinquilino y Azure Cosmos DB

En este artículo se describen las características de Azure Cosmos DB que puede usar para sistemas multiinquilino. Proporciona instrucciones y ejemplos sobre cómo usar Azure Cosmos DB en una solución multiinquilino.

Requisitos multiinquilino

Al planear una solución multiinquilino, debe cumplir dos requisitos clave:

• Garantizar el aislamiento de seguridad y rendimiento entre inquilinos. Como proveedor, debe cumplir los requisitos de seguridad y asegurarse de que cada inquilino cumple los requisitos de rendimiento.

• Mantenga un costo bajo para cada inquilino. Como proveedor, debe asegurarse de que el costo para ejecutar la aplicación sigue siendo sostenible a medida que se escala.

Estos dos requisitos suelen entrar en conflicto y requieren que dé prioridad uno al otro. Las instrucciones de este artículo le ayudarán a comprender estas ventajas y tomar decisiones fundamentadas al diseñar la solución multiinquilino.

Modelos de aislamiento

Determine el nivel de aislamiento que necesita entre los inquilinos. Para la mayoría de las soluciones, se recomienda usar una de las estrategias siguientes, en función de la carga de trabajo:

• Las soluciones de software como servicio (SaaS) de negocio a consumidor (B2C) suelen usar una clave de partición para cada inquilino. Un ejemplo de este tipo de solución es una aplicación de bot de chat conversacional que almacena el historial de chat de usuario en Azure Cosmos DB.

• Las soluciones SaaS de negocio a negocio (B2B) suelen usar una cuenta de base de datos para cada inquilino. Un ejemplo de este tipo de solución es un sistema de administración de contenido (CMS) que las empresas compran para publicar contenido digital.

Para elegir el modelo de aislamiento más adecuado, tenga en cuenta el modelo de negocio y los requisitos de los inquilinos. Por ejemplo, en los modelos B2C, una empresa vende un producto o servicio directamente a un cliente individual. Normalmente no se requiere un aislamiento de seguridad y rendimiento para cada cliente individual. Para obtener la mayor eficiencia de costos, estas aplicaciones pueden almacenar datos para todos los inquilinos del mismo contenedor y las claves de partición proporcionan aislamiento lógico.

Sin embargo, en los modelos B2B, los proveedores venden diferentes SKU que corresponden a distintos niveles de rendimiento, garantías de acuerdo de nivel de servicio (SLA) o requisitos de aislamiento. Los proveedores quieren ofrecer a sus clientes la opción de administrar sus propias claves de cifrado, también conocidas como claves administradas por el cliente o entre inquilinos. Para estas aplicaciones, use una cuenta de base de datos independiente para cada inquilino para que pueda optimizar y garantizar el rendimiento de cada cliente. Al usar cuentas de base de datos independientes, también puede proporcionar claves administradas por el cliente. Esta característica solo está disponible en el nivel de cuenta de base de datos de Azure Cosmos DB.

Modelo de clave de partición por inquilino

En un modelo de clave de partición por inquilino, el mismo contenedor de Azure Cosmos DB almacena todos los datos de los inquilinos mediante una clave de partición como /TenantId. Los inquilinos comparten el rendimiento del contenedor.

Ventajas

• Administración simplificada: Colocará a todos los inquilinos en un único contenedor, que está particionado por el identificador de inquilino. Este enfoque crea solo un recurso facturable que aprovisiona y comparte RU/s entre varios inquilinos. Este modelo es más fácil de administrar porque solo una configuración de RU/s afecta el coste de toda la carga de trabajo multiteniente.

Compromisos y consideraciones

• Contención de recursos: El rendimiento compartido (RU/s) entre los clientes del mismo contenedor puede provocar contención durante el uso pico. Esta contención puede crear problemas de vecinos ruidosos y desafíos de rendimiento si los inquilinos tienen cargas de trabajo elevadas o superpuestas. Use este modelo de aislamiento para cargas de trabajo que no necesiten RU/s garantizadas en un solo inquilino y que puedan compartir el rendimiento.

• Aislamiento limitado: este enfoque proporciona aislamiento lógico, no aislamiento físico. Use este modelo de aislamiento para cargas de trabajo que no necesitan un rendimiento garantizado para cada inquilino o claves administradas por el cliente para cada inquilino.

• Menos flexibilidad: Si aísla los inquilinos por clave de partición, no puede personalizar características de nivel de cuenta como la replicación geográfica, la restauración a un momento dado y las claves administradas por el cliente para cada inquilino.

Características de Azure Cosmos DB para multitenencia

Azure Cosmos DB proporciona varias características que le ayudan a optimizar el rendimiento y administrar los costos de las soluciones multiinquilino. Estas características abordan desafíos comunes, como problemas ruidosos de vecinos, y le ayudan a almacenar datos de forma eficaz y consultar entre inquilinos.

Control de rendimiento

Las siguientes características ayudan a controlar el problema de vecino ruidoso cuando se usa una clave de partición para aislar inquilinos o tener varias cargas de trabajo que usan el mismo contenedor compartido.

Claves de partición jerárquicas

Para cargas de trabajo de lectura intensivas en las que normalmente consulta por entidad, se recomienda usar claves de partición jerárquicas para lograr las siguientes ventajas:

• Almacenamiento ilimitado para cada inquilino: Establezca /TenantId como clave de primer nivel y un campo /id de cardinalidad alta, como la clave de segundo nivel, para garantizar que cada inquilino tenga almacenamiento ilimitado. Es posible que tenga otra jerarquía en la carga de trabajo. Por ejemplo, es posible que tenga que almacenar datos para cada usuario de cada inquilino. En este escenario, establezca /TenantId como clave de primer nivel, /UserId como clave de segundo nivel y /id como clave de tercer nivel para garantizar un almacenamiento ilimitado para cada usuario de un inquilino.

  Nota:

  Las características de Azure Cosmos DB, como los procedimientos almacenados y las transacciones por lotes atómicas, solo están disponibles en el nivel de clave de partición lógica completa. Si utiliza claves de partición jerárquicas y usa /id como clave de último nivel, no puede ejecutar procedimientos almacenados ni realizar una transacción atómica por lotes en niveles parciales.

  Por ejemplo, si crea particiones por /TenantId, /UserId y /id, no puede ejecutar un procedimiento almacenado ni realizar una transacción por lotes atómica especificando solo /TenantId o solo /TenantId y /UserId. Si necesita usar estas características, no establezca /id como clave de último nivel.

• Consultas eficaces: Las consultas que especifican /TenantId o ambas /TenantId y /UserId se enrutan de forma eficaz solo al subconjunto de particiones físicas que contiene los datos pertinentes, lo que evita una consulta de distribución completa. Si el contenedor tiene 1000 particiones físicas, pero un valor específico /TenantId es solo en 5 particiones físicas, la consulta se enruta al menor número de particiones físicas pertinentes.

Use claves de partición jerárquicas cuando tenga una cardinalidad alta de valores y una distribución uniforme de volúmenes de solicitudes para las claves de primer nivel. En un entorno multitenant, se debería tener muchos inquilinos, idealmente del orden de cientos o miles de inquilinos, y sus inquilinos deberían compartir un patrón de uso similar.

Una partición activa y un posible rendimiento degradado pueden producirse en los escenarios siguientes:

• Trabaja con pocos inquilinos.

• Trabajas con una carga de trabajo sesgada en la que un único inquilino consume consistentemente exponencialmente más RU/s que tus otros inquilinos, incluso cuando usas claves de partición jerárquicas.

No utilice claves de partición jerárquicas para tareas en las que no tenga una alta cardinalidad para cada cliente o cuando necesite optimizar el rendimiento de escritura. En estos escenarios, se recomienda usar claves de partición sintéticas o la creación de particiones solo mediante /id. Estos enfoques permiten repartir las operaciones de escritura uniformemente en todas las particiones físicas.

Puede construir una clave sintética de una manera que se optimice para algunas consultas. Por ejemplo, una TenantId_UserId clave sintética reduce ligeramente la distribución uniforme de datos en todas las particiones, pero permite consultar eficazmente a un usuario específico de un inquilino al especificar la clave de partición completa. La optimización de consultas es la principal ventaja de usar una clave sintética en lugar de /id.

Sin embargo, si la carga de trabajo optimiza el rendimiento de escritura, es posible que las consultas no sean pertinentes. Puede particionar solo mediante /id para simplificar su carga de trabajo.

Si trabaja con algunos inquilinos grandes que necesitan constantemente volúmenes de solicitudes más altos que otros inquilinos, considere la posibilidad de aislar esos inquilinos en sus propias cuentas de base de datos. Mantenga los inquilinos restantes en un contenedor compartido.

Modelo de cuenta por inquilino de base de datos

En el modelo database-account-per-tenant, los datos de cada inquilino se almacenan en su propia cuenta de base de datos de Azure Cosmos DB. Dentro de cada cuenta, varios contenedores para diferentes cargas de trabajo o microservicios acceden a los datos de un inquilino. Cada contenedor tiene un rendimiento dedicado (RU/s).

Ventajas

• Alta aislamiento: Este enfoque evita problemas de contención o vecinos ruidosos porque los datos de cada cliente están en su propia cuenta de Azure Cosmos DB dedicada. Cada contenedor de la cuenta tiene RU/s dedicadas.

• Acuerdos de Nivel de Servicio personalizados: Cada inquilino tiene su propia cuenta, por lo que puede proporcionar recursos personalizados específicos, acuerdos de nivel de servicio orientados al cliente y garantías, ya que puede ajustar los recursos de la cuenta de base de datos de cada inquilino de forma independiente para satisfacer sus necesidades de rendimiento.

• Seguridad mejorada: Este enfoque permite claves administradas por el cliente en el nivel de cuenta de base de datos, por lo que el proveedor puede ofrecer claves administradas por el cliente para cada inquilino. Si se requieren claves administradas por el cliente, deberá utilizar el aislamiento tipo "database-account-per-tenant".

• Flexibilidad: Puede activar características de nivel de cuenta, como la replicación geográfica, la restauración a un momento dado y las claves administradas por el cliente en un nivel por inquilino (cuenta de base de datos) según sea necesario.

Compromisos y consideraciones

• Más cuentas para administrar: Este enfoque puede ser más complejo porque tiene varias cuentas de Azure Cosmos DB que representan un inquilino o cliente. Sin embargo, puede usar la flota de Azure Cosmos DB para simplificar la administración de cuentas compartiendo su capacidad de procesamiento (RU/s) en varias cuentas de base de datos. También puede usar análisis de flotas para supervisar el uso a escala.

• Limitaciones de consulta entre inquilinos: Todos los inquilinos están en cuentas diferentes, por lo que las aplicaciones que consultan varios inquilinos requieren varias llamadas dentro de la lógica de la aplicación. Normalmente, estas consultas entre inquilinos no forman parte de la carga de trabajo transaccional principal que proporciona el servicio a cada inquilino. En su lugar, forman parte de una carga de trabajo analítica que ayuda al proveedor a comprender las tendencias y el uso más amplios en distintos inquilinos o clientes. Para estos casos de uso, utilice reflejo en Microsoft Fabric.

Características de Azure Cosmos DB para multitenencia

• Azure Cosmos DB grupos de flotas: Los grupos de flotas ayudan a los clientes que crean aplicaciones multitenencia a administrar, supervisar y optimizar su flota de cuentas de base de datos. Dentro de una flota, puede organizar los inquilinos o las cuentas de base de datos en agrupaciones lógicas denominadas fleetspaces. También puede configurar un grupo opcional de rendimiento (RU/s) que pueden compartir todas las cuentas de base de datos del espacio de flotas. Este enfoque ayuda a optimizar los costos.

  

  El diagrama muestra la estructura de una flota de Azure Cosmos DB y sus componentes. En la parte superior, un icono de edificio con la etiqueta flota acompaña a una llamada. La llamada explica que una flota es una entidad de alto nivel que almacena espacios de flota y se asigna a aplicaciones multiinquilino. Debajo del icono de flota, una línea horizontal que indica el rendimiento compartido entre los fleetspaces se conecta a un cuadro etiquetado como 'pool de flota' que tiene una capacidad de 100.000 RU/s. El conjunto de flotas contiene tres espacios de flota. Junto con los espacios de flota, una anotación explica que los espacios de flota son agrupaciones lógicas de cuentas de base de datos dentro de una flota, que puede distribuir espacios de flota en varias suscripciones y que puede usar espacios de flota para agrupar clases similares de arrendatarios. La llamada también menciona que puede configurar un grupo opcional para compartir RU/s. Cada fleetspace incluye varios iconos de bases de datos y puntos suspensivos para indicar más bases de datos. Un recordatorio adicional explica que todos los recursos en un fleetspace comparten el grupo de RU/s.

  Muchos proveedores crean una flota para cada región en la que operan y separan aún más los inquilinos en espacios de flota en función de los requisitos de rendimiento del inquilino o la clase de inquilino.

  Por ejemplo, para su flota de East US 2, un proveedor podría crear un fleetspace para las cuentas que pertenecen a clientes que usan una prueba gratuita porque requieren menos RU/s de grupo. El proveedor crea otro espacio de flota para las cuentas que pertenecen a los inquilinos que firman un contrato enterprise porque requieren más RU/s.

  Estos grupos le permiten compartir RU/s en varias cuentas, incluso si abarcan diferentes suscripciones y grupos de recursos dentro de una flota. Los recursos de cada cuenta conservan sus propias RU/s dedicadas, y los grupos permiten que las cuentas utilicen automáticamente RU/s adicionales del conjunto compartido cuando sea necesario. Este enfoque le ayuda a evitar el sobreaprovisionamiento.

  En lugar de aprovisionar los contenedores de cada usuario para las RU/s máximas, lo que puede ser costoso, puedes establecer un valor típico de RU/s-por contenedor y usar la capacidad compartida del grupo para gestionar los picos.

• Protección contra vecinos ruidosos: Por diseño, cualquier rendimiento aprovisionado en un contenedor está dedicado y se garantiza que siempre está disponible para ese contenedor. Otros contenedores no pueden usar RU/s dedicados. Un contenedor que necesite más rendimiento solo puede usar RU/s desde el grupo compartido.

• Escalado automático: Los grupos siempre se pueden escalar automáticamente y puede configurar el grupo para escalar automáticamente entre un número mínimo y máximo de RU/s. Las RU/s del pool tienen el mismo precio unitario que las RU/s normales que configuras en un contenedor, por lo que cambiar el uso a un pool compartido de recursos te ayuda a ahorrar costes.

• Analytics: Active el análisis de flota de Azure Cosmos DB para supervisar el uso de su flota y seguir las tendencias históricas en todas las instancias.

  El análisis de flota transmite los datos de uso y costo de cada cuenta de base de datos, base de datos y contenedor dentro de la flota a Fabric o a una cuenta de Azure Storage, por lo que puede realizar análisis a largo plazo de cuentas dentro de su flota. Use estos datos para realizar un seguimiento de las tendencias como las cuentas más activas, cómo se escalan los recursos a lo largo del tiempo y la rotación más reciente de las claves de acceso. También puede usar datos de telemetría sin procesar para escribir consultas personalizadas o crear paneles Power BI para analizar los datos de uso de los inquilinos.

• Características de seguridad: El modelo de cuenta por arrendatario proporciona un mayor aislamiento de seguridad de acceso a los datos a través del control de acceso basado en rol de Azure (RBAC). Este modelo también es la única opción que proporciona aislamiento de seguridad de nivel de inquilino a través de claves administradas por el cliente.

• Configuración personalizada: Puede establecer la ubicación de la cuenta de base de datos según los requisitos del inquilino. También puede ajustar la configuración de las características de Azure Cosmos DB, como la replicación geográfica y las claves de cifrado administradas por el cliente, para que se adapten a los requisitos de cada inquilino.

  Al usar una cuenta de Azure Cosmos DB dedicada para cada inquilino, tenga en cuenta el número maximum de cuentas de Azure Cosmos DB por suscripción Azure.

Resumen de los modelos de aislamiento recomendados

Modelos de aislamiento no recomendados

Se recomiendan los modelos de aislamiento partition-key-per-tenant y database-account-per-tenant para la mayoría de los escenarios de multitenencia. El aislamiento por contenedor o base de datos es posible, pero estos enfoques suelen tener desventajas que los modelos de aislamiento recomendados abordan de forma más eficaz.

Modelo de contenedor por inquilino

Puede aprovisionar contenedores dedicados que cada uno tenga sus propias RU/s para cada inquilino y colocarlos en una cuenta de base de datos de Azure Cosmos DB. Cada cuenta de base de datos solo puede contener un número limitado de contenedores, por lo que es posible que necesite varias cuentas para almacenar datos para todos los inquilinos. Debe realizar un seguimiento de qué cuenta de base de datos contiene datos para cada cliente, lo que agrega complejidad a la aplicación.

Azure Cosmos DB también limita el rendimiento para las operaciones de metadatos y el número de bases de datos o contenedores en cada cuenta. Las operaciones de metadatos incluyen leer la lista de bases de datos o contenedores en una cuenta y leer y actualizar la configuración del contenedor. Debido a estos límites, no se recomienda este modelo. Si una sola cuenta tiene varios inquilinos, el volumen de operaciones de metadatos aumenta y es posible que no se escale de forma eficaz. Este modelo también puede requerir que administre varias cuentas para equilibrar muchos inquilinos, lo que aumenta la complejidad de la solución multiinquilino.

Puede usar el modelo de contenedor por arrendatario para lograr el aislamiento del rendimiento para cada arrendatario mediante la asignación de RU/s dedicadas a nivel de contenedor. También puede mejorar la seguridad mediante Azure RBAC. Pero el modelo de contenedor por inquilino no admite claves administradas por el cliente. Las claves administradas por el cliente solo están disponibles en el nivel de cuenta de base de datos.

Si tiene muchos contenedores en una cuenta de base de datos y necesita usar RBAC del plano de datos de Azure Cosmos DB para asignar un rol a cada contenedor, es posible que encuentre límites en la cantidad de asignaciones de roles por cada cuenta.

Si necesita aislamiento de rendimiento o claves administradas por el cliente, considere la posibilidad de usar el modelo database-account-per-tenant y los grupos de flotas para optimizar el costo de cada inquilino. Si no necesita estas funcionalidades, considere la posibilidad de usar el modelo partition-key-per-tenant.

Modelo de base de datos por inquilino

Puede aprovisionar bases de datos para cada inquilino y colocarlas en la misma cuenta de base de datos. Al igual que el modelo de contenedor por inquilino, es posible que necesite varias cuentas de base de datos para almacenar datos para todos los inquilinos y la lógica de aplicación personalizada para realizar un seguimiento de la cuenta de base de datos a la que pertenece un inquilino.

Puede usar el modelo de base de datos por inquilino para lograr el aislamiento de rendimiento para cada inquilino mediante la configuración de RU/s compartidas a nivel de base de datos o RU/s dedicadas para cada contenedor. También puede mejorar la seguridad mediante Azure RBAC. Pero el modelo de base de datos por inquilino no admite claves administradas por el cliente. Tampoco solemos recomendar RU/s compartidas a nivel de base de datos para cargas de trabajo de alto tráfico porque no se garantiza el rendimiento de cada contenedor de la base de datos.

Si necesita aislamiento de rendimiento o claves administradas por el cliente, considere la posibilidad de usar el modelo database-account-per-tenant y los grupos de flotas para optimizar el costo de cada inquilino. Si no necesita estas funcionalidades, considere la posibilidad de usar el modelo partition-key-per-tenant.

Al igual que el modelo de contenedor por inquilino, no recomendamos este modelo debido a los límites de Azure Cosmos DB en el rendimiento para las operaciones de metadatos y el número de bases de datos o contenedores de cada cuenta.

Azure Cosmos DB características que admiten multitenencia

Use las siguientes características de Azure Cosmos DB en la solución multiinquilino.

Particionamiento

Use particiones con los contenedores de Azure Cosmos DB para crear contenedores que comparten varios inquilinos. Normalmente, se usa el identificador de inquilino como clave de partición, pero también puede usar varias claves de partición para un solo inquilino. Una estrategia de creación de particiones bien planeada implementa eficazmente el patrón de particionamiento. Cuando tiene contenedores grandes, Azure Cosmos DB distribuye los inquilinos entre varios nodos físicos para lograr un alto grado de escala.

Considere la posibilidad de usar claves de partición jerárquicas para mejorar el rendimiento de la solución multiinquilino. Use claves de partición jerárquicas para crear una clave de partición que incluya varios valores. Por ejemplo, puede usar una clave que incluya el identificador de inquilino como clave de primer nivel y un campo de cardinalidad alta, como /id para el siguiente nivel, para garantizar un almacenamiento ilimitado para cada inquilino. También puede especificar una clave de partición jerárquica que incluya una propiedad que consulta con frecuencia. Este enfoque le ayuda a evitar consultas entre particiones. Utilice claves de partición jerárquicas para escalar más allá del límite lógico de partición de 20 GB por valor de clave de partición y limitar las consultas costosas de distribución ramificada. Las claves de partición jerárquicas funcionan mejor cuando tiene una cardinalidad alta de inquilinos y necesita optimizar para una carga de trabajo de lectura intensiva.

Para obtener más información, consulte los siguientes recursos:

• Creación de particiones y escalado horizontal en Azure Cosmos DB
• Claves de partición jerárquicas

Grupos de flotas

Usa flotas de Azure Cosmos DB, una característica de Azure Cosmos DB, para obtener las ventajas de rendimiento y aislamiento de seguridad que vienen con el modelo de cuentas de base de datos por inquilino. Puede optimizar los costos al compartir RU/s entre varias cuentas en el mismo grupo. Agrupe tipos similares de inquilinos en el mismo grupo de flotas y configure el grupo para escalar automáticamente entre un número mínimo y máximo de RU/s.

Los contenedores de cada cuenta conservan RU/s dedicados, pero cuando están en un grupo, usan automáticamente RU/s adicionales del grupo compartido cuando es necesario. Este enfoque le ayuda a evitar el sobreaprovisionamiento. En lugar de aprovisionar los contenedores de cada inquilino para las RU/s máximas, lo que puede ser costoso, puede establecer un valor típico de RU/s por contenedor y usar la capacidad compartida del grupo para controlar los picos. Para proteger contra vecinos ruidosos, cualquier ancho de banda aprovisionado en un contenedor está dedicado y garantizado para estar siempre disponible para ese contenedor. Si un contenedor necesita más rendimiento, puede usar RU/s del grupo compartido.

Para obtener más información, consulte los siguientes recursos:

• Azure Cosmos DB flotas
• Pools de flotas de Azure Cosmos DB

Análisis de flota (versión preliminar)

Use fleet analytics, una característica de las flotas de Azure Cosmos DB, para analizar tendencias a largo plazo en las cuentas de bases de datos de su flota. El análisis de flotas ofrece datos de rendimiento, uso y costos como tablas de Apache Delta Lake de código abierto en Azure Data Lake Storage y Microsoft OneLake a una cadencia horaria.

Use estos datos para realizar un seguimiento de tendencias como las cuentas más activas, cómo se escalan los recursos a lo largo del tiempo, qué cuentas de base de datos o inquilinos tienen el costo más alto y la rotación más reciente de las claves de acceso. También puede usar los datos para escribir consultas personalizadas o crear paneles Power BI para analizar la flota.

Administración de RU

El modelo de precios de Azure Cosmos DB se basa en el número de RU/s que aprovisiona o consume. Azure Cosmos DB proporciona varias opciones para aprovisionar el rendimiento. En un entorno multiinquilino, la selección afecta al rendimiento y el precio de los recursos de Azure Cosmos DB.

En el caso de los inquilinos que requieren aislamiento de seguridad y rendimiento garantizado, se recomienda aislar los inquilinos por cuenta de base de datos, asignar RU/s dedicadas al inquilino y usar grupos de flotas para controlar las necesidades de capacidad adicionales. En el caso de los inquilinos que tienen requisitos menos estrictos, se recomienda aislar los inquilinos por clave de partición. Utilice este modelo para compartir RU/s entre sus clientes y optimizar los costos para cada cliente.

Azure Cosmos DB también proporciona un nivel sin servidor, que se adapta a las cargas de trabajo que tienen tráfico intermitente o impredecible.

Para supervisar y administrar los costos asociados a cada inquilino, recuerde que cada operación que usa la API de Azure Cosmos DB incluye las RU consumidas. Puede usar esta información para agregar y comparar las RU reales que consume cada inquilino. A continuación, puede identificar los inquilinos que tienen características de rendimiento diferentes. Si algunos inquilinos tienen requisitos de aislamiento o rendimiento considerablemente mayores, considere la posibilidad de aislarlos en su propia cuenta, con RU/s de contenedor dedicados. Puede usar un contenedor con particiones por identificador de inquilino para almacenar los datos de los inquilinos restantes.

Características de gobernanza de recursos

Explore las características que pueden ayudar a controlar el problema de vecino ruidoso al usar una clave de partición para aislar los inquilinos.

Para obtener más información, consulte los siguientes recursos:

• Rendimiento aprovisionado
• Escalado automático del rendimiento
• Medición del cargo de RU de una solicitud
• Cuotas de servicio de Azure Cosmos DB

Claves administradas por el cliente

Es posible que algunos inquilinos necesiten usar sus propias claves de cifrado. Azure Cosmos DB proporciona una característica de clave administrada por el cliente. Esta característica solo se aplica en el nivel de una cuenta de Azure Cosmos DB. Si los clientes requieren sus propias claves de cifrado, debe usar cuentas dedicadas de Azure Cosmos DB para desplegar a los clientes.

Para obtener más información, consulte Configurar claves administradas por el cliente para su cuenta de Azure Cosmos DB utilizando Azure Key Vault.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autores principales:

• Tara Bhatia | Administrador de programas
• Paul Burpo | Ingeniero principal de clientes, FastTrack para Azure
• Deborah Chen | Administrador de programas principal
• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
• Sergiy Smyrnov | Administrador de programas principal, Azure Cosmos DB

Otros colaboradores:

• Mark Brown | Administrador de proyectos principal, Azure Cosmos DB
• Vic Perdana | Arquitecto de soluciones en la nube, ISV de Azure
• Theo van Kraay | Administrador de programas sénior, Azure Cosmos DB
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure
• Thomas Weiss | Administrador de programas principal

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Para obtener más información sobre multitenencia y Azure Cosmos DB, vea los siguientes vídeos:

• Diseñar capas de datos escalables para aplicaciones multitenencia con Azure Cosmos DB: una sesión en Build 2025 que le guía para diseñar soluciones de multitenencia en Azure Cosmos DB. Obtenga información sobre los procedimientos recomendados de un proveedor de software independiente del mundo real.

• Aplicaciones multitenant con Azure Cosmos DB: Una sesión en el Build 2019 que aborda aislamiento de rendimiento, gestión de costos, consistencia, latencia, compensaciones de disponibilidad y patrones de seguridad para aplicaciones multitenant.

• Compila un SaaS multitenant en Azure Cosmos DB y Azure: un caso práctico real sobre cómo Whally, un startup de SaaS multitenant, crea una plataforma moderna desde cero en Azure Cosmos DB y Azure. Whally toma decisiones de diseño e implementación relacionadas con la partición, el modelado de datos, el multiinquilinato seguro, el rendimiento y el streaming en tiempo real desde la alimentación de cambios a SignalR. Todas estas soluciones usan ASP.NET Core en Azure App Service.

Recursos relacionados

Para revisar otros escenarios de arquitectura de Azure Cosmos DB, consulte los siguientes artículos:

• Enfoques de almacenamiento y datos para multiinquilino
• Patrón de bandeja de salida transaccional con Azure Cosmos DB
• mejores prácticas de arquitectura para Azure Cosmos DB para NoSQL