Turbopuffer - tecnologia de busca rápida em armazenamento de objetos

• No fim de 2022, ao escalar a infraestrutura da Readwise, queriam adicionar recomendações de artigos e busca semântica usando embeddings vetoriais
• O custo do banco de dados relacional era de US$ 5 mil por mês, mas a busca vetorial custaria mais de US$ 20 mil por mês, então desistiram de implementar a funcionalidade por causa do alto custo
• Os mecanismos de busca existentes são caros e difíceis de operar: com os avanços em armazenamento de objetos, SSD NVMe, IA e tecnologia vetorial, surgiu a necessidade de um novo mecanismo de busca
• Os bancos de dados vetoriais existentes usam armazenamento em memória, o que eleva os custos
  • É possível reduzir bastante os custos usando armazenamento de objetos (S3, GCS) e cache em SSD
  • Exemplo: armazenamento em memória custa mais de US$ 2/GB, enquanto armazenamento de objetos custa US$ 0,02/GB

Arquitetura do turbopuffer

• Desenvolvido como um mecanismo de busca adequado ao presente
• Alcança eficiência de custos e desempenho ao mesmo tempo usando armazenamento de objetos e cache inteligente
• Pode processar dezenas de bilhões de vetores e milhões de tenants
• Mecanismo de busca baseado em armazenamento de objetos
  • Os mecanismos de busca tradicionais usam a arquitetura de disco replicado dos bancos de dados relacionais
  • Mecanismos de busca exigem alta vazão de escrita e toleram latência de escrita mais flexível
  • Mantém o desempenho enquanto reduz custos por meio de armazenamento de objetos e cache em SSD/memória
• Implementação de banco de dados nativo para armazenamento de objetos
  • Construção de um banco de dados com armazenamento de objetos como base
  • Oferece alta confiabilidade e escalabilidade ilimitada
  • Mantém alta disponibilidade por meio de multitenancy e sharding
• Casos de clientes
  • Cursor: editor de código com IA, gerencia dezenas de bilhões de vetores e reduziu os custos em 10 vezes
  • Suno: recurso de rádio
  • Dot: recurso de memória
  • Shapes: recurso de memória

Resumo do GN⁺

• O turbopuffer melhora significativamente a eficiência de custos e o desempenho de mecanismos de busca usando armazenamento de objetos e cache inteligente
• Busca resolver os altos custos e a dificuldade operacional dos mecanismos de busca existentes
• Foi projetado como um novo mecanismo de busca alinhado aos avanços em IA e tecnologia vetorial
• Com casos iniciais de clientes como a Cursor, comprovou redução de custos e melhora de desempenho
• Outros projetos com funcionalidades semelhantes incluem o ElasticSearch e bancos de dados vetoriais

[GN⁺]

Comentários do Hacker News

• Já trabalhei com o Simon, e ele entende muito da área dele

  • Trabalhamos juntos em busca na Shopify e tivemos muitas conversas sobre a stack de busca ideal
  • Quero um sistema ideal que expresse ranking por meio de uma API de busca na nuvem e use matemática de dataframe para dar boost com vários atributos

• Espero que o Turbopuffer funcione como um dataframe do Polars, para que seja possível expressar ranking na API de busca

  • Quero a capacidade de fazer a primeira passada com matemática de dataframe e executar um modelo de reranking

• Também gosto muito do design do site da Fixie.ai

  • A Fixie.ai é um dos clientes da Turbopuffer

• Na Hetzner, o custo de RAM é de $200/TB/mês, 18 vezes mais barato do que em outros lugares

  • Se você reduzir a complexidade, pode atingir o objetivo mais rapidamente

• O pg_vector já existia antes de 2022 e não requer armazenamento em memória

  • É possível fazer busca vetorial em mais de 100 milhões de documentos

• Fico me perguntando se é possível construir uma abordagem usando Lucene com nós de cache em SSD na frente do armazenamento de objetos

  • Já vi implantações de Elasticsearch em grande escala, e seria impressionante se fosse possível colocar tudo no S3

• Parece uma versão de código fechado do Quickwit

  • Link do Quickwit

• Fico me perguntando se existe uma solução genérica para armazenar um grande banco de dados somente leitura no S3 e consultá-lo diretamente

  • O DuckDB consegue abrir e consultar arquivos parquet via http, mas isso dispara muitos pedidos pequenos
  • Quero um único arquivo e um índice que possa ser armazenado em cache para gerenciar milhões de objetos

• A latência de leitura do ClickHouse fica abaixo de 100 ms, e a latência de escrita abaixo de 1 segundo

  • O ClickHouse também é adequado para logging, analytics em tempo real e RAG

• Não conheço bem bancos de dados vetoriais, mas acho que eles são usados principalmente para RAG e outros trabalhos relacionados a IA

  • Preciso explorar isso mais a fundo

• Acho que uma abordagem object-storage-first se encaixa naturalmente na nuvem