Identificar ponto final de pesquisa vetorial não utilizado
Esta página descreve como usar a tabela log de auditoria do sistema para encontrar pontos de extremidade de pesquisa vetorial que possuem índices, mas não recebem tráfego de consultas. Pontos de extremidade não utilizados consomem recursos e geram custos sem agregar valor. Identificar endpoints não utilizados ajuda a limpar recursos ociosos e reduzir custos.
Requisitos
- Um workspace compatível com o Catálogo Unity.
- Acesso à tabela
system.access.audit. Por default, somente os administradores account têm acesso. Para conceder acesso a outros usuários, consulte a referência da tabela de log de auditoria do sistema. - Um SQL warehouse ou compute serverless para execução de consultas.
Como funciona
A tabela system.access.audit logs cada chamada API de pesquisa vetorial como um evento com service_name = 'vectorSearch'. Isso inclui criação de índices, exclusão, consultas, upserts e varreduras.
Um único endpoint pode servir vários índices. Para encontrar pontos de extremidade não utilizados, compare o conjunto de índices existentes (criados, mas não excluídos) com o conjunto de índices que receberam tráfego de consulta em um determinado período e, em seguida, agregue os resultados ao nível endpoint . Um endpoint só é considerado não utilizado quando nenhum de seus índices recebeu consultas.
O log de auditoria retém dados dos últimos 365 dias, permitindo consultar dados de até um ano atrás.
O log de auditoria registra as consultas no nível do índice, não no nível do endpoint. As consultas neste guia mapeiam os índices de volta para seu ponto de extremidade usando o endpoint_name registrado no momento da criação do índice.
Encontrar endpoint não utilizado
A consulta a seguir identifica o ponto de extremidade onde nenhum índice recebeu consultas nos últimos 30 dias. Ele utiliza eventos de log de auditoria para determinar quais índices foram criados, quais foram excluídos e quais receberam tráfego de consulta, agregando os dados ao nível do endpoint.
Esta consulta determina os índices ativos comparando os eventos createVectorIndex e deleteVectorIndex no log de auditoria. Se um índice foi criado há mais de 365 dias (antes do período de retenção do log de auditoria), ele não aparece nos resultados. Para uma visão completa, compare esses resultados com a saída do método SDK de pesquisa vetorial list_indexes .
WITH created_indexes AS (
-- All indexes created in the last year
SELECT DISTINCT
request_params['name'] AS index_name,
request_params['endpoint_name'] AS endpoint_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),
deleted_indexes AS (
-- Indexes that have been deleted
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'deleteVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),
active_indexes AS (
-- Indexes that exist (created but not deleted)
SELECT ci.index_name, ci.endpoint_name
FROM created_indexes ci
LEFT JOIN deleted_indexes di ON ci.index_name = di.index_name
WHERE di.index_name IS NULL
),
queried_indexes AS (
-- Indexes that received queries in the last 30 days
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'scanVectorIndex'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
),
index_status AS (
SELECT
ai.endpoint_name,
ai.index_name,
CASE WHEN qi.index_name IS NOT NULL THEN 1 ELSE 0 END AS is_queried
FROM active_indexes ai
LEFT JOIN queried_indexes qi ON ai.index_name = qi.index_name
)
SELECT
endpoint_name,
COUNT(*) AS total_indexes,
SUM(is_queried) AS queried_indexes,
COUNT(*) - SUM(is_queried) AS unqueried_indexes
FROM index_status
GROUP BY endpoint_name
HAVING SUM(is_queried) = 0 -- Only fully unused endpoints
ORDER BY total_indexes DESC
Encontre índices não utilizados no endpoint ativo.
Mesmo que um endpoint esteja atendendo ativamente consultas para alguns índices, ele pode ter outros índices que não recebem tráfego. Esses índices não utilizados ainda consomem recursos no endpoint. Remover índices não utilizados de um endpoint ativo pode reduzir seu consumo de memória e evitar que ele seja escalado desnecessariamente.
A consulta a seguir identifica índices individuais não utilizados, incluindo aqueles em endpoints que possuem outros índices ativos.
WITH created_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name,
request_params['endpoint_name'] AS endpoint_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),
deleted_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'deleteVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),
active_indexes AS (
SELECT ci.index_name, ci.endpoint_name
FROM created_indexes ci
LEFT JOIN deleted_indexes di ON ci.index_name = di.index_name
WHERE di.index_name IS NULL
),
queried_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'scanVectorIndex'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
)
SELECT
ai.endpoint_name,
ai.index_name
FROM active_indexes ai
LEFT JOIN queried_indexes qi ON ai.index_name = qi.index_name
WHERE qi.index_name IS NULL
ORDER BY ai.endpoint_name, ai.index_name
Obtenha detalhes da atividade de consulta por índice.
Para entender os padrões de consulta em todos os seus índices, e não apenas nos não utilizados, use a seguinte consulta. Esta consulta encontra a última hora de consulta e o volume de consultas para cada índice, ajudando a identificar índices que são consultados, mas que apresentam um tráfego muito baixo e que também podem ser candidatos à limpeza.
SELECT
request_params['name'] AS index_name,
MAX(event_time) AS last_query_time,
DATEDIFF(current_date(), DATE(MAX(event_time))) AS days_since_last_query,
COUNT(*) AS query_count_30d,
COUNT(DISTINCT DATE(event_time)) AS active_days_30d
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'scanVectorIndex'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
GROUP BY 1
ORDER BY last_query_time ASC
Identificar quem criou o endpoint não utilizado
Para descobrir quem criou os endpoints que estão servindo índices não utilizados, use a seguinte consulta. Isso pode te ajudar a entrar em contato com a equipe certa para a limpeza.
SELECT
request_params['name'] AS endpoint_name,
user_identity.email AS created_by,
event_time AS created_at
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createEndpoint'
AND event_date >= current_date() - INTERVAL 365 DAYS
ORDER BY event_time DESC
Personalize a janela de retrospectiva
Os exemplos acima utilizam um período de 30 dias para definir "não utilizado". Ajuste o valor de INTERVAL de acordo com o seu caso de uso:
- 30 dias : Bom default para a maioria das cargas de trabalho.
- 7 dias : Use para cargas de trabalho que devem ser consultadas diariamente.
- 90 dias : Utilize para lotes ou cargas de trabalho sazonais que sejam executadas com menos frequência.
Substitua INTERVAL 30 DAYS na CTE queried_indexes pela janela desejada.
Próximos passos
- Programe essas consultas como uma tarefa recorrente usando LakeFlow Jobs para obter relatórios regulares.
- Consulte o guia de gerenciamento de custos de busca vetorial para obter estratégias adicionais de otimização de custos.
- Estabelecer políticas orçamentárias para monitorar os custos de busca de vetores. Consulte as políticas de orçamento de pesquisa vetorial.