Partekatu honen bidez:

Tablas elásticas para desarrolladores

  • Artikulua

Las tablas elásticas de Dataverse funcionan con Azure Cosmos DB. Se escalan automáticamente de forma horizontal para manejar grandes cantidades de datos y altos niveles de rendimiento con baja latencia. Las tablas elásticas son adecuadas para aplicaciones con cargas de trabajo impredecibles, puntiagudas o de rápido crecimiento.

Este artículo se centra en la información que los desarrolladores necesitan saber sobre el uso de tablas elásticas. Para obtener más información sobre las capacidades de las tablas elásticas y lo que se admite, visite Crear y editar tablas elásticas.

Cuándo usar tablas elásticas

Los requisitos específicos de sus datos y su aplicación determinan si debe usar tablas elásticas o tablas estándar.

Use tablas elásticas en estas situaciones:

  • Sus datos pueden no estar estructurados o semiestructurados, o su modelo de datos puede cambiar constantemente.
  • Necesita escalado horizontal para manejar el crecimiento de la carga de trabajo a lo largo del tiempo o la carga de trabajo en ráfagas en un punto determinado.
  • Debe manejar un gran volumen de solicitudes de lectura y escritura.

Use tablas estándar en estas situaciones:

  • Su aplicación requiere una fuerte consistencia de datos.
  • Su aplicación requiere modelado relacional y necesita capacidad transaccional entre tablas o durante la ejecución del complemento.
  • Su aplicación requiere uniones complejas.

Una combinación de tablas elásticas y estándar podría ser adecuada para sus datos y su aplicación.

Para obtener más información sobre las diferencias en el modelado de tablas elásticas, visite:

Realizar una partición y ampliación horizontal

Las tablas elásticas usan la partición de Azure Cosmos DB para escalar tablas individuales y satisfacer las necesidades de rendimiento de su aplicación. Todas las tablas elásticas contienen una columna de cadena definida por el sistema Partition Id. Esta columna tiene el nombre de esquema PartitionId y el nombre lógico partitionid.

Azure Cosmos DB garantiza que las filas de una tabla se dividan en distintos subconjuntos, basados en el valor de la columna partitionid por cada fila. Estos subconjuntos se denominan particiones lógicas.

Importante

Para obtener el rendimiento óptimo disponible con tablas elásticas, debe elegir y aplicar de forma coherente una estrategia de partición. Si no establece un valor partitionid para cada fila, el valor seguirá siendo nulo y no podrá cambiarlo más adelante.

Si usa un valor personalizado partitionid, el valor de la clave principal no tiene una restricción única. En otras palabras, puede crear varios registros con la misma clave principal, pero con diferentes valores partitionid. Es importante comprender que las referencias únicas para las tablas elásticas son la combinación de la clave principal y el valor partitionid.

Elegir un valor de partitionId

El valor partitionid que debe usar depende de la naturaleza de sus datos. Una partición lógica en una tabla elástica consta de un conjunto de filas que tienen el mismo valor partitionid. Por ejemplo, en una tabla que contiene datos sobre varios productos, puede usar la categoría de producto como valor partitionid para la tabla. En este caso, los grupos de artículos que tienen valores específicos para la categoría del producto, como Clothing, Books, Electronic Appliances y Pet supplies, forman particiones lógicas distintas.

Dataverse gestiona de forma transparente y automática las particiones lógicas asociadas a una tabla. No hay un límite para la cantidad de particiones lógicas que puede tener en una tabla. Además, no hay riesgo de que se elimine una partición lógica si se eliminan las filas subyacentes.

