Otimizar a performance da consulta

O Amazon QLDB é destinado a atender às necessidades de workloads de processamento de transações online (OLTP). Isso significa que o QLDB é otimizado para um conjunto específico de padrões de consulta, embora ofereça suporte a recursos de consulta semelhantes ao SQL. É fundamental projetar aplicativos e seus modelos de dados para trabalhar com esses padrões de consulta. Caso contrário, à medida que suas tabelas crescerem, você encontrará problemas significativos de desempenho, incluindo latência de consultas, tempos limite de transação e conflitos de simultaneidade.

Essa seção descreve restrições de consulta no QLDB e fornece orientação para escrever consultas ideais dadas essas restrições.

Tempo limite de transação

No QLDB, cada instrução PartiQL (incluindo cada consulta SELECT) é processada em uma transação e está sujeita a um limite de tempo de espera de transações. Uma transação pode ser executada por até 30 segundos antes de ser confirmada. Após esse limite de tempo, o QLDB rejeita qualquer trabalho realizado na transação e descarta a sessão que executou a transação. Esse limite protege o cliente de sessões vazadas ao iniciar transações e não confirmá-las ou cancelá-las.

Conflitos de concorrência

O QLDB implementa o controle de concorrência usando o controle de concorrência otimista (OCC). Consultas inadequadas também podem levar a mais conflitos de OCC. Para obter mais informações sobre OCC, consulte Modelo de simultaneidade do Amazon QLDB.

Padrões de consulta ideais

Como prática recomendada, você deve executar instruções com uma cláusula de predicado WHERE que filtre em um campo indexado ou em uma ID de documento. O QLDB requer um operador de igualdade (= ou IN) em um campo indexado para pesquisar um documento com eficiência.

Veja a seguir exemplos de padrões de consulta ideais na visualização do usuário.

--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'

Qualquer consulta que não siga esses padrões invoca uma varredura completa da tabela. As varreduras de tabelas podem causar tempos limite de transação para consultas em tabelas grandes ou consultas que retornam grandes conjuntos de resultados. Também podem levar a conflitos de OCC com transações concorrentes.

Índices de alta cardinalidade

Recomendamos a indexação de campos que contenham valores de alta cardinalidade. Por exemplo, os campos VIN e LicensePlateNumber na tabela VehicleRegistration são campos indexados que devem ser exclusivos.

Evite indexar campos de baixa cardinalidade, como códigos de status, estados ou províncias de endereço e códigos postais. Se você indexar esse campo, suas consultas poderão produzir grandes conjuntos de resultados com maior probabilidade de resultar em tempos limite de transação ou causar conflitos de OCC não intencionais.

Consultas de visualização comprometidas

As consultas que você executa na visualização confirmada seguem as mesmas diretrizes de otimização das consultas de visualização do usuário. Os índices que você cria em uma tabela também são usados para consultas na exibição confirmada.

Consultas de funções de histórico

As consultas de função de histórico não usam os índices que você cria em uma tabela. O histórico do QLDB é indexado por ID do documento, e você não pode criar índices de histórico adicionais no momento.

Como prática recomendada, qualifique uma consulta de histórico com um intervalo de datas (hora de início e hora de término) e um ID de documentos (metadata.id). As consultas de histórico que incluem uma hora de início e uma hora de término ganham o benefício da qualificação por intervalo de datas.

Consultas de junção interna

Para consultas de junção interna, use critérios de junção que incluam pelo menos um campo indexado para a tabela no lado direito da junção. Sem um índice de junção, uma consulta de junção invoca várias varreduras de tabela. Para cada documento na tabela esquerda da junção, a consulta digitaliza totalmente a tabela direita. A melhor prática é unir campos indexados para cada tabela que você está unindo, além de especificar um predicado de igualdade WHERE para pelo menos uma tabela.

Por exemplo, a consulta a seguir une as tabelas VehicleRegistration e Vehicle em seus respectivos campos VIN, ambos indexados. Essa consulta também tem um predicado de igualdade em VehicleRegistration.VIN.

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

Escolha índices de alta cardinalidade para os critérios de junção e os predicados de igualdade em sua consulta de junção .

Padrões de consulta a serem evitados

A seguir estão alguns exemplos de declarações abaixo do ideal que não se adaptam bem a tabelas maiores no QLDB. É altamente recomendável que você não confie nesses tipos de consultas para tabelas que crescem com o tempo, pois suas consultas acabarão resultando em tempos limite de transação. Como as tabelas contêm documentos que variam em tamanho, é difícil definir limites precisos para consultas não 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)

Em geral, não recomendamos executar os seguintes tipos de padrões de consulta para casos de uso de produção no QLDB:

• Consultas de processamento analítico on-line (OLAP)

• Consultas exploratórias sem uma cláusula de predicado

• Consultas de relatórios

• Busca de texto

Em vez disso, recomendamos transmitir seus dados para um serviço de banco de dados com propósito específico que seja otimizado para casos de uso analítico. Por exemplo, você pode transmitir dados do QLDB para o Amazon OpenSearch Service para fornecer recursos de pesquisa de texto completo em documentos. Para ver um aplicativo de amostra que demonstra esse caso de uso, consulte o repositório do GitHub aws-samples/amazon-qldb-streaming-amazon-opensearch-service-sample-python. Para obter informações sobre fluxos no QLDB, consulte Stream de dados do diário do Amazon QLDB.

Monitorar o desempenho

O driver QLDB fornece informações de tempo e uso de E/S consumidas no objeto resultante de uma instrução. Você pode usar essas métricas para identificar instruções PartiQL ineficientes. Para saber mais, vá para Obter estatísticas de instruções PartiQL.

Você também pode usar o Amazon CloudWatch para monitorar o desempenho de seu livro-ledger para operações de dados. Monitore a métrica CommandLatency para um determinado LedgerName e CommandType. Para obter mais informações, consulte Monitoramento com a Amazon CloudWatch. Para saber como o QLDB usa comandos para gerenciar operações de dados, consulte Gerenciamento da sessão com o driver.