Compartir a través de

Comando .update table

  • Artículo

El .update table comando realiza actualizaciones de datos en una tabla especificada eliminando y anexando registros de forma atómica.

Advertencia

Este comando es irrecuperable.

Nota:

Al ejecutar el .update table comando en una tabla que es el origen de una directiva de actualización, el .update table comando desencadena estas directivas de actualización para las que se va a modificar la tabla es el origen de la directiva de actualización.

Puede eliminar hasta 5 millones de registros en un solo comando.

Permisos

Debe tener al menos permisos de administrador de tablas para ejecutar este comando.

Sintaxis

Nota:

La sintaxis simplificada , que estaba disponible durante la versión preliminar, ha quedado en desuso.

Obtenga más información sobre las convenciones de sintaxis.

.update[async] table TableName delete DeleteIdentifier append AppendIdentifier [with ( propertyName = propertyValue ] )<|
letDeleteIdentifier= DeletePredicate;
letAppendIdentifier= AppendPredicate;

Parámetros

Nombre Type Obligatorio Descripción
async string Si se especifica, indica que el comando se ejecuta en modo asincrónico.
TableName string ✔️ Nombre de la tabla que se va a actualizar.
DeleteIdentifier string ✔️ Nombre de identificador usado para especificar el predicado delete aplicado a la tabla actualizada.
DeletePredicate string ✔️ Texto de una consulta cuyos resultados se usan como datos para eliminar. El predicado tiene las mismas limitaciones que el predicado de eliminación temporal.
AppendIdentifier string ✔️ Nombre de identificador usado para especificar el predicado append aplicado a la tabla actualizada.
AppendPredicate string ✔️ Texto de una consulta cuyos resultados se usan como datos para anexar.

Importante

  • Los predicados delete y append no pueden usar entidades remotas, entre bases de datos y entidades entre clústeres. Los predicados no pueden hacer referencia a una tabla externa ni usar el externaldata operador .
  • Se espera que las consultas de anexión y eliminación generen resultados deterministas. Las consultas no deterministas pueden provocar resultados inesperados. Una consulta es determinista si y solo si devolvería los mismos datos si se ejecutaran varias veces.
  • Es posible que las consultas se ejecuten más de una vez dentro de la update ejecución. Si los resultados intermedios de la consulta son incoherentes, el comando update puede generar resultados inesperados.

Propiedades admitidas

Nombre Escribir Descripción
whatif bool Si truees , devuelve el número de registros que se anexarán o eliminarán en cada partición, sin anexar o eliminar registros. El valor predeterminado es false.
distribuido bool Si truees , el comando ingiere de todos los nodos que ejecutan la consulta en paralelo. El valor predeterminado es false. Consulte sugerencias de rendimiento.

Importante

Se recomienda ejecutar primero en whatif modo antes de ejecutar la actualización para validar los predicados antes de eliminar o anexar datos.

Devoluciones

El resultado del comando es una tabla donde cada registro representa una extensión que se creó con datos nuevos o que tenía registros eliminados.

Nombre Escribir Descripción
Table string Tabla en la que se creó o eliminó la extensión.
Action string Cree o elimine en función de la acción realizada en la extensión.
ExtentId guid Identificador único de la extensión que creó o eliminó el comando.
RowCount long Número de filas creadas o eliminadas en la extensión especificada por el comando .

Elegir entre .update table vistas materializadas y

Hay escenarios en los que podría usar el .update table comando o una vista materializada para lograr el mismo objetivo en una tabla. Por ejemplo, se podría usar una vista materializada para mantener la versión más reciente de cada registro o una actualización para actualizar los registros cuando hay disponible una nueva versión.

Use las instrucciones siguientes para decidir qué método usar:

  • Si el patrón de actualización no es compatible con las vistas materializadas, use el comando update.
  • Si la tabla de origen tiene un gran volumen de ingesta, pero solo algunas actualizaciones, el uso del comando update puede ser más eficaz y consumir menos caché o almacenamiento que las vistas materializadas. Esto se debe a que las vistas materializadas deben volver a procesar todos los datos ingeridos, lo que es menos eficaz que identificar los registros individuales que se van a actualizar en función de los predicados append o delete.
  • Las vistas materializadas son una solución totalmente administrada. La vista materializada se define una vez y la materialización se produce en segundo plano por el sistema. El comando update requiere un proceso orquestado (por ejemplo, Azure Data Factory, Logic Apps, Power Automate y otros) que ejecute explícitamente el comando update cada vez que haya actualizaciones. Si las vistas materializadas funcionan bien para su caso de uso, el uso de vistas materializadas requiere menos administración y mantenimiento.

