opendistro-build VS bleve

You should consider opening an issue on their github [0]?

AWS, from what I know, takes security seriously, and given they themselves use OpenDistro internally, this should become a top priority for them.

[0] https://github.com/opendistro-for-elasticsearch/opendistro-b...

By fork they mean: a binary build straight from the unmodified elastic source code using the elastic build file that creates the OSS build bundled with a handful of plugins and components to add alternatives some of the things elastic bundles. They don't even build it themselves and it gets downloaded in binary form straight from Elastic's servers.

If you don't believe me, this is the line in the code where they 'fork' in their build script: https://github.com/opendistro-for-elasticsearch/opendistro-b...

It will be interesting to see if opendistro actually starts contributing to Lucene or adding value to the elastic code base or whether this 'fork' is effectively frozen in time and doomed to go nowhere due to a lack of actual development on the core product.

I seriously doubt that they are going to put any effort whatsoever in that. Because in two years of pretending they have a fork, there has been no serious code contributions from their side at all that I'm aware off. Correct me if I'm wrong.

If you want to back an OSS version of related technology, maybe use something like Apache Solr, which continues to provide many of the same features and is part of the same ecosystem of users and developers that work on Lucene, which also powers Elasticsearch and which of course continues to contribute a lot to Lucene; unlike Amazon.

I don't have the answer to that, but the project has been alive for many years. Seems maybe you should find the answer since you are developing a competing solution? Also it might be a good reference project for solving similar problems to yours. They do have bench tests you could play with https://github.com/blevesearch/bleve/blob/master/query_bench_test.go

I know of https://github.com/blevesearch/bleve and I think there was another project for full text search that I can't find now.

I would be interested in such a testbed. I would also like to know how Bleve Search (https://github.com/blevesearch/bleve) turns out.

I have for many years now a small search engine project in my free-time pipeline, but I'm before crawling even and I intend to sit for searching part after some of that.

Haha. Seriously I can’t tell the difference between these libraries https://github.com/blevesearch/bleve

I've never worked on a project that encompasses as many computer science algorithms as a search engine. There are a lot of topics you can lookup in "Information Storage and Retrieval":

- Tries (patricia, radix, etc...)

- Trees (b-trees, b+trees, merkle trees, log-structured merge-tree, etc..)

- Consensus (raft, paxos, etc..)

- Block storage (disk block size optimizations, mmap files, delta storage, etc..)

- Probabilistic filters (hyperloloog, bloom filters, etc...)

- Binary Search (sstables, sorted inverted indexes, roaring bitmaps)

- Ranking (pagerank, tf/idf, bm25, etc...)

- NLP (stemming, POS tagging, subject identification, sentiment analysis etc...)

- HTML (document parsing/lexing)

- Images (exif extraction, removal, resizing / proxying, etc...)

- Queues (SQS, NATS, Apollo, etc...)

- Clustering (k-means, density, hierarchical, gaussian distributions, etc...)

- Rate limiting (leaky bucket, windowed, etc...)

- Compression

- Applied linear algebra

- Text processing (unicode-normalization, slugify, sanitation, lossless and lossy hashing like metaphone and document fingerprinting)

- etc...

I'm sure there is plenty more I've missed. There are lots of generic structures involved like hashes, linked-lists, skip-lists, heaps and priority queues and this is just to get 2000's level basic tech.

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

- https://github.com/valeriansaliou/sonic

- https://github.com/mosuka/phalanx

- https://github.com/meilisearch/MeiliSearch

- https://github.com/blevesearch/bleve

- https://github.com/thomasjungblut/go-sstables

A lot of people new to this space mistakenly think you can just throw elastic search or postgres fulltext search in front of terabytes of records and have something decent. The problem is that search with good rankings often requires custom storage so calculations can be sharded among multiple nodes and you can do layered ranking without passing huge blobs of results between systems.

For those curious, I'm on my 3rd search engine as I keep discovering new methods of compactly and efficiently processing and querying results.

There isn't a one-size-fits all approach, but I've never worked on a project that encompasses as many computer science algorithms as a search engine.

- Tries (patricia, radix, etc...)

- Trees (b-trees, b+trees, merkle trees, log-structured merge-tree, etc..)

- Consensus (raft, paxos, etc..)

- Block storage (disk block size optimizations, mmap files, delta storage, etc..)

- Probabilistic filters (hyperloloog, bloom filters, etc...)

- Binary Search (sstables, sorted inverted indexes)

- Ranking (pagerank, tf/idf, bm25, etc...)

- NLP (stemming, POS tagging, subject identification, etc...)

- HTML (document parsing/lexing)

- Images (exif extraction, removal, resizing / proxying, etc...)

- Queues (SQS, NATS, Apollo, etc...)

- Clustering (k-means, density, hierarchical, gaussian distributions, etc...)

- Rate limiting (leaky bucket, windowed, etc...)

- text processing (unicode-normalization, slugify, sanitation, lossless and lossy hashing like metaphone and document fingerprinting)

- etc...

I'm sure there is plenty more I've missed. There are lots of generic structures involved like hashes, linked-lists, skip-lists, heaps and priority queues and this is just to get 2000's level basic tech.

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

- https://github.com/valeriansaliou/sonic

- https://github.com/mosuka/phalanx

- https://github.com/meilisearch/MeiliSearch

- https://github.com/blevesearch/bleve

A lot of people new to this space mistakenly think you can just throw elastic search or postgres fulltext search in front of terabytes of records and have something decent. That might work for something small like a curated collection of a few hundred sites.

Search in SQL databases is a tough beast to get it right. And given that we support MySQL and Postgres both, it gets even harder to support quirks of both of them.

In enterprise editions, the only addition is Elasticsearch. But in our open-source version, we do have support for https://github.com/blevesearch/bleve. Although, it's in beta, we have a lot of customers using it.

I am wondering if you have tried using it and didn't like it?