Preguntas más frecuentes sobre Azure Cosmos DB

Azure Cosmos DB es adecuado para casos de uso web, móviles, de juegos e IoT. En estos casos de uso, el escalado automático, el rendimiento predecible, unos tiempos de respuesta rápidos del orden de milisegundos y la capacidad de consultar datos sin esquemas son importantes. Se presta a un desarrollo rápido y admite la iteración continua de modelos de datos de aplicaciones. Las aplicaciones que administran datos y contenido generados por el usuario se suelen asignar a casos de uso comunes de Azure Cosmos DB.

Una unidad de solicitud (RU) es la medida de procesamiento de Azure Cosmos DB. Una única unidad de solicitud de rendimiento corresponde al rendimiento de la acción HTTP GET para un documento de 1 kilobyte. Todas las operaciones de Azure Cosmos DB, incluidas las lecturas, escrituras, consultas y ejecuciones de procedimiento almacenado, tienen un valor de unidad de solicitud determinista en función del rendimiento necesario para completar la operación. En lugar de forzarse a tener en cuenta la CPU, la E/S y la memoria en relación con el rendimiento de la aplicación, puede pensar en términos de unidades de solicitud.

Puede configurar cada contenedor de Azure Cosmos DB con rendimiento aprovisionado en términos de unidades de solicitud por segundo (RU/s). Puede usar puntos de referencia de solicitudes individuales para medir en unidades de solicitud y crear un contenedor para controlar la suma de unidades de solicitud en todas las solicitudes de ese contenedor en un segundo. También puede escalar o reducir verticalmente el rendimiento del contenedor a medida que evolucionen las necesidades de la aplicación. Para obtener más información sobre cómo medir las unidades de solicitud, consulte la calculadora de rendimiento.

Los modelos de datos de pares clave-valor (tabla), columnas, documentos y gráficos se admiten de forma nativa porque Azure Cosmos DB se basa en el diseño de ARS (átomos, registros y secuencias). Los átomos, los registros y las secuencias se pueden asignar y proyectar con facilidad en varios modelos de datos. Las API de un subconjunto de modelos están disponibles mediante el diseño de ARS (MongoDB, NoSQL, Table, Apache Cassandra y Apache Gremlin). Azure Cosmos DB también admite otras API.

Un contenedor es un grupo de elementos. Los contenedores pueden abarcar una o varias particiones y se pueden escalar para controlar volúmenes prácticamente ilimitados de almacenamiento o rendimiento.

Un contenedor es una entidad facturable, en la que el rendimiento y el almacenamiento usados determinan el costo. Cada contenedor se factura por hora según el rendimiento aprovisionado y el espacio de almacenamiento usado. Para obtener más información, consulte Precios de Azure Cosmos DB.

Azure Cosmos DB es un servicio de base de datos con varios modelos distribuido de forma global de Microsoft. Modelo múltiple hace referencia a la compatibilidad de Azure Cosmos DB con varias API y modelos de datos. En este paradigma, las distintas API usan diferentes formatos de datos para el protocolo de almacenamiento y conexión. Por ejemplo; NoSQL usa JSON, MongoDB usa JSON con codificación binaria (BSON), Table usa Entity Data Model (EDM), Cassandra usa el lenguaje de consulta Cassandra (CQL), Gremlin usa el formato JSON. Como resultado, se recomienda usar la misma API para todo el acceso a los datos de una cuenta determinada.

Sí. Las API de Azure Cosmos DB permiten la integración directa. Por ejemplo, las API de REST de Azure Cosmos DB se pueden integrar con Azure API Management para operaciones CRUD, lo que elimina la necesidad de servicios intermediarios como Azure Functions.

Sí, Azure Cosmos DB es compatible con HIPAA. HIPAA establece los requisitos para el uso, la divulgación y la protección de información de mantenimiento identificable individualmente. Para más información, consulte el Centro de confianza de Microsoft.

No existe ningún límite en la cantidad total de datos que puede almacenar un contenedor en Azure Cosmos DB.

No existe ningún límite en la cantidad total de rendimiento que admite un contenedor en Azure Cosmos DB. La idea clave es distribuir la carga de trabajo de manera más o menos uniforme entre una cantidad suficientemente grande de claves partición.

Sí, ambos modos se cifran siempre totalmente.

