Optimizar el rendimiento de las consul‎tas‎

El objetivo de Amazon QLDB es abordar las necesidades de las cargas de trabajo de procesamiento de transacciones online (OLTP) de alto rendimiento. Esto significa que QLDB está optimizada para un conjunto específico de patrones de consulta, aunque admite capacidades de consulta similares a las de SQL. 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.

Esta sección describe las restricciones de consulta en QLDB y guía sobre cómo escribir consultas óptimas dadas estas restricciones.

Límite de tiempo de espera de transacción

En QLDB, cada instrucción de PartiQL (incluida cada consulta SELECT) 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 que 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

QLDB implementa el control de concurrencia mediante el control de concurrencia optimista (OCC). Las consultas subóptimas también pueden provocar más conflictos de OCC. Para obtener más información acerca de OCC, consulte Modelo de concurrencia de Amazon QLDB.

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. QLDB requiere un operador de igualdad (= o IN) 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 conflictos de OCC 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 de OCC no deseados.

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. El historial de QLDB solo se indexa por ID de documento y no se pueden crear índices de historial adicionales de momento.

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

Los siguientes son algunos ejemplos de instrucciones subóptimas que no se escalan bien para tablas más grandes en 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

• Text search

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, puede transmitir datos de QLDB a Amazon OpenSearch Service para ofrecer capacidades de búsqueda de texto completo en los documentos. Para ver un ejemplo de aplicación que demuestre este caso de uso, consulte el repositorio de GitHub aws-samples/amazon-qldb-streaming-amazon-opensearch-service-sample-python. Para obtener información acerca de secuencias QLDB, consulte Transmisión de datos de diarios desde Amazon QLDB.

Monitorear el desempeño

El controlador de QLDB proporciona información sobre el uso de E/S consumido y la temporización en el objeto resultado de una instrucción. 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 puede utilizar Amazon CloudWatch para realizar un seguimiento del rendimiento de su 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 obtener información sobre cómo QLDB utiliza los comandos para administrar las operaciones de datos, consulte Gestión de sesiones con el controlador.