Directiva de almacenamiento en caché (caché activa y inactiva)

Azure Data Explorer usa un sistema de caché de datos de niveles múltiples para garantizar un rendimiento rápido de las consultas. Los datos se almacenan en almacenamiento confiable, como Azure Blob Storage, pero partes de ellos se almacenan en caché en nodos de procesamiento, SSD o incluso en RAM para un acceso más rápido.

Real-Time Analytics usa un sistema de caché de datos de niveles múltiples para garantizar un rendimiento rápido de las consultas. Los datos se almacenan en un almacenamiento confiable, como OneLake, pero las partes de ellos se almacenan en caché en nodos de procesamiento, SSD o incluso en RAM para un acceso más rápido.

La directiva de almacenamiento en caché permite elegir qué datos se deben almacenar en caché. Puede diferenciar entre la caché de datos activa y la caché de datos en frío estableciendo una directiva de almacenamiento en caché en los datos activos. Los datos activos se mantienen en el almacenamiento SSD local para un rendimiento de consulta más rápido, mientras que los datos en frío se almacenan en un almacenamiento confiable, lo que es más barato pero más lento para acceder.

La memoria caché usa el 95 % del disco SSD local para los datos activos. Si no hay espacio suficiente, los datos más recientes se mantienen preferentemente en la memoria caché. El 5 % restante se usa para los datos que no se clasifican como activos. Este diseño garantiza que las consultas que cargan muchos datos en frío no expulsarán los datos activos de la memoria caché.

El mejor rendimiento de las consultas se logra cuando se almacenan en caché todos los datos ingeridos. Sin embargo, algunos datos podrían no garantizar el gasto de mantenerse en la caché activa. Por ejemplo, los registros antiguos a los que se accede con poca frecuencia pueden considerarse menos cruciales. En tales casos, los equipos suelen optar por reducir el rendimiento de las consultas en comparación con el pago para mantener la preparación de los datos.

Use comandos de administración para modificar la directiva de almacenamiento en caché en el nivel de vista materializado, tabla o base de datos.

Use comandos de administración para modificar la directiva de almacenamiento en caché en el nivel de vista materializado, base de datos, base de datos o clúster.

Sugerencia

El clúster está diseñado para consultas ad hoc con conjuntos de resultados intermedios que caben en la RAM total del clúster. Para trabajos grandes, como map-reduce, puede ser útil almacenar resultados intermedios en el almacenamiento persistente. Para ello, cree un trabajo de exportación continua . Esta característica le permite realizar consultas por lotes de ejecución prolongada mediante servicios como HDInsight o Azure Databricks.

Aplicación de la directiva de almacenamiento en caché

Cuando se ingieren datos, el sistema realiza un seguimiento de la fecha y hora de la ingesta y de la extensión que se creó. El valor de fecha y hora de ingesta de la extensión (o el valor máximo, si se creó una extensión a partir de varias extensiones preexistentes), se usa para evaluar la directiva de almacenamiento en caché.

Nota

Puede especificar un valor para la fecha y hora de ingesta mediante la propiedad creationTimede ingesta . Al hacerlo, asegúrese de que la Lookback propiedad de la directiva de combinación extensiones efectiva de la tabla está alineada con los valores establecidos para creationTime.

De forma predeterminada, la directiva efectiva es null, lo que significa que todos los datos se consideran activos. Una null directiva en el nivel de tabla significa que la directiva se heredará de la base de datos. null Una directiva de nivel de tabla invalida una directiva de nivel de base de datos.

Determinación del ámbito de las consultas a la caché activa

Al ejecutar consultas, puede limitar el ámbito a consultar solo los datos de la caché activa.

Nota

El ámbito de datos solo se aplica a las entidades que admiten directivas de almacenamiento en caché, como tablas y vistas materializadas. Se omite para otras entidades, como tablas externas y datos en el almacén de filas.

Hay varias posibilidades de consulta:

  • Agregue una propiedad de solicitud de cliente llamada query_datascope a la consulta. Valores posibles: default, all y hotcache.
  • Use una set instrucción en el texto de la consulta: set query_datascope='...'. Los valores posibles son los mismos que para la propiedad de solicitud de cliente.
  • Agregue un datascope=... texto inmediatamente después de una referencia de tabla en el cuerpo de la consulta. Los valores posibles son all y hotcache.

El default valor indica el uso de la configuración predeterminada del clúster, que determina que la consulta debe cubrir todos los datos.

Si hay una discrepancia entre los distintos métodos, set tiene prioridad sobre la propiedad de solicitud de cliente. Especificar un valor para una referencia de tabla tiene prioridad sobre ambos.

Por ejemplo, en la consulta siguiente, todas las referencias de tabla solo usan datos de caché activa, excepto la segunda referencia a "T", cuyo ámbito es todos los datos:

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Directiva de almacenamiento en caché frente a directiva de retención

La directiva de almacenamiento en caché es independiente de la directiva de retención:

  • La directiva de almacenamiento en caché define cómo priorizar los recursos. Las consultas de datos importantes son más rápidas.
  • La directiva de retención define la extensión de los datos consultables en una tabla o base de datos (en concreto, SoftDeletePeriod).

Configure esta directiva para lograr el equilibrio óptimo entre el costo y el rendimiento, en función del patrón de consulta esperado.

Ejemplo:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

En el ejemplo, los últimos 28 días de datos estarán en el SSD del clúster y los 28 días adicionales de los datos se almacenarán en Azure Blob Storage. Puede ejecutar consultas en los 56 días completos de los datos.