El número de contenedores aprovisionados, el número de horas que estuvieron en línea los contenedores y el rendimiento aprovisionado para cada contenedor determinan los cargos de uso de Azure Cosmos DB. Para obtener más información sobre los precios, consulte Precios de Azure Cosmos DB.

Para formular una pregunta técnica, puede realizar una publicación en alguno de estos dos foros de preguntas y respuestas:

• Preguntas y respuestas de Microsoft (Q&A)
• Stack Overflow. Stack Overflow es la mejor opción para preguntas de programación. Proporcione tantos detalles como sea posible, lo que hace que la pregunta sea clara y respondible.

Para corregir un problema con la cuenta, envíe una solicitud de soporte técnico en Azure Portal.

En primer lugar, debe registrarse para obtener una suscripción de Azure. Una vez que se haya registrado para obtener una suscripción de Azure, puede agregar a esta un contenedor de API para NoSQL.

Los kits de desarrollo de software (SDK) están disponibles para .NET, Python, Node.js, JavaScript, Go y Java. Los desarrolladores también pueden usar las API REST para interactuar con recursos de Azure Cosmos DB desde más plataformas y lenguajes.

Consulte estos ejemplos de código y plantillas de inicio rápido para la API para NoSQL:

• .NET
• Python
• Node.js / JavaScript
• Java/Spring
• Ir a

Sí, la API para NoSQL permite que las aplicaciones almacenen documentos JSON arbitrarios como elementos sin definiciones ni sugerencias de esquemas. Los datos están disponibles inmediatamente para la consulta con el lenguaje de consulta de Azure Cosmos DB for NoSQL.

Sí, la API para NoSQL admite transacciones entre documentos expresadas mediante lotes en los SDK o como procedimientos almacenados y desencadenadores de JavaScript. Las transacciones se limitan a una única partición dentro de cada contenedor y se ejecutan con semántica ACID, como "todo o nada", aisladas de otras solicitudes de usuario y código que se ejecutan a la vez. Si se producen excepciones, se revierte toda la transacción.

Puede crear bases de datos mediante una de estas herramientas:

• Azure Portal
• SDK de API para cliente NoSQL (plano de datos)
  • .NET
  • Python
  • JavaScript
  • Java
  • Ir a
• SDK de API para administración NoSQL (plano de control)
  • .NET
  • Python
  • JavaScript
  • Java
  • Ir a
• Azure Resource Manager
  • Plantilla de JSON
  • Bíceps
  • Terraform
• REST API

Yes! Azure Cosmos DB admite la autenticación de Microsoft Entra para administrar el servicio y sus recursos (plano de control) y para ejecutar datos, operaciones y consultas (plano de datos). La autenticación del plano de control se realiza mediante la característica de control de acceso basado en roles de Azure. Puede usar un rol integrado preconfigurado](../../role-based-access-control/built-in-roles.md) o puede crear un rol personalizado. Con el control de acceso basado en roles de Azure, puede administrar cuentas, bases de datos, contenedores y metadatos. El plano de control incluye operaciones, entre las que se incluyen, entre otros, estos ejemplos.

• Creación, reemplazo o eliminación de bases de datos; creación, sustitución o eliminación de contenedores; lectura o sustitución del rendimiento de la base de datos; lectura o reemplazo de los datos de rendimiento del contenedor; la autenticación de plano utiliza una API personalizada para la implementación del control de acceso basado en roles nativo de NoSQL. Con esta implementación nativa, también puede usar roles preconfigurados o personalizados. Con el control de acceso basado en roles nativo, puede ejecutar consultas, administrar elementos o realizar otras operaciones comunes. El plano de datos incluye operaciones, entre las que se incluyen, entre otros, estos ejemplos.
• Creación, reemplazo, actualización o eliminación de elementos; aplicación de revisiones a elementos; ejecución de consultas

El lenguaje de consulta estructurado (SQL) es un lenguaje que normalmente se usa para consultar datos relacionales. La API para NoSQL tiene un lenguaje de consulta NoSQL personalizado derivado de SQL. El lenguaje de consulta NoSQL incluye un subconjunto del lenguaje de consulta SQL normalmente asociado a SQL Server junto con varias mejoras específicas de NoSQL. El lenguaje de consulta SQL de NoSQL proporciona operadores relacionales y jerárquicos y una extensibilidad a través de JavaScript según las funciones definidas por el usuario (UDF). La sintaxis JSON permite el modelado de documentos JSON como árboles con nodos etiquetados, algo que usan las técnicas de indexación automática de Azure Cosmos DB y el dialecto de consulta SQL de Azure Cosmos DB. Para obtener información sobre el uso de este lenguaje de consulta, vea Consulta NoSQL.

