Turbopuffer - tecnología de búsqueda rápida en almacenamiento de objetos

• A finales de 2022, mientras ampliaban la infraestructura de Readwise, querían agregar recomendaciones de artículos y búsqueda semántica usando embeddings vectoriales
• El costo de la base de datos relacional era de $5k al mes, pero la búsqueda vectorial costaba más de $20k mensuales, así que descartaron implementar la función por su alto costo
• Los motores de búsqueda existentes son caros y difíciles de operar: con los avances en almacenamiento de objetos, SSD NVMe, IA y tecnología vectorial, se necesitaba un nuevo motor de búsqueda
• Las bases de datos vectoriales existentes usan almacenamiento en memoria, por lo que su costo es alto
  • Se puede reducir mucho el costo aprovechando almacenamiento de objetos (S3, GCS) y caché en SSD
  • Ejemplo: el almacenamiento en memoria cuesta más de $2/GB, mientras que el almacenamiento de objetos cuesta $0.02/GB

Diseño de turbopuffer

• Desarrollaron un motor de búsqueda adaptado al presente
• Logra tanto eficiencia de costos como rendimiento usando almacenamiento de objetos y caché inteligente
• Puede manejar decenas de miles de millones de vectores y millones de tenants
• Motor de búsqueda basado en almacenamiento de objetos
  • Los motores de búsqueda tradicionales usan una arquitectura de discos replicados tomada de las bases de datos relacionales
  • Los motores de búsqueda requieren alto rendimiento de escritura y toleran una latencia de escritura más flexible
  • Mantiene el rendimiento mientras reduce costos mediante almacenamiento de objetos y caché en SSD/memoria
• Implementación de base de datos nativa para almacenamiento de objetos
  • Construyeron una base de datos con almacenamiento de objetos como base
  • Ofrece alta confiabilidad y escalabilidad ilimitada
  • Mantiene alta disponibilidad mediante multi-tenancy y sharding
• Casos de clientes
  • Cursor: editor de código con IA, administra decenas de miles de millones de vectores y redujo costos 10 veces
  • Suno: función de radio
  • Dot: función de memoria
  • Shapes: función de memoria

Resumen de GN⁺

• turbopuffer mejora de forma importante la eficiencia de costos y el rendimiento de los motores de búsqueda usando almacenamiento de objetos y caché inteligente
• Busca resolver el alto costo y la dificultad operativa de los motores de búsqueda existentes
• Diseñó un nuevo motor de búsqueda acorde con los avances en IA y tecnología vectorial
• Demuestra reducción de costos y mejora de rendimiento con casos iniciales de clientes como Cursor
• Otros proyectos con funciones similares incluyen ElasticSearch y las Vector DBs

[GN⁺]

Opiniones de Hacker News

• He trabajado con Simon y domina muy bien su área

  • Trabajamos juntos en temas de búsqueda en Shopify y tuvimos muchas conversaciones sobre el stack de búsqueda ideal
  • Quiere un sistema ideal que exprese el ranking mediante una API de búsqueda en la nube y que use matemáticas de dataframes para potenciar distintos atributos

• Le gustaría que Turbopuffer funcionara como un dataframe de Polars para poder expresar el ranking en la API de búsqueda

  • Quiere la capacidad de hacer una primera pasada con matemáticas de dataframes y luego ejecutar un modelo de re-ranking

• También le gusta mucho el diseño del sitio web de Fixie.ai

  • Fixie.ai es uno de los clientes de Turbopuffer

• En Hetzner, el costo de RAM es de $200/TB/mes, 18 veces más barato que en otros lugares

  • Si se reduce la complejidad, se puede alcanzar el objetivo más rápido

• pg_vector ya existía desde antes de 2022 y no requiere almacenamiento en memoria

  • Puede realizar búsquedas vectoriales sobre más de 100 millones de documentos

• Se pregunta si es posible construir un enfoque usando Lucene con nodos de caché SSD delante del object storage

  • Ha visto despliegues a gran escala de Elasticsearch, y sería increíble si todo pudiera ponerse en S3

• Suena como una versión de código cerrado de Quickwit

  • Enlace de Quickwit

• Se pregunta si existe una solución general para almacenar grandes bases de datos de solo lectura en S3 y consultarlas directamente

  • DuckDB puede abrir y consultar archivos parquet por http, pero dispara muchas solicitudes pequeñas
  • Quiere un solo archivo y un índice cacheable para gestionar millones de objetos

• La latencia de lectura de ClickHouse es inferior a 100 ms y la latencia de escritura es inferior a 1 segundo

  • ClickHouse también es adecuado para logging, analítica en tiempo real y RAG

• No sabe mucho sobre bases de datos vectoriales, pero cree que se usan principalmente para RAG y otras tareas relacionadas con IA

  • Necesita explorarlo más a fondo

• Cree que un enfoque centrado primero en object storage encaja de forma natural con la nube