Consejos de rendimiento

  • La ingesta de datos es una operación que consume muchos recursos y puede afectar a las actividades simultáneas en el clúster, incluidas las consultas en ejecución. Se recomienda evitar las siguientes acciones que consumen muchos recursos: ejecutar muchos .update comandos a la vez y un uso intensivo de la propiedad distribuida .
  • Limite los datos anexados a menos de 1 GB por operación. Si es necesario, use varios comandos de actualización.
  • Establezca la distributed marca true en solo si la cantidad de datos que genera la consulta es grande, supera los 1 GB y no requiere serialización: varios nodos pueden generar resultados en paralelo. No use esta marca cuando los resultados de la consulta sean pequeños, ya que puede generar innecesariamente muchas particiones de datos pequeñas.

Ejemplos

Para ver los ejemplos, vamos a usar la tabla siguiente:

.set-or-replace Employees <|
  range i from 1 to 100 step 1
  | project Id=i
  | extend Code = tostring(dynamic(["Customer", "Employee"])[Id %2])
  | extend Color = tostring(dynamic(["Red", "Blue", "Gray"])[Id %3])

Este comando crea una tabla con 100 registros a partir de:

ID Código Color
1 Employee Azul
2 Customer Gris
3 Employee Rojo
4 Customer Azul
5 Employee Gris
6 Customer Rojo
6 Employee Azul

Actualización de una sola columna en una fila

En el ejemplo siguiente se actualiza una sola columna en una sola fila:

.update table Employees delete D append A with(whatif=true) <|
    let D = Employees
      | where Id==3;
    let A = Employees
      | where Id==3
      | extend Color="Orange";

Observe que whatif se establece en true. Después de esta consulta, la tabla no cambia, pero el comando devuelve que habría una extensión con una fila eliminada y una nueva extensión con una fila.

El siguiente comando realiza realmente la actualización:

.update table Employees delete D append A <|
    let D = Employees
      | where Id==3;
    let A = Employees
      | where Id==3
      | extend Color="Orange";

Actualización de una sola columna en varias filas

En el ejemplo siguiente se actualiza en una sola columna Color el valor de Green en esas filas que tienen el valor azul.

.update table Employees delete D append A <|
    let D = Employees
        | where Code=="Employee"
        | where Color=="Blue";
    let A = D
      | extend Color="Green";

Aquí hemos reutilizado el identificador de eliminación en la definición del predicado append.

Actualización de varias columnas en varias filas

En el ejemplo siguiente se actualizan varias columnas de todas las filas con color gris.

.update table Employees delete D append A <|
    let D = Employees
      | where Color=="Gray";
    let A = D
      | extend Code=strcat("ex-", Code)
      | extend Color="";

Actualización de filas mediante otra tabla

En este ejemplo, el primer paso es crear la tabla de asignación siguiente:

.set-or-replace ColorMapping <|
  datatable(OldColor:string, NewColor:string)[
    "Red", "Pink",
    "Blue", "Purple",
    "Gray", "LightGray",
    "Orange", "Yellow",
    "Green", "AppleGreen"
  ]

A continuación, esta tabla de asignación se usa para actualizar algunos colores de la tabla original:

.update table Employees delete D append A <|
  let D = Employees
    | where Code=="Customer";
  let A = D
    | lookup ColorMapping on $left.Color==$right.OldColor
    | project Id, Code, Color=NewColor

Actualización de filas con una tabla de almacenamiento provisional

Un patrón popular consiste en colocar primero los datos en una tabla de ensayo antes de actualizar la tabla principal.

El primer comando crea una tabla de almacenamiento provisional:

.set-or-replace MyStagingTable <|
    range i from 70 to 130 step 5
    | project Id=i
    | extend Code = tostring(dynamic(["Customer", "Employee"])[Id %2])
    | extend Color = tostring(dynamic(["Red", "Blue", "Gray"])[Id %3])

El siguiente comando actualiza la tabla principal con los datos de la tabla de almacenamiento provisional:

.update table Employees delete D append A <|
    let A = MyStagingTable;
    let D = Employees
        | join kind=leftsemi MyStagingTable on Id
        | where true;

Algunos registros de la tabla de almacenamiento provisional no existían en la tabla principal (es decir, tenían Id>100) pero todavía se insertaron en la tabla principal (comportamiento upsert).

Clave compuesta

El primer comando crea una tabla con claves compuestas:

.set-or-replace VersionedArticle <|
  datatable(ArticleId:string, Version:int, Detail:string)[
    "A", 1, "Early version",
    "B", 1, "News about mobiles",
    "C", 1, "Opinion article",
    "B", 2, "Revision about brand X",
    "B", 3, "Revision about brand Y",
    "C", 2, "Fact check"
  ]

El siguiente comando actualiza un registro específico mediante la sintaxis expandida:

.update table VersionedArticle delete D append A <|
  let D = VersionedArticle
    | where ArticleId=="B"
    | where Version==3;
  let A = VersionedArticle
    | where ArticleId=="B"
    | where Version==3
    | extend Detail = "Revision about brand Z";

Contenido relacionado