La API para NoSQL admite la agregación a través de funciones de agregado como: COUNT, MAX, AVG y SUM a través del lenguaje de consulta NoSQL.

La API para NoSQL admite el control de simultaneidad optimista (OCC) mediante etiquetas de entidad HTTP, o ETag. Cada recurso de API para NoSQL tiene una ETag y esta se establece en el servidor cada vez que se actualiza un documento. El encabezado de la ETag y el valor actual se incluyen en todos los mensajes de respuesta. Las etiquetas ETag pueden utilizarse con el encabezado If-Match para permitir que el servidor decida si debe actualizarse un recurso. El valor de If-Match es el valor de ETag con el que se va a cotejar. Si el valor de ETag coincide con el valor de ETag del servidor, el recurso se actualiza. Si el valor de ETag ya no es el actual, el servidor rechaza la operación con un código de respuesta "HTTP 412 Precondition failure" (HTTP 412: error de condición previa). Después, el cliente recupera el recurso para obtener el valor de Etag actual del recurso. Además, se pueden usar ETags con el encabezado If-None-Match para determinar si es necesario capturar un recurso.

La mayoría de los SDK de API para NoSQL incluyen clases para administrar el control de simultaneidad optimista.

Use la característica de importación masiva en el SDK de .NET o el SDK de Java para que la API para NoSQL importe grandes conjuntos de datos. Esta característica optimiza el rendimiento aprovisionado para importar grandes conjuntos de datos.

Como alternativa, use Apache Spark para importar datos a escala mediante Python o Scala.

Sí, dado que Azure Cosmos DB for NoSQL es un servicio RESTful, los vínculos de recursos son inmutables y se pueden almacenar en caché. Los clientes de la API para NoSQL pueden especificar un encabezado "If-None-Match" para lecturas en cualquier documento o contenedor de tipo recurso y actualizar sus copias locales cuando la versión del servidor cambie.

Sí. El emulador de Azure Cosmos DB proporciona una emulación de gran fidelidad del servicio Azure Cosmos DB. Admite la funcionalidad idéntica a Azure Cosmos DB en varias API. Esta funcionalidad incluye compatibilidad para crear elementos, consultar elementos, aprovisionar contenedores y escalar contenedores. Puede desarrollar y probar aplicaciones mediante los puntos de conexión del emulador. Después, puede implementar las aplicaciones en Azure a escala global cambiando la cadena de conexión del emulador al servicio activo.

Esta limitación del explorador de datos es una limitación de JavaScript. JavaScript usa números de formato de punto flotante de precisión doble, como se especifica en Institute of Electrical and Electronics Engineers (IEEE) 754. Este tipo de datos puede contener números entre -(2⁵³ - 1) y 2⁵³-1 (es decir, solo 9007199254740991).

El control de acceso basado en roles (RBAC) es un método para regular el acceso a los recursos de equipo o de red en función de los roles de usuarios individuales dentro de una empresa. En Azure Cosmos DB, RBAC se usa para conceder acceso al plano de datos a usuarios y aplicaciones. Para obtener más información sobre varios términos en el control de acceso basado en rol, consulte el glosario de seguridad.

Use la característica de control de acceso basado en roles (RBAC) nativo de Azure Cosmos DB para conceder acceso al plano de datos a usuarios y aplicaciones. Para obtener más información, consulte Concesión de acceso basado en roles del plano de datos.

A partir de ahora, solo se admite la API NoSQL.

Todavía no está disponible la compatibilidad de Azure Portal con la administración de roles.

Actualmente, se admiten los SDK de .NET V3, Java V4, JavaScript V3 y Python V4.3 y versiones posteriores.

Sí.

Sí. Para obtener más información, consulte cómo deshabilitar la autenticación con clave de acceso.

La guía general para migrar una cuenta de Cosmos DB a otro grupo de recursos o suscripción se describe en el artículo traslado de recursos de Azure a un nuevo grupo de recursos o suscripción .