Para todas las tablas elásticas, la columna partitionid debe cumplir estos criterios:

  • Los valores en ella no cambian. Una vez que se crea una fila con un valor partitionid, no puede cambiarla.
  • Tiene un alto valor de cardinalidad. En otras palabras, la propiedad debe tener una amplia gama de valores posibles. Cada partición lógica puede almacenar 20 gigabytes (GB) de datos. Por lo tanto, elegir un valor partitionid con una amplia gama de valores posibles garantiza que la tabla se pueda escalar sin alcanzar los límites de ninguna partición lógica específica.
  • Distribuya los datos de la forma más uniforme posible entre todas las particiones lógicas.
  • Los valores no pueden superar los 1024 bytes.
  • Ningún valor contiene barras inclinadas (/), corchetes angulares (<, >), asteriscos (*), signos de porcentaje (%), signos de y comercial (&), dos puntos (:), barras invertidas (\), signos de interrogación (?) o signos más (+). Estos caracteres no son compatibles con claves alternativas.

Si un valor partitionid no se especifica para una fila, Dataverse utiliza el valor de la clave principal como valor predeterminado partitionid. Para tablas de cualquier tamaño que requieren mucha escritura, o para casos en los que las filas se recuperan principalmente mediante la clave principal, la clave principal es una excelente opción para la columna partitionid.

Nivel de coherencia

La tabla elástica admite una consistencia fuerte durante una sesión lógica. Una sesión lógica es una conexión entre un cliente y Dataverse. Cuando un cliente realiza una operación de escritura en una tabla elástica, recibe un token de sesión que identifica de forma única la sesión lógica. Para tener una consistencia fuerte, debe mantener el contexto de sesión lógica, incluyendo el token de sesión con todas las solicitudes posteriores.

Los tokens de sesión garantizan que todas las operaciones de lectura realizadas dentro del mismo contexto de sesión lógica devuelven la escritura más reciente realizada dentro de esa sesión lógica. En otras palabras, los tokens de sesión garantizan que las lecturas respeten las garantías read-your-writes y write-follows-reads dentro de una sesión lógica. Si una sesión lógica diferente realiza una operación de escritura, es posible que otras sesiones lógicas no vean esos cambios inmediatamente.

El token de sesión está disponible como un valor x-ms-session-token en la respuesta de todas las operaciones de escritura. Debe incluir este valor cuando recupere datos para recuperar la fila más actualizada.

  • Si usa el SDK, use el parámetro opcional SessionToken.
  • Si usa la API web, use el encabezado de solicitud MSCRM.SessionToken.

Si recupera un registro sin un token de sesión, los cambios recién aplicado podrían no aplicarse. En su lugar, es posible que se devuelvan en solicitudes posteriores.

Obtenga más información sobre cómo usar el token de sesión.

Comportamiento transaccional

Las tablas elásticas no admiten transacciones de registros múltiples. Para la ejecución de una sola solicitud, las múltiples operaciones de escritura que ocurren en las mismas o diferentes etapas de complemento síncrono no son transaccionales entre sí.

Por ejemplo, tiene un paso de complemento síncrono que está registrado en la etapa PostOperation del mensaje Create en una tabla elástica. En este caso, un error que ocurre en el complemento no revierte el registro que se crea en Dataverse. Siempre debe evitar cancelar intencionalmente cualquier operación lanzando InvalidPluginExecutionException en las etapas sincrónicas PreOperation o PostOperation. Si el error se lanza después de la operación Main, la solicitud devolverá un error, pero la operación de datos tendrá éxito. Si se inicia alguna operación de escritura en la etapa PreOperation, estas tendrán éxito.

Sin embargo, siempre debe aplicar reglas de validación en un complemento registrado para la etapa sincrónica PreValidation. La validación es el propósito de esta etapa. Incluso cuando use tablas elásticas, la solicitud devuelve un error y la operación de datos no comienza. Obtenga más información sobre la canalización de ejecución de eventos.

Las tablas elásticas tampoco admiten solicitudes de agrupación en una sola transacción de base de datos que usa la clase de SDK ExecuteTransactionRequest o en un conjunto de cambios de operación $batch de la API Web. Actualmente, estas operaciones tienen éxito pero no son atómicas. En el futuro, se lanzará un error.

