News for hackers. Stuff that matters.
Re:turbopuffer: Fast Search on Object Storage by solatic on Wednesday July 10, 2024 @12:19PM (#40928528)
Is it feasible to try to build this kind of approach (hot SSD cache nodes sitting in front of object storage) with prior open-source art (Lucene)? Or are the search indexes themselves also proprietary in this solution?

Having witnessed some very large Elasticsearch production deployments, being able to throw everything into S3 would be incredible. The applicability here isn't only for vector search.

Re:turbopuffer: Fast Search on Object Storage by rohitnair on Wednesday July 10, 2024 @01:50PM (#40929482)
Elasticsearch and OpenSearch already support S3 backed indices. See features like https://opensearch.org/docs/latest/tuning-your-cluster/avail... The files in S3 are plain old Lucene segment files (just wrapped in OpenSearch snapshots which provide a way to track metadata around those files).
Re:turbopuffer: Fast Search on Object Storage by francoismassot on Wednesday July 10, 2024 @01:56PM (#40929561)
But you don’t have fast search on those files stored on object storage.
Re:turbopuffer: Fast Search on Object Storage by rohitnair on Wednesday July 10, 2024 @02:01PM (#40929618)
Yes, there is a cold start penalty but once the data is cached, it is equivalent to disk backed indices. There is also active work being done to improve the performance, example https://github.com/opensearch-project/OpenSearch/issues/1380...
Re:turbopuffer: Fast Search on Object Storage by francoismassot on Wednesday July 10, 2024 @12:55PM (#40928889)
If you don't need vector search and have very large Elasticsearch deployment, you can have a look at Quickwit, it's a search engine on object storage, it's OSS and works for append-only datasets (like logs, traces, ...)

Repo: https://github.com/quickwit-oss/quickwit