As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Otimizar a performance da consulta

QLDBO objetivo da Amazon é atender às necessidades de cargas de trabalho de processamento de transações on-line (OLTP) de alto desempenho. Isso significa que QLDB é otimizado para um conjunto específico de padrões de consulta, embora ofereça suporte a recursos de consulta SQL semelhantes aos de. É 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.

Esta seção descreve as restrições de consulta QLDB e fornece orientação para escrever consultas ideais considerando essas restrições.

Tempo limite de transação

EmQLDB, cada instrução partiQL (incluindo cada SELECT consulta) é processada em uma transação e está sujeita a um limite de tempo limite de transação. Uma transação pode ser executada por até 30 segundos antes de ser confirmada. Após esse limite, 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

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

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 um ID de documento. QLDBrequer um operador de igualdade (=ouIN) 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. Eles também podem levar a OCC conflitos 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 não OCC 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. QLDBo histórico é indexado somente pela 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. 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 emQLDB:

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 QLDB dados 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 GitHub repositório amazon-qldb-streaming-amazonaws-samples/ -. opensearch-service-sample-python Para obter informações sobre QLDB streams, consulteStreaming de dados de diários da Amazon QLDB.

Monitorar o desempenho

O QLDB driver 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 CloudWatch a Amazon para monitorar o desempenho do seu livro contábil para operações de dados. Monitore a métrica CommandLatency para um determinado LedgerName e CommandType. Para ter mais informações, consulte Monitoramento com a Amazon CloudWatch. Para saber como QLDB usa comandos para gerenciar operações de dados, consulteGerenciamento da sessão com o driver.