Optimización del rendimiento de las consultas - Base de datos Amazon Quantum Ledger (AmazonQLDB)

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Optimización del rendimiento de las consultas

importante

Aviso de fin de soporte: los clientes actuales podrán usar Amazon QLDB hasta que finalice el soporte, el 31 de julio de 2025. Para obtener más información, consulte Migración de un Amazon QLDB Ledger a Amazon Aurora SQL Postgre.

Amazon QLDB tiene como objetivo abordar las necesidades de las cargas de trabajo de procesamiento de transacciones en línea (OLTP) de alto rendimiento. Esto significa que QLDB está optimizado para un conjunto específico de patrones de consulta, aunque admite capacidades de consulta SQL similares. Es fundamental diseñar las aplicaciones y sus modelos de datos para que funcionen con estos patrones de consulta. De lo contrario, a medida que las tablas crezcan, se producirán importantes problemas de rendimiento, como la latencia de las consultas, los tiempos de espera de las transacciones y los conflictos de concurrencia.

En esta sección se describen las restricciones de consulta QLDB y se proporciona orientación para escribir consultas óptimas en función de estas restricciones.

Límite de tiempo de espera de transacción

EnQLDB, cada sentencia PartiQL (incluidas todas las SELECT consultas) se procesa en una transacción y está sujeta a un límite de tiempo de espera de la transacción. Una transacción puede ejecutarse durante un máximo de 30 segundos antes de confirmarse. Tras este límite, QLDB rechaza cualquier trabajo realizado en la transacción y descarta la sesión en la que se ejecutó la transacción. Este límite evita que el cliente de sesión pierda sesiones al iniciar transacciones y no confirmarlas ni cancelarlas.

Conflictos de concurrencia

QLDBimplementa el control de simultaneidad mediante un control de simultaneidad optimista (). OCC Las consultas subóptimas también pueden generar más conflictos. OCC Para obtener más información sobre OCC, consulte Modelo de QLDB simultaneidad de Amazon.

Patrones de consulta óptimos

Como práctica recomendada, debe ejecutar las instrucciones con una cláusula de predicado WHERE que filtre por campo indexado o por identificador de documento. QLDBrequiere un operador de igualdad (=oIN) en un campo indexado para buscar un documento de manera eficiente.

Los siguientes son ejemplos de patrones de consulta óptimos en la vista de usuario.

--Indexed field (VIN) lookup using the = operator SELECT * FROM VehicleRegistration WHERE VIN = '1N4AL11D75C109151' --Indexed field (VIN) AND non-indexed field (City) lookup SELECT * FROM VehicleRegistration WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle' --Indexed field (VIN) lookup using the IN operator SELECT * FROM VehicleRegistration WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761') --Document ID (r_id) lookup using the BY clause SELECT * FROM VehicleRegistration BY r_id WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'

Cualquier consulta que no siga estos patrones invoca un escaneado completo de la tabla. Los escaneos de tablas pueden provocar tiempos de espera de transacción para consultas en tablas grandes o consultas que devuelven conjuntos de resultados de gran tamaño. También pueden provocar OCC conflictos con transacciones competidoras.

Índices de alta cardinalidad

Se recomienda indexar los campos que contienen valores de cardinalidad alta. Por ejemplo, los campos VIN y LicensePlateNumber de la tabla VehicleRegistration son campos indexados concebidos para ser únicos.

Evite indexar campos de baja cardinalidad, como códigos de estado, direcciones, estados o provincias y códigos postales. Si indexa un campo de este tipo, las consultas pueden producir conjuntos de resultados grandes que tienen más probabilidades de provocar tiempos de espera en las transacciones o provocar conflictos no deseados OCC.

Consultas de vista confirmada

Las consultas que se ejecutan en la vista confirmada siguen las mismas pautas de optimización que las consultas de vista de usuario. Los índices que se crean en una tabla también se utilizan para las consultas en la vista confirmada.

Consultas de la función historial

