Dimensionando o Lakebase Search: lições de um aplicativo real e 4 milhões de passagens
Traduzido do original em inglês por IA. Ver em inglês
Dimensionar o Local File Cache para corresponder ao índice vetorial mantém até 98% das páginas na memória e reduz a latência de busca vetorial quente para poucos milissegundos diretamente no Lakebase Postgres. Reduzir o pool de candidatos de busca para 200 corta as leituras de páginas em dois terços, preservando 90,5% dos principais resultados, com um piso de 0,5 CU sempre ativo que fornece uma linha de base de produção ideal por apenas US$ 31 a US$ 40 por mês.
* O Lakebase Search executa busca vetorial e por palavras-chave BM25 como extensões do Postgres dentro do banco de dados da aplicação, para que os desenvolvedores obtenham busca híbrida sem manter um sistema de busca separado ou um segundo caminho de transação. * Os benchmarks mostram que dimensionar o Local File Cache para corresponder aproximadamente ao índice vetorial mantém 95~98% das páginas na memória, reduzindo a latência da busca vetorial quente para um dígito de milissegundos, enquanto a redução do pool de candidatos de 1.000 para 200 preserva 90,5% dos 10 principais resultados com um terço das leituras de página. * O Lakebase Postgres cobra computação apenas enquanto está em execução, e um teste de carga de 14 minutos servindo 109 mil solicitações usou apenas US$ 0,02 de computação do Lakebase Postgres, tornando um piso de 0,5 CU sempre ativo de US$ 31~40/mês a linha de base de produção recomendada para evitar cold starts.