Después de mover correctamente la cuenta de Azure Cosmos DB según la guía general, las identidades (System-Assigned o User-Assigned) asociadas a la cuenta deben ser reasignadas. Esta reasignación es necesaria para asegurarse de que estas identidades siguen teniendo los permisos necesarios para acceder a la clave de Key Vault.

Si la cuenta de Cosmos DB tiene habilitadas las claves administradas por el cliente, solo puede migrar la cuenta si es una cuenta de clave administrada por el cliente entre inquilinos. Para obtener más información, consulte la guía sobre la configuración de claves gestionadas por el cliente en un entorno multi-inquilino para su cuenta de Azure Cosmos DB con Azure Key Vault.

Al migrar del modo periódico al modo continuo, no se pueden ejecutar operaciones del plano de control que realicen actualizaciones o eliminaciones de nivel de cuenta. Por ejemplo, las operaciones como agregar o quitar regiones, la conmutación por error de la cuenta, la actualización de la directiva de copia de seguridad, etc. no se pueden ejecutar mientras la migración está en curso. El tiempo de migración depende del tamaño de los datos y del número de regiones de la cuenta. La acción de restauración en las cuentas migradas solo se realiza correctamente desde el momento en que se completa correctamente la migración.

Puede restaurar la cuenta una vez completada la migración. Si la migración se completa a las 13:00 PST, puede realizar una restauración a un momento dado a partir de las 13:00 PST.

Sí.

Las cuentas de la API para NoSQL, la API para Table, la API de Gremlin y la API para MongoDB que usan rendimiento aprovisionado compartido, aprovisionado o de escalabilidad automática admiten la migración a la copia de seguridad continua.

Las cuentas con Azure Synapse Link habilitado o que tenían Azure Synapse Link deshabilitado para una o varias colecciones, no se pueden migrar a la copia de seguridad continua.

La migración tarda una cantidad de tiempo variable que depende en gran medida del tamaño de los datos y del número de regiones de la cuenta. Puede obtener el estado de migración mediante la CLI de Azure o comandos de PowerShell. En el caso de cuentas grandes con decenas de terabytes de datos, la migración puede tardar hasta unos días en completarse.

Sí, esta migración tarda mucho tiempo que depende en gran medida de la necesidad de esperar a que todas las escrituras provisionales antiguas se agoten durante la migración de la copia de seguridad continua. Puede obtener el estado de migración mediante la CLI de Azure o comandos de PowerShell. En el caso de cuentas grandes con decenas de terabytes de datos, la migración puede tardar hasta unos días en completarse.

No, la operación de migración tiene lugar en segundo plano. Por lo tanto, las solicitudes de cliente no se ven afectadas. Sin embargo, es necesario realizar algunas operaciones de back-end durante la migración y podría tardar más tiempo si la cuenta está bajo carga pesada.

Una vez iniciado el proceso de migración, la cuenta está habilitada en modo continuo. Si se produce un error en la migración, debe iniciar la migración de nuevo hasta que se realice correctamente.

Supongamos que inició la migración en t1 y finalizó en t5, no puede usar una marca de tiempo de restauración entre t1 y t5. Suponga también que la cuenta está ahora en modo continuo. Para restaurar a un tiempo después de t5, realice la restauración mediante Azure Portal, CLI, o PowerShell como se hace normalmente con una cuenta continua. Esta solicitud de restauración de autoservicio solo se puede realizar una vez completada la migración. Para restaurar a un momento anterior a t1, puede abrir una incidencia de soporte técnico tal como lo haría con una cuenta de copia de seguridad periódica. Después de la migración, tiene hasta 30 días para realizar la restauración periódica. Durante estos 30 días, puede restaurar en función de la retención o el intervalo de copia de seguridad de la cuenta antes de la migración. Por ejemplo, si la copia de seguridad se configuró para conservar 24 copias a intervalos de 1 hora, puede restaurar en cualquier momento entre (t1 – 24 hours) y t1.

Las operaciones como agregar o quitar región, conmutación por error, cambiar la política de copia de seguridad, y cualquier cambio en el rendimiento que resulte en el movimiento de datos, se bloquean durante la migración.