Las tablas elásticas no admiten la inserción profunda como todas las tablas estándar. Obtrendrá este error: Cannot create related entities. Create has to be called individually for each entity.

Para obtener más información sobre transacciones multiregistro vaya a:

Caducar datos usando Time to live

Dataverse incluye automáticamente una columna de enteros Tiempo de vida con tablas elásticas. Esta columna tiene el nombre de esquema TTLInSeconds y el nombre lógico ttlinseconds.

Cuando se establece un valor en esta columna, define el tiempo en segundos después del cual la fila caducará y se eliminará de la base de datos automáticamente. Si no se establece ningún valor, el registro persiste indefinidamente, al igual que las tablas estándar.

Escenario

Los ejemplos en artículos relacionados usan este escenario.

Contoso opera una gran cantidad de dispositivos de Internet de las cosas (IoT) implementados por la empresa en todo el mundo. Contoso necesita almacenar y consultar grandes cantidades de datos de sensores que se emiten desde dispositivos IoT para que puedan monitorear el estado del dispositivo y recopilar otros conocimientos.

Contoso puede crear una tabla elástica denominada contoso_SensorData para almacenar y consultar un gran volumen de datos de IoT. Utiliza una columna de cadena que se denomina contoso_DeviceId como el valor partitionid para cada fila que corresponde a un dispositivo. Dado que cada valor contoso_DeviceId es único para cada dispositivo y Contoso realiza consultas principalmente en el contexto de un valor contoso_DeviceId dado, actúa como una buena estrategia de partición para todo conjunto de datos.

Artículos relacionados:

Problemas conocidos

Los siguientes son problemas conocidos con las tablas elásticas que deben abordarse antes de que esta función esté disponible de forma general.

No se devuelve el error al agrupar operaciones de datos de tablas elásticas en una transacción

Dataverse no devuelve un error cuando agrupa operaciones de datos mediante la clase SDK ExecuteTransactionRequest o con una operación de cambio de API web $batch. Aunque estas operaciones de datos se completan, no se aplica ninguna transacción. Debido a que no se puede aplicar ninguna transacción, estas operaciones deberían fallar y devolver un error.

El valor de x-ms-session-token no se devuelve para operaciones de eliminación

Dataverse no devuelve el valor x-ms-session-token para las operaciones de eliminación. Obtenga más información sobre cómo se usa este valor para administrar la consistencia de los datos.

El parámetro opcional de particiónId no está disponible para todos los mensajes

Siempre que se deba identificar un registro que usa un valor partitionid personalizado, como para operaciones Retrieve, Update o Upsert , necesita una manera para hacer referencia al valor partitionid. En este caso, puede usar la clave alternativa para hacer referencia al registro. Si lo prefiere, también debería poder usar el estilo de parámetro opcional partitionId. En este momento, solo las operaciones Retrieve y Delete admiten el uso del parámetro opcional partitionId. Más información sobre el uso del parámetro partitionId.

Cuando tiempo de vida (TTL) se usa en una fila, la fila se eliminará de la tabla elástica cuando el TTL haya expirado. Si se sincroniza con un lago de datos mediante Synapse Link for Dataverse antes de que caduque el TTL, no se eliminará del lago de datos.

Preguntas frecuentes

Esta sección incluirá preguntas frecuentes (P+F). Si tiene una pregunta que no se aborda en la documentación, seleccione el botón Esta página en la sección Comentarios sección en la parte inferior de la página. Debe tener una cuenta de GitHub para enviar preguntas de esta manera.

Pasos siguientes

Crear tablas elásticas mediante código

Consulte también

Usar tablas elásticas mediante código
Consultar columnas JSON en tablas elásticas
Mensajes de operación masiva
Código de ejemplo de tablas elásticas
Realizar una partición y ampliación horizontal en Azure Cosmos DB