pisa
lucene
pisa | lucene | |
---|---|---|
1 | 11 | |
859 | 2,370 | |
1.5% | 2.2% | |
8.0 | 9.8 | |
15 days ago | about 15 hours ago | |
C++ | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pisa
-
A Compressed Indexable Bitset
The EF core algorithm implemented in folly [3] may be a bit faster, and implementing partitioning on top of that is relatively easy.
It would definitely compress much better than roaring bitmaps. In terms of performance, it depends on the access patterns. If very sparse (large jumps) PEF would likely be faster, if dense (visit a large fraction of the bitmap) it'd be slower.
It is possible to squeeze a bit more compression out of PEF by introducing a chunk type for Elias-Fano of the chunk complement (for very dense chunks), but you lose the operation of skipping to a given position, which is however not needed in inverted indexes (you only need to skip past a given id, and that can be supported efficiently). That is not mentioned in the paper because at the time I thought the skip-to-position operation was a non-negotiable.
[1] https://github.com/ot/ds2i/
[2] https://github.com/pisa-engine/pisa
[3] https://github.com/facebook/folly/blob/main/folly/experiment...
lucene
-
Building an efficient sparse keyword index in Python
First, a review of the landscape. As said in the introduction, there aren't a ton of good options. Apache Lucene is by far the best traditional search index from a speed, performance and functionality standpoint. It's the base for Elasticsearch/OpenSearch and many other projects. But it requires Java.
-
Java Panama Vector API Integrated with Apache Lucene
https://github.com/apache/lucene/issues/10047
2. The Panama Vector API allows CPU's that support it to accelerate vector operations: https://openjdk.org/jeps/438
So this allows fast ANN on Lucene for semantic search!
How did people do this before Lucene supported it? Only through entirely different tools?
-
What Is a Vector Database
Are they forking Lucene or somehow getting the Lucene devs to increase that limit? Because this PR has been open for over a year now: https://github.com/apache/lucene/issues/11507
- An alternative to Elasticsearch that runs on a few MBs of RAM
- Lucene 9.4 (optionally) uses Panama's mapped MemorySegments when JDK 19 is detected
-
A primer on Roaring bitmaps: what they are and how they work
Lucene's adaptation of Roaring uses the complement idea on a block-wise basis:
https://github.com/apache/lucene/blob/84cae4f27cfd3feb3bb42d...
-
How are documents stored in Elasticsearch?
Like someone said, it's in locations as specified in the path.data. Depending on sharing and replication, it could be on more than one host. Elastic uses Apache Lucene to store documents, since it's open source, that rabbit hole will welcome research :-)
- panama/foreign status update
-
Amazon Elasticsearch Service Is Now Amazon OpenSearch Service
It is pretty clear to me that Elastic is planning to build their ANN features differently than OpenDistro's k-NN implementation, or other plugins modules that extend Easticsearch in similar ways. They now will build on the Apache Lucene capabilities that were collaboratively built "upstream" by a number of individuals, some that work for Amazon and some that work for Elastic.
From the linked issue, it seemed that they were originally planning to develop this as a proprietary feature of Elasticsearch, without contributing the functionality to Apache Lucene, but then changed direction when the Apache Lucene developers (some of which are currently employed to do such work by Amazon) started to build its approximate nearest neighbor (ANN) vector search capabilities. [1]
It's great to see folks that work for Elastic collaborating and building on what is in Apache Lucene to extend the utility of ANN with Hierarchical Navigable Small World Graphs (HNSW) [2]! From this, I think it should be possible to implement an Open Source version of the functionality with a compatible API, if that is something that OpenSearch users seek.
[1] https://issues.apache.org/jira/browse/LUCENE-9004
[2] https://github.com/apache/lucene/pull/250
What are some alternatives?
Apache Solr - Apache Lucene and Solr open-source search software
Typesense - Open Source alternative to Algolia + Pinecone and an Easier-to-Use alternative to ElasticSearch ⚡ 🔍 ✨ Fast, typo tolerant, in-memory fuzzy Search Engine for building delightful search experiences
resin - Vector space search engine. Available as a HTTP service or as an embedded library.
RoaringBitmap - A better compressed bitset in Java: used by Apache Spark, Netflix Atlas, Apache Pinot, Tablesaw, and many others
efg - GPU based Compressed Graph Traversal
OpenSearch - 🔎 Open source distributed and RESTful search engine.
MeTA - A Modern C++ Data Sciences Toolkit
alexandria - Full text search engine powering Alexandria.org - the open search engine.
liqe - Lightweight and performant Lucene-like parser, serializer and search engine.