El diagnóstico de almacenamiento le ayuda a identificar sesgos de datos, claves de partición subóptimas, índices excesivos y otros problemas de configuración de tablas en su clúster de AnalyticDB for MySQL. En la página Storage Diagnostics, evalúe la idoneidad de las claves de partición, las claves de distribución y las tablas replicadas. También identifique oportunidades para separar datos fríos y calientes, y reciba sugerencias de optimización de índices. Al aplicar estas sugerencias, optimice el esquema de su base de datos, reduzca los costos del clúster y mejore la eficiencia.
Notas importantes
La optimización de tablas frías y calientes, así como el diagnóstico de índices, solo son compatibles con clústeres que ejecutan Milvus versión 3.1.4 o posterior.
Las sugerencias para la optimización de tablas frías y calientes y el diagnóstico de índices se basan en un análisis histórico de los datos y los patrones de consulta. Estas sugerencias mantienen su eficacia mientras dichos patrones sean estables. Si cambian de forma significativa, la utilidad de las recomendaciones disminuye. Antes de usar esta función, evalúe si conviene aplicar las sugerencias según la carga de trabajo actual de su negocio.
Diagnóstico de tablas
Diagnóstico de sesgo de datos
Cuando create a table, use DISTRIBUTED BY HASH para especificar una clave de distribución. Una vez definida la clave, AnalyticDB for MySQL calcula un hash de sus valores y distribuye las filas entre distintos shards. Una distribución desigual de los datos entre los nodos de almacenamiento provoca un sesgo en el espacio de disco. Esto llena los discos antes de tiempo y bloquea las escrituras de datos.
Criterios de diagnóstico
AnalyticDB for MySQL diagnostica el sesgo de datos en tablas con más de 10 000 filas. El método de cálculo es el siguiente:
Excluya el shard más grande y calcule el tamaño promedio de los shards.
Si algún shard supera
average shard size × thresholdo es menor queaverage shard size / threshold, la tabla se considera sesgada. El umbral predeterminado es 3 y el rango válido es [0, 10000000000]. Ajuste el umbral al ejecutar el siguiente comando:SET ADB_CONFIG RC_DATA_SKEW_THRESHOLD=Value;.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
-
Click the Table Diagnostics tab to view the details in the Table Skew Diagnostics section.
Storage Node Disk Usage
Use la gráfica para comprobar el uso de disco entre los nodos de almacenamiento e identificar sesgos de espacio. Si existe un sesgo, optimice las tablas listadas en Top 10 Skewed Tables. Aunque el espacio parezca equilibrado, optimice las tablas que aparezcan en Top 10 Skewed Tables para evitar degradar el rendimiento de las consultas del clúster.
Top 10 Skewed Tables
Esta sección enumera las tablas con sesgo de datos, ordenadas por volumen total de datos de forma descendente. Para ver la cantidad de filas por shard y evaluar la gravedad del sesgo, haga clic en View Skew Details dentro de la columna Actions.
Métodos de optimización
Resuelva este problema mediante uno de los siguientes métodos:
-
Escale horizontalmente la capacidad de almacenamiento.
Los clústeres de Enterprise Edition requieren escalar los recursos reservados. Para obtener más información, consulte Scale an Enterprise Edition cluster.
Los clústeres de Basic Edition requieren escalar los recursos de cómputo. Para obtener más información, consulte Scale a Basic Edition cluster.
Los clústeres de Data Lakehouse Edition requieren escalar los recursos de almacenamiento reservados. Para obtener más información, consulte Scale up or down the Data Lakehouse Edition.
Los clústeres de Data Warehouse Edition (elastic mode) requieren escalar las unidades de E/S elásticas. Para obtener más información, consulte Scale a Data Warehouse Edition (elastic mode) cluster.
Los clústeres de Data Warehouse Edition (reserved mode) requieren escalar los grupos de nodos. Para obtener más información, consulte Scale a Data Warehouse Edition (reserved mode) cluster.
Elimine índices o particiones inactivos para reducir el uso de almacenamiento. Para obtener más información, consulte Index diagnostics.
Vuelva a crear la tabla y migre los datos. Para obtener más información, consulte CREATE TABLE.
Optimización de tablas frías y calientes
AnalyticDB for MySQL analiza la frecuencia de acceso a las tablas para identificar aquellas con poco tráfico y generar sugerencias de optimización. Aplique estas recomendaciones para ajustar la política de separación de datos fríos y calientes de sus tablas. Para obtener más información sobre esta separación, consulte Hot and cold data separation.
Criterios de diagnóstico
AnalyticDB for MySQL proporciona sugerencias de optimización para las tablas sin accesos en los últimos 15 días y con una tasa de acceso inferior al 1 %.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
On the Table Diagnostics tab, click Hot and Cold Table Optimization.
En la pestaña Available Optimization Suggestions, haga clic en Disable para habilitar la función de optimización de tablas frías y calientes. Si ya está habilitada en el clúster actual, omita este paso.
-
Haga clic en las pestañas Available Optimization Suggestions y Applied Optimization Suggestions para consultar las sugerencias disponibles y aplicadas.
Parámetro
Descripción
Suggestion ID
El ID de la sugerencia de optimización.
SQL
Los cambios de tabla y definición que requiere la sugerencia.
Optimization Type
Optimización de tablas frías y calientes.
Optimization Suggestion
Recomendación detallada para el tipo de optimización.
Expected Optimization Benefits
Ventaja esperada tras aplicar la sugerencia.
NotaLas ventajas esperadas son estimaciones basadas en estadísticas históricas, no valores exactos en tiempo real. Úselas únicamente como referencia.
Actions
Aplique la sugerencia actual mediante Apply.
Nota-
Después de hacer clic en Apply, AnalyticDB for MySQL cambia la política de almacenamiento de la tabla a COLD. Para cambiarla a MIXED o HOT, ejecute manualmente una instrucción ALTER. Para obtener más detalles, consulte Storage policies.
-
Haga clic en Apply para adoptar la sugerencia de optimización. Tras hacerlo, el clúster correspondiente ejecuta el cambio SQL y la sugerencia aparece en la pestaña Apply.
-
Hacer clic en Applied Optimization Suggestions tiene el mismo efecto que ejecutar el SQL en un cliente. Esta acción no se puede deshacer. Úsela con precaución.
-
Una vez emitido el SQL, la tabla debe completar una operación Build para que el cambio surta efecto. El sistema de base de datos activa Build automáticamente según reglas internas. Hasta que se active, el estado de la sugerencia permanece como "running". Después de activarse, cambia a "completed".
-
Diagnóstico de tablas replicadas
Al crear una tabla en AnalyticDB for MySQL, especifique la distribución broadcast con DISTRIBUTED BY BROADCAST. La tabla se crea entonces como tabla replicada, lo que almacena una copia idéntica de sus datos en cada shard. Si su carga de trabajo incluye uniones de alta concurrencia entre tablas grandes y pequeñas, como unir una tabla de hechos grande con una tabla de dimensiones pequeña, cree la tabla más pequeña como replicada. Esto reduce la transmisión de datos por la red interna del clúster y mejora la concurrencia de las consultas. Sin embargo, las tablas replicadas tienen un rendimiento de escritura deficiente y consumen mucho espacio de almacenamiento, lo cual afecta negativamente el rendimiento general de escritura del clúster de AnalyticDB for MySQL.
Criterios de diagnóstico
Una tabla replicada se considera ineficiente si contiene más de 20 000 filas.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Apply. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
On the Table Diagnostics tab, click Replicated Table Diagnostics.
Métodos de optimización
Cree una tabla estándar y migre los datos. Para obtener más información, consulte CREATE TABLE.
Diagnóstico de particiones
Diagnóstico de tablas particionadas
Si no configura correctamente el campo de partición al crear una tabla particionada, pueden ocurrir los siguientes problemas:
Particiones demasiado grandes, como las anuales donde todos los datos de un año residen en una sola partición, generan pocas particiones con volúmenes masivos de datos. Si una tarea Build se ejecuta sobre una partición así, consume recursos excesivos, como CPU y E/S de disco del nodo de almacenamiento, lo que afecta la estabilidad del clúster.
Particiones demasiado pequeñas, como las horarias donde los datos de cada hora residen en una sola partición, generan muchas particiones con datos mínimos. El clúster debe almacenar en caché metadatos extensos de particiones, lo que consume una cantidad significativa de memoria. Las consultas también necesitan examinar muchas particiones, lo que degrada su rendimiento.
¿Cuál es un tamaño de partición razonable?
El tamaño de la partición se mide por la cantidad de filas1 y escala proporcionalmente con la cantidad de shards2. Si un clúster tiene N shards, un tamaño de partición razonable es una cantidad de filas entre [1 millón × N] y [5 millones × N].
Por ejemplo, si un clúster tiene 64 shards, una cantidad razonable de filas por partición oscila entre 64 millones y 320 millones.
1Para consultar la cantidad de filas por partición, ejecute el siguiente comando:
SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;2Para consultar la cantidad de shards, ejecute el siguiente comando:
SELECT COUNT(1) FROM information_schema.kepler_meta_shards;
Diagnosticar si el campo de partición es adecuado
Criterios de diagnóstico
Un campo de partición se considera inadecuado si el 10 % o más de las particiones de una tabla tienen un tamaño irrazonable.
Por ejemplo, si una tabla tiene 100 particiones y 10 o más presentan un tamaño inadecuado, el campo de partición se marca como inadecuado.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Haga clic en la pestaña Partition Diagnostics para consultar las tablas particionadas inadecuadas y sus nombres específicos en la sección Partitioned Table Diagnostics.
Cómo ajustar el tamaño de partición al rango razonable
Si la herramienta de diagnóstico de particiones identifica particiones inadecuadas, utilice los siguientes métodos para ajustarlas.
Si la cantidad de filas de una partición está por debajo del límite inferior del rango razonable, la partición es demasiado pequeña. En este caso, aumente la granularidad de la partición. Por ejemplo, si un clúster tiene 64 shards, el rango razonable va de 64 millones a 320 millones de filas. Si una partición tiene menos de 64 millones de filas, cambie la partición de diaria a mensual.
-
Si la cantidad de filas de una partición supera el límite superior recomendado, la partición se considera demasiado grande y debe reducir su granularidad. Por ejemplo, si tiene 64 shards, la cantidad recomendada de filas por partición es de entre 64 millones y 320 millones. Si una partición contiene más de 320 millones de filas, se recomienda cambiar la partición de mensual a diaria.
Para obtener más información sobre cómo cambiar la granularidad de partición, consulte Change the partition function format.
Si la cantidad total de filas de una tabla está por debajo del límite inferior del rango razonable y no se espera que crezca hasta alcanzarlo, cree una tabla no particionada y migre los datos desde la tabla particionada.
Diagnóstico de tablas no particionadas
Si omite la cláusula PARTITION BY al crear una tabla, esta se crea como tabla no particionada. Las operaciones DML, como INSERT, UPDATE y DELETE, en tablas no particionadas suelen desencadenar tareas Build de tabla completa. Si la tabla contiene una cantidad excesiva de datos, estas tareas Build consumen mucho espacio temporal de disco, lo que aumenta el uso de disco en el nodo y puede provocar bloqueos. Las tareas Build en tablas grandes también consumen recursos considerables de E/S de disco y CPU, lo que degrada el rendimiento general del clúster.
Criterios de diagnóstico
Una tabla no particionada se considera ineficiente si contiene más de mil millones de filas.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Click the Partition Diagnostics tab to view Non-partitioned Table Diagnostics information.
Métodos de optimización
Cree una tabla particionada y migre los datos desde la tabla no particionada. Para obtener más información, consulte CREATE TABLE.
Diagnóstico de índices
AnalyticDB for MySQL analiza el uso de los índices y proporciona automáticamente sugerencias de optimización para aquellos que llevan mucho tiempo sin usarse. Aplique estas sugerencias para eliminar índices inactivos y reducir los costos de almacenamiento.
Diagnóstico de índices inactivos
Criterios de diagnóstico
Un índice se considera inactivo si no se ha utilizado en los últimos 15 días y su tasa de uso es inferior al 1 %.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Click the Index Diagnostics tab to view details for Indexes to Remove.
En la pestaña Available Optimization Suggestions, haga clic en Enable para habilitar el diagnóstico de índices. Omita este paso si la función ya está habilitada.
-
Haga clic en las pestañas Available Optimization Suggestions y Applied Optimization Suggestions para consultar las sugerencias disponibles y aplicadas.
Parámetro
Descripción
Suggestion ID
El ID de la sugerencia de optimización.
SQL
Los cambios de tabla y definición que requiere la sugerencia.
Optimization Type
Optimización de índices.
Optimization Suggestion
Recomendación detallada para el tipo de optimización.
Expected Optimization Benefits
Ventaja esperada tras aplicar la sugerencia.
NotaLas ventajas esperadas son estimaciones basadas en estadísticas históricas, no valores exactos en tiempo real. Úselas únicamente como referencia.
Actions
Aplique la sugerencia actual mediante Apply.
Nota-
Tras eliminar un índice, las consultas que filtren por esa columna tardarán más tiempo.
-
Hacer clic en Apply indica que acepta adoptar esta sugerencia de optimización. Después de hacer clic en Apply, el clúster correspondiente ejecuta los cambios SQL y esta sugerencia aparece en la pestaña Apply.
-
Hacer clic en Applied Optimization Suggestions tiene el mismo efecto que ejecutar el SQL en un cliente. Esta acción no se puede deshacer. Úsela con precaución.
-
Una vez emitido el SQL, la tabla debe completar una operación Build para que el cambio surta efecto. El sistema de base de datos activa Build automáticamente según reglas internas. Hasta que se active, el estado de la sugerencia permanece como "running". Después de activarse, cambia a "completed".
-
Diagnóstico de nuevos índices
Criterios de diagnóstico
Este diagnóstico identifica campos utilizados como filtros en consultas durante los últimos 15 días, pero que no están definidos como campos indexados.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Click the Index Diagnostics tab to view details for Indexes to Create.
En la pestaña Available Optimization Suggestions, haga clic en Enable para habilitar el diagnóstico de índices. Omita este paso si la función ya está habilitada.
-
Haga clic en las pestañas Enable y Available Optimization Suggestions para consultar las sugerencias disponibles y aplicadas.
Parámetro
Descripción
Applied Optimization Suggestions
El ID de la sugerencia de optimización.
Suggestion ID
El campo que se agregará como índice.
Index Fields
La instrucción SQL para crear el índice.
SQL
Sugerencia de creación de índice.
Optimization Type
Describe la frecuencia con la que se utilizó el campo recientemente, lo que indica su potencial como campo indexado.
Aplique la sugerencia actual mediante Optimization Suggestion.
NotaDespués de usar Batch Create, la tabla debe completar una operación Build para que el cambio surta efecto. El sistema de base de datos activa Build automáticamente según reglas internas. Hasta que se active, el estado de la sugerencia permanece como "running". Después de activarse, cambia a "completed".
Diagnóstico de índices de clave primaria
Criterios de diagnóstico
Se considera que una tabla tiene una cantidad excesiva de claves primarias si posee más de tres campos de clave primaria y estos constituyen como mínimo la mitad de todos los campos de la tabla.
Procedimiento
Inicie sesión en la consola de AnalyticDB for MySQL. En la esquina superior izquierda de la consola, seleccione una región. En el panel de navegación izquierdo, haga clic en Clusters. Busque el clúster que desea gestionar y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Click the Storage Diagnostics tab to view details for Index Diagnostics.
En la pestaña Primary Key Diagnostics, haga clic en Available Optimization Suggestions para habilitar el diagnóstico de índices. Omita este paso si la función ya está habilitada.
Consulte las tablas que tienen una cantidad excesiva de claves primarias. La tabla muestra las siguientes columnas: Enable, Database, Table Name y Table Fields.
Preguntas frecuentes
¿Por qué el estado de la tarea de optimización permanece como "running" después de hacer clic en Apply now en una sugerencia de optimización de tablas frías y calientes?
Causa: Después de hacer clic en Primary Key Fields, AnalyticDB for MySQL cambia la política de almacenamiento de la tabla a COLD. Este cambio requiere una operación Build para surtir efecto. La función de optimización de datos fríos y calientes no desencadena una tarea Build de inmediato. El sistema activa esta tarea automáticamente más adelante.
Solución: Espere a que el sistema trigger the Build task automatically, o copie la instrucción SQL que desencadena la tarea Build desde la consola y ejecútela manualmente. Una vez ejecutada la tarea Build, compruebe su estado al correr el siguiente comando: SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10;.
API relacionadas
|
API |
Descripción |
|
Consulte las tablas con claves primarias excesivas en clústeres de Enterprise Edition, Basic Edition y Data Lakehouse Edition. |
|
|
Consulte el diagnóstico de particiones para clústeres de Data Warehouse Edition. |