Visão geral
Nesta página, você verá conceitos sobre planos de execução de consulta e como eles são usados pelo Spanner para executar consultas em um ambiente distribuído. Para saber como recuperar um plano de execução para uma consulta específica usando o console do Google Cloud, consulte Noções básicas sobre como o Spanner executa consultas. Também é possível ver planos de consulta históricos de amostra e comparar o desempenho de uma consulta ao longo do tempo em relação a determinadas consultas. Para saber mais, acesse Planos de consulta de amostra.
O Spanner usa instruções SQL declarativas para consultar os bancos de dados. As instruções SQL definem o que o usuário quer sem especificar como conseguir os resultados. Um plano de execução de consulta é o conjunto de etapas para alcançar os resultados. Para uma determinada instrução SQL, pode haver várias maneiras de conseguir os resultados. O otimizador de consultas do Spanner avalia diferentes planos de execução e escolhe o que considera mais eficiente. Em seguida, o Spanner usa o plano de execução para recuperar os resultados.
Conceitualmente, um plano de execução é uma árvore de operadores relacionais. Cada operador lê as linhas de entrada e produz linhas de saída. O resultado do operador na raiz da execução é retornado como resultado da consulta SQL.
Como exemplo, esta consulta:
SELECT s.SongName FROM Songs AS s;
resulta em um plano de execução de consulta que pode ser visualizado como:
As consultas e os planos de execução dessa página se baseiam no esquema de banco de dados abaixo:
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX),
BirthDate DATE
) PRIMARY KEY(SingerId);
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName);
CREATE TABLE Albums (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
AlbumTitle STRING(MAX),
MarketingBudget INT64
) PRIMARY KEY(SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) STORING (MarketingBudget);
CREATE TABLE Songs (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
TrackId INT64 NOT NULL,
SongName STRING(MAX),
Duration INT64,
SongGenre STRING(25)
) PRIMARY KEY(SingerId, AlbumId, TrackId),
INTERLEAVE IN PARENT Albums ON DELETE CASCADE;
CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId, SongName DESC), INTERLEAVE IN Albums;
CREATE INDEX SongsBySongName ON Songs(SongName);
CREATE TABLE Concerts (
VenueId INT64 NOT NULL,
SingerId INT64 NOT NULL,
ConcertDate DATE NOT NULL,
BeginTime TIMESTAMP,
EndTime TIMESTAMP,
TicketPrices ARRAY<INT64>
) PRIMARY KEY(VenueId, SingerId, ConcertDate);
É possível usar as seguintes instruções da linguagem de manipulação de dados (DML) para adicionar dados a estas tabelas:
INSERT INTO Singers (SingerId, FirstName, LastName, BirthDate)
VALUES (1, "Marc", "Richards", "1970-09-03"),
(2, "Catalina", "Smith", "1990-08-17"),
(3, "Alice", "Trentor", "1991-10-02"),
(4, "Lea", "Martin", "1991-11-09"),
(5, "David", "Lomond", "1977-01-29");
INSERT INTO Albums (SingerId, AlbumId, AlbumTitle)
VALUES (1, 1, "Total Junk"),
(1, 2, "Go, Go, Go"),
(2, 1, "Green"),
(2, 2, "Forever Hold Your Peace"),
(2, 3, "Terrified"),
(3, 1, "Nothing To Do With Me"),
(4, 1, "Play");
INSERT INTO Songs (SingerId, AlbumId, TrackId, SongName, Duration, SongGenre)
VALUES (2, 1, 1, "Let's Get Back Together", 182, "COUNTRY"),
(2, 1, 2, "Starting Again", 156, "ROCK"),
(2, 1, 3, "I Knew You Were Magic", 294, "BLUES"),
(2, 1, 4, "42", 185, "CLASSICAL"),
(2, 1, 5, "Blue", 238, "BLUES"),
(2, 1, 6, "Nothing Is The Same", 303, "BLUES"),
(2, 1, 7, "The Second Time", 255, "ROCK"),
(2, 3, 1, "Fight Story", 194, "ROCK"),
(3, 1, 1, "Not About The Guitar", 278, "BLUES");
Conseguir planos de execução eficientes é um desafio porque o Spanner divide os dados em divisões. As divisões podem ser movimentadas independentemente entre si e atribuídas a servidores diferentes, que podem estar em diferentes locais físicos. Para avaliar os planos de execução nos dados distribuídos, o Spanner usa a execução com base em:
- execução local de subplanos em servidores que contêm os dados;
- orquestração e agregação de várias execuções remotas com poda agressiva por distribuição.
O Spanner usa o operador primitivo distributed union
, com suas variantes distributed cross apply
e distributed outer apply
, para ativar esse modelo.
Planos de consulta de amostra
Os planos de consulta de amostra do Spanner permitem que você confira amostras de planos de consulta históricos e compare o desempenho de uma consulta ao longo do tempo. Nem todas as consultas têm planos de consulta de amostra disponíveis. Somente as consultas que consomem mais CPU podem ser amostradas. A retenção de dados para amostras de planos de consulta do Spanner é de 30 dias. Confira amostras de planos de consulta na página Insights de consulta no console do Google Cloud. Para mais instruções, acesse Ver planos de consulta de amostra.
A anatomia de um plano de consulta por amostra é a mesma de um plano de execução de consulta normal. Para mais informações sobre como entender os planos visuais e usá-los para depurar consultas, confira Um tour pelo visualizador de planos de consulta.
Casos de uso comuns para planos de consulta com amostra:
Alguns casos de uso comuns para planos de consulta por amostragem incluem:
- Observar as alterações no plano de consulta devido a mudanças no esquema, como adicionar ou remover um índice.
- Observar as alterações no plano de consulta devido a uma atualização da versão do otimizador.
- Observar as alterações no plano de consulta devido às novas estatísticas do otimizador,
que são coletadas a cada três dias automaticamente ou realizadas manualmente usando
o comando
ANALYZE
.
Se o desempenho de uma consulta mostrar uma diferença significativa ao longo do tempo ou se você quiser melhorar o desempenho de uma consulta, consulte Práticas recomendadas de SQL para criar instruções de consulta otimizadas que ajudam o Spanner a encontrar planos de execução eficientes.
Vida útil de uma consulta
Uma consulta SQL no Spanner é primeiro compilada em um plano de execução e, em seguida, é enviada a um servidor raiz inicial para execução. O servidor raiz é escolhido para minimizar o número de saltos para alcançar os dados que estão sendo consultados. Então, o servidor raiz:
- inicia a execução remota de subplanos (se necessário);
- aguarda os resultados das execuções remotas;
- processas as etapas de execução local restantes, como a agregação de resultados;
- retorna os resultados da consulta.
Os servidores remotos que recebem um subplano atuam como servidor "raiz" para o subplano, seguindo o mesmo modelo que o servidor raiz superior. O resultado é uma árvore de execuções remotas. Conceitualmente, a execução da consulta flui de cima para baixo e os resultados da consulta são retornados de baixo para cima. O diagrama a seguir mostra esse padrão:
Os exemplos a seguir ilustram esse padrão com mais detalhes.
Consultas agregadas
Uma consulta agregada implementa consultas GROUP BY
.
Por exemplo, para esta consulta:
SELECT s.SingerId, COUNT(*) AS SongCount
FROM Songs AS s
WHERE s.SingerId < 100
GROUP BY s.SingerId;
Estes são os resultados:
+----------+-----------+
| SingerId | SongCount |
+----------+-----------+
| 3 | 1 |
| 2 | 8 |
+----------+-----------+
Conceitualmente, o plano de execução é o seguinte:
O Spanner envia o plano de execução a um servidor raiz que coordena a execução da consulta e executa a distribuição remota de subplanos.
Esse plano de execução começa com uma união distribuída, que distribui subplanos para servidores remotos com divisões que atendem a SingerId < 100
. Após a conclusão da verificação em divisões individuais, o operador streamaggregate agrega linhas para receber as contagens de cada SingerId
. Em seguida, o operador serialize result
serializa o resultado. Por fim, a união distribuída combina todos os resultados e retorna os resultados da consulta.
Saiba mais sobre agregados em operador agregado.
Consultas de junções colocalizadas
As tabelas intercaladas são armazenadas fisicamente com as respectivas linhas de tabelas relacionadas no mesmo lugar. Uma junção colocalizada é uma junção entre tabelas intercaladas. As junções colocalizadas podem oferecer melhores benefícios de desempenho do que as junções que exigem índices ou junções de volta.
Por exemplo, para esta consulta:
SELECT al.AlbumTitle, so.SongName
FROM Albums AS al, Songs AS so
WHERE al.SingerId = so.SingerId AND al.AlbumId = so.AlbumId;
(Essa consulta pressupõe que Songs
está intercalado em Albums
.)
Estes são os resultados:
+-----------------------+--------------------------+
| AlbumTitle | SongName |
+-----------------------+--------------------------+
| Nothing To Do With Me | Not About The Guitar |
| Green | The Second Time |
| Green | Starting Again |
| Green | Nothing Is The Same |
| Green | Let's Get Back Together |
| Green | I Knew You Were Magic |
| Green | Blue |
| Green | 42 |
| Terrified | Fight Story |
+-----------------------+--------------------------+
Este é o plano de execução:
Esse plano de execução começa com uma união distribuída, que
distribui subplanos para servidores remotos que têm divisões da tabela Albums
.
Como Songs
é uma tabela intercalada de Albums
, cada servidor remoto pode
executar todo o subplano em cada servidor remoto sem exigir uma junção a
um servidor diferente.
Os subplanos contêm uma aplicação cruzada. Cada aplicação cruzada executa uma verificação de tabela na tabela Albums
para recuperar SingerId
, AlbumId
e AlbumTitle
. Em seguida, o cross apply mapeia a saída da verificação da tabela para a saída de uma verificação de índice no índice SongsBySingerAlbumSongNameDesc
, sujeito a um filtro do SingerId
no índice que corresponde ao SingerId
da saída da verificação da tabela. Cada cross apply envia os resultados a um operador serialize result,
que serializa os dados AlbumTitle
e SongName
e retorna
os resultados para as uniões distribuídas locais. A união distribuída agrega os resultados das uniões distribuídas locais e os retorna como resultado da consulta.
Consultas de índice e junção de volta
O exemplo acima usou uma junção em duas tabelas, uma intercalada à outra. Os planos de execução são mais complexos e menos eficientes quando duas tabelas, ou uma tabela e um índice, não são intercalados.
Considere um índice criado com o seguinte comando:
CREATE INDEX SongsBySongName ON Songs(SongName)
Use este índice nesta consulta:
SELECT s.SongName, s.Duration
FROM Songs@{force_index=SongsBySongName} AS s
WHERE STARTS_WITH(s.SongName, "B");
Estes são os resultados:
+----------+----------+
| SongName | Duration |
+----------+----------+
| Blue | 238 |
+----------+----------+
Este é o plano de execução:
O plano de execução resultante é complicado porque o índice SongsBySongName
não contém a coluna Duration
. Para conseguir o valor Duration
, o Spanner precisa fazer a junção de retorno dos resultados indexados à tabela Songs
. Esta é uma junção, mas ela não está colocalizada porque a tabela Songs
e o índice global SongsBySongName
não são intercalados. O plano de execução resultante é mais complexo do que o exemplo de junção colocalizada porque o Spanner executa otimizações para acelerar a execução se os dados não estiverem colocalizados.
O operador superior é uma aplicação cruzada distribuída. O lado de entrada do operador são lotes de linhas do índice SongsBySongName
que satisfazem o predicado STARTS_WITH(s.SongName, "B")
. Em seguida, o "Distribute cross apply" associa esses lotes a servidores remotos cujas divisões contêm os dados Duration
. Os servidores remotos usam uma verificação de tabela para recuperar a coluna Duration
.
A verificação da tabela usa o filtro Condition:($Songs_key_TrackId' =
$batched_Songs_key_TrackId)
, que une TrackId
da tabela Songs
a TrackId
das linhas que foram agrupadas do índice SongsBySongName
.
Os resultados são agregados na resposta final da consulta. Por sua vez, o lado input da aplicação cruzada distribuída contém um par de união distribuída/união distribuída local para avaliar as linhas do índice que satisfazem o predicado STARTS_WITH
.
Considere uma consulta um pouco diferente que não selecione a coluna s.Duration
:
SELECT s.SongName
FROM Songs@{force_index=SongsBySongName} AS s
WHERE STARTS_WITH(s.SongName, "B");
Essa consulta é capaz de aproveitar totalmente o índice, conforme mostrado neste plano de execução:
O plano de execução não requer uma junção de volta porque todas as colunas solicitadas pela consulta estão presentes no índice.
A seguir
Saiba mais sobre operadores de execução de consulta.
Saiba mais sobre o otimizador de consultas do Spanner.
Saiba como gerenciar o otimizador de consultas