Introducción a la eliminación temporal

Como plataforma de datos, Azure Data Explorer admite la capacidad de eliminar registros individuales. Normalmente, la eliminación de registros se logra mediante uno de los métodos siguientes:

• Para eliminar registros con una garantía del sistema de que también se eliminan los artefactos de almacenamiento que contienen estos registros, use . .purge
• Para eliminar registros sin esta garantía, use .delete como se describe en este artículo: este comando marca los registros como eliminados, pero no elimina necesariamente los datos de los artefactos de almacenamiento. Este método de eliminación es más rápido que purgar.

Para obtener información sobre cómo usar el comando , vea Sintaxis.

Casos de uso

Este método de eliminación solo se debe usar para la eliminación no planeada de registros individuales. Por ejemplo, si detecta que un dispositivo IoT informa de telemetría dañada durante algún tiempo, debe considerar la posibilidad de usar este método para eliminar los datos dañados.

Si necesita eliminar registros con frecuencia para la desduplicación o actualizaciones, se recomienda usar vistas materializadas. Consulte Elegir entre vistas materializadas y eliminación temporal para la desduplicación de datos.

Proceso de eliminación

El proceso de eliminación temporal se realiza mediante los pasos siguientes:

1. Ejecutar consulta de predicado: la tabla se examina para identificar las extensiones de datos que contienen registros que se van a eliminar. Las extensiones identificadas son aquellas con uno o varios registros devueltos por la consulta de predicado.
2. Reemplazo de extensiones: las extensiones identificadas se reemplazan por nuevas extensiones que apuntan a los blobs de datos originales y también tienen una nueva columna oculta de tipo bool que indica por registro si se eliminó o no. Una vez completado, si no se ingieren nuevos datos, la consulta de predicado no devolverá ningún registro si se vuelve a ejecutar.

Limitaciones y consideraciones

• El proceso de eliminación es definitivo e irreversible. No es posible deshacer este proceso ni recuperar los datos que se han eliminado, aunque los artefactos de almacenamiento no se eliminen necesariamente después de la operación.

• La eliminación temporal es compatible con tablas nativas y vistas materializadas. No se admite para tablas externas.

• Antes de ejecutar la eliminación temporal, compruebe el predicado mediante la ejecución de una consulta y compruebe que los resultados coinciden con el resultado esperado. También puede ejecutar el comando en whatif modo , que devuelve el número de registros que se espera que se eliminen.

• No ejecute varias operaciones de eliminación temporal paralelas en la misma tabla, ya que esto puede provocar errores de algunos o todos los comandos. Sin embargo, es posible ejecutar varias operaciones de eliminación temporal paralelas en tablas diferentes.

• No ejecute comandos de eliminación temporal y purga en la misma tabla en paralelo. En primer lugar, espere a que se complete un comando y solo ejecute el otro comando.

• La eliminación temporal se ejecuta en el URI del clúster: https://[YourClusterName].[region].kusto.windows.net. El comando requiere permisos de administrador de base de datos en la base de datos pertinente.

• La eliminación de registros de una tabla que es una tabla de origen de una vista materializada puede tener un impacto en la vista materializada. Si el ciclo de materialización no procesó aún los registros que se van a eliminar, estos registros faltarán en la vista, ya que nunca se procesarán. Del mismo modo, la eliminación no tendrá un impacto en la vista materializada si los registros ya se han procesado.

• Limitaciones del predicado:

  • Debe contener al menos un where operador.
  • Solo puede hacer referencia a la tabla desde la que se van a eliminar los registros.
  • Solo se permiten los operadores siguientes: extend, order, projecttake y where. Dentro toscalar()de , también se permite el summarize operador .

Rendimiento de eliminación

Las consideraciones principales que pueden afectar al rendimiento del proceso de eliminación son:

• Ejecutar consulta de predicado: el rendimiento de este paso es muy similar al rendimiento del propio predicado. Puede ser ligeramente más rápido o más lento en función del predicado, pero se espera que la diferencia sea insignificante.
• Reemplazo de extensiones: el rendimiento de este paso depende de lo siguiente:
  • Distribución de registros entre las extensiones de datos del clúster
  • Número de nodos del clúster

A diferencia .purgede , el .delete comando no vuelve a generar los datos. Simplemente marca los registros devueltos por la consulta de predicado como eliminados y, por tanto, es mucho más rápido.

Rendimiento de las consultas después de la eliminación

No se espera que el rendimiento de las consultas cambie notablemente después de la eliminación de registros.

No se espera una degradación del rendimiento porque el filtro que se agrega automáticamente en todas las consultas que filtran los registros eliminados es eficaz.

Sin embargo, tampoco se garantiza que el rendimiento de las consultas mejore. Aunque la mejora del rendimiento puede producirse para algunos tipos de consultas, es posible que no se produzca para otros. Para mejorar el rendimiento de las consultas, las extensiones en las que se eliminan la mayoría de los registros se compactan periódicamente reemplazando por nuevas extensiones que solo contienen los registros que no se han eliminado.

Impacto en el COGS (costo de las mercancías vendidas)

En la mayoría de los casos, la eliminación de registros no dará lugar a un cambio de COGS.

• No habrá ninguna disminución, ya que realmente no se eliminan registros. Los registros solo se marcan como eliminados mediante una columna oculta de tipo bool, cuyo tamaño es insignificante.
• En la mayoría de los casos, no habrá ningún aumento porque la .delete operación no requiere el aprovisionamiento de recursos adicionales.
• En algunos casos, las extensiones en las que se eliminan la mayoría de los registros se compactan periódicamente reemplazando por nuevas extensiones que solo contienen los registros que no se han eliminado. Esto provoca la eliminación de los artefactos de almacenamiento antiguos que contienen un gran número de registros eliminados. Las nuevas extensiones son más pequeñas y, por tanto, consumen menos espacio en la cuenta de almacenamiento y en la caché activa. Sin embargo, en la mayoría de los casos, el efecto de esto en COGS es insignificante.