La migración con errores no bloquea ninguna operación del plano de control. Si se produce un error en la migración, vuelva a intentarlo hasta que se realice correctamente antes de realizar otras operaciones del plano de control.

No es posible cancelar la migración porque las migraciones no son una operación reversible. Mediante el equipo de llamadas de soporte técnico puede cancelar temporalmente y permitir que las operaciones sin conexión continúen. Pero no se puede volver al estado de copia de seguridad periódico.

No hay ninguna herramienta para calcular el tiempo. Nuestras pruebas y ejecuciones de escalado indican que una cuenta con 1 TB de datos tarda aproximadamente 90 minutos. Para las cuentas de varias regiones, calcule el tamaño total de los datos como Number_of_regions * Data_in_single_region.

Pruebe la característica de modo de copia de seguridad continua para comprobar que funciona según lo previsto antes de migrar cuentas de producción. La migración es una operación unidireccional y no se puede revertir.

Sí, puede registrarse para obtener una cuenta gratuita de base de datos con 1000 RU/s y 25 GB de forma gratuita.

Si es la primera vez que usa Azure, regístrese para obtener una cuenta gratuita de Azure, que ofrece 30 días y un crédito para que pruebe todos los servicios de Azure. Si tiene una suscripción a Visual Studio, puede recibir créditos gratis de Azure para usarlos en cualquier servicio de Azure.

También puede usar el Emulador de Azure Cosmos DB para desarrollar y probar su aplicación localmente, de forma gratuita, sin necesidad de crear una suscripción de Azure. Cuando esté satisfecho con el funcionamiento de la aplicación en el Emulador, puede cambiar a una cuenta de Azure Cosmos DB en la nube.

Azure Cosmos DB está disponible en Azure Portal. En primer lugar, regístrese para obtener una suscripción de Azure. Una vez que se haya registrado, puede agregar una cuenta de Azure Cosmos DB a la suscripción de Azure.

Use microsoft Entra ID para autenticarse en Azure Cosmos DB para todas las API que admiten este método de autenticación. Para las API que no admiten la autenticación de Microsoft Entra ID, use las claves con precaución. Asegúrese de que las claves de las cuentas de producción se almacenan de forma segura, como en Azure Key Vault.

Para obtener información sobre la disponibilidad regional de Azure Cosmos DB, consulte Productos de Azure disponibles por región. Puede usar una cuenta para la base de datos en una o varias de estas regiones.

Los kits de desarrollo de software (SDK) para Azure Cosmos DB permiten la configuración de las regiones que usan para las conexiones. En la mayoría de los SDK, el valor de "PreferredLocations" se establece en cualquiera de las regiones de Azure en las que Azure Cosmos DB está disponible.

Azure Cosmos DB se ofrece en todas las regiones de Azure, tal y como se especifica en la página Regiones de Azure. Dado que es un servicio principal de Azure, cada nuevo centro de datos tiene presencia de Azure Cosmos DB.

Al establecer una región, debe recordar que Cosmos DB respeta las nubes independientes y de administración pública. Por ejemplo, no se pueden replicar datos fuera de una región soberana. De manera similar, tampoco puede habilitar la replicación en otras ubicaciones soberanas desde una cuenta externa.

El aprovisionamiento de rendimiento a nivel de contenedor y base de datos son ofertas independientes, y cambiar entre cualquiera de estas ofertas requiere migrar datos desde el origen hacia el destino. Debe crear una base de datos o un contenedor y, a continuación, migrar los datos mediante la biblioteca Bulk Executor o Azure Data Factory.

Sí, Azure Cosmos DB admite el análisis de series temporales. Puede usar la fuente de cambios para crear vistas agregadas en los datos de series temporales. Puede ampliar este enfoque mediante el uso de streaming de Apache Spark u otro procesador de datos de streaming.

Para obtener información sobre las cuotas de servicio y los límites de rendimiento, consulte Cuotas de servicio y Límites de rendimiento.

Contenido relacionado

• Preguntas frecuentes sobre Azure Cosmos DB for NoSQL
• Preguntas frecuentes sobre Azure Cosmos DB for MongoDB
• Preguntas frecuentes sobre Azure Cosmos DB for Apache Gremlin
• Preguntas frecuentes sobre Azure Cosmos DB for Apache Cassandra
• Preguntas frecuentes sobre Azure Cosmos DB for Table