Las consultas de la función historial no utilizan los índices creados en una tabla. QLDBel historial se indexa únicamente por identificador de documento y, por el momento, no se pueden crear índices de historial adicionales.

Como práctica recomendada, califique una consulta de historial con un intervalo de fechas (hora de inicio y hora de finalización) y un identificador de documento (metadata.id). Las consultas de historial que incluyen una hora de inicio y una hora de finalización se benefician de la calificación por intervalo de fechas.

Consultas de Ion internas

Para las consultas de combinación internas, utilice criterios de combinación que incluyan al menos un campo indexado para la tabla del lado derecho de la combinación. Sin un índice de combinación, una consulta de combinación invoca varios escaneos de tabla: para cada documento de la tabla izquierda de la combinación, la consulta escanea completamente la tabla derecha. La práctica recomendada consiste en combinar los campos que estén indexados para cada tabla a la que vaya a combinar, además de especificar un predicado de igualdad WHERE para al menos una tabla.

Por ejemplo, la siguiente consulta combina las tablas VehicleRegistration y Vehicle de sus campos VIN respectivos, ambos indexados. Esta consulta también tiene un predicado de igualdad en VehicleRegistration.VIN.

SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v ON r.VIN = v.VIN WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

Seleccione índices de cardinalidad alta tanto para los criterios de combinación como para los predicados de igualdad en sus consultas de combinación.

Patrones de consulta que deben evitarse

A continuación, se muestran algunos ejemplos de sentencias subóptimas que no se adaptan bien a tablas más grandes. QLDB Le recomendamos encarecidamente que no confíe en este tipo de consultas para las tablas que crecen con el tiempo, ya que sus consultas acabarán provocando tiempos de espera de las transacciones. Como las tablas contienen documentos que varían en tamaño, es difícil definir límites precisos para las consultas no indexadas.

--No predicate clause SELECT * FROM Vehicle --COUNT() is not an optimized function SELECT COUNT(*) FROM Vehicle --Low-cardinality predicate SELECT * FROM Vehicle WHERE Color = 'Silver' --Inequality (>) does not qualify for indexed lookup SELECT * FROM Vehicle WHERE "Year" > 2019 --Inequality (LIKE) SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%' --Inequality (BETWEEN) SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T` --No predicate clause DELETE FROM Vehicle --No document id, and no date range for the history() function SELECT * FROM history(Vehicle)

En general, no recomendamos ejecutar los siguientes tipos de patrones de consulta para los casos de uso de producción en: QLDB

  • Consultas de procesamiento analítico en línea (OLAP)

  • Consultas exploratorias sin cláusula de predicado

  • Consultas de informes

  • Búsqueda de texto

En su lugar, recomendamos transmitir los datos a un servicio de base de datos personalizada y optimizado para casos de uso analíticos. Por ejemplo, puedes transmitir QLDB datos a Amazon OpenSearch Service para proporcionar capacidades de búsqueda de texto completo en los documentos. Para ver un ejemplo de aplicación que muestre este caso de uso, consulte el GitHub repositorio amazon-qldb-streaming-amazonaws-samples/ -. opensearch-service-sample-python Para obtener información sobre las transmisiones, consulteQLDB. Transmisión de datos de revistas desde Amazon QLDB

Monitorear el desempeño

El QLDB controlador proporciona información sobre el uso de E/S consumido y la temporización en el objeto de resultado de una sentencia. Puede utilizar estas métricas para identificar instrucciones PartiQL ineficientes. Para obtener más información, consulte Obtener estadísticas de instrucciones PartiQL.

También puedes usar Amazon CloudWatch para realizar un seguimiento del rendimiento de tu libro mayor para las operaciones de datos. Supervise la métrica CommandLatency para un LedgerName y CommandType específicos. Para obtener más información, consulte Monitorización con Amazon CloudWatch. Para saber cómo se QLDB utilizan los comandos para gestionar las operaciones de datos, consulteGestión de sesiones con el controlador.