Live data from Hacker News

Bleve: Full-text search and indexing for Go

blevesearch.com

41–50 of 65 posts

Re: Bleve: Full-text search and indexing for Go

#41

To the maintainers: what are the top 3-5 (or so) requested features, and do you plan to implement them? Any thoughts on how Bleve compares with Xapian or Trinity (C++ libraries for full-text indexing)? https://xapian.org/ https://github.com/phaistos-networks/Trinity

First, here are the top two requests that we do NOT plan to implement.

1. Make Bleve a distributed index, or make Bleve into something that is a more direct ES competitor.

We have no plans to do this because we think that is better built at a different layer. We have hooks we introduce in certain places where we need to plug-in code that would otherwise violate the boundaries. And that is an arrangement that has worked well so far. There are multiple projects built on top of bleve that allow you to index/search across nodes.

2. Make an adapter for the XYZ key/value store.

This request goes back to the original bleve index which is serialized into a key/value abstraction layer. When users run into size/speed issues with bleve, many assume that just plugging in a faster key/value store will help. (Hey we thought that too when we built it this way)

But, we've now replaced that index scheme with a new implementation called scorch. Scorch is considerably smaller and faster, and manages it's own index on disk, without using any key/value store.

As for things that we DO plan to implement:

1. Size of the index still comes up a lot. Couchbase is a very performnace sensitive user of Bleve, so I expect they'll lead the way on this front.

2. Better (pluggable) scoring. Today our search result scoring is broken for several types of queries, and the stuff that does score right is too tightly coupled to the searching logic.

3. Overhaul index mapping. Today bleve uses a mapping object to describe how source objects/documents are indexed. One of the best ways we can simplify the mapping is to make things more explicit. I think we tried to embrace the concept of reasonable defaults, but we ended up with inheritance hierarchies that are difficult to reason about.

There are lots of miscellaneous things like adding a data type that supports IPv6, or more advanced queries (lots of variations on span queries).

Re: Bleve: Full-text search and indexing for Go

#42
post #14

To get a feel for the size of Bleve, checkout this graph that shows commit rates doing into Bleve versus Elasticsearch and Vespa: http://blog.minimum.se/assets/elasticsearch-open-source-comm... If you don't need heavy lifting, then "sonic" implemented in rust is a really nice lean alternative too: https://github.com/valeriansaliou/sonic FWIW, that graph is from a blog post I published earlier today: http://blog.minim…

Great blog post! First one I've seen with good comparisons to the other options. I would recommend adding Xapiand too: https://github.com/Kronuz/Xapiand

Thanks (you can upvote it here if you want: https://news.ycombinator.com/item?id=19605334 )

I've added a mention of Xapian/Xapiand as well now and generated new graphs that include data for those two projects.

Re: Bleve: Full-text search and indexing for Go

#46
post #8

I actually used this recently in a small personal project, it's pretty good. It's not like Elastic or Solr, more like Lucene - which may very well be good enough for your use case. The index structures are stored in BoltDB (which stores in a flat file.) There are some issues, though. For example I think it's currently not possible to use the built-in query language to search Boolean values. So you might run into some…

Our biggest pain point using bleve is umlaut handling (our documents are in German).

Other than that, I was pleasantly surprised by how well it fit into our static doc server that we shipped a binary around of.

Re: Bleve: Full-text search and indexing for Go

#47
post #8

I actually used this recently in a small personal project, it's pretty good. It's not like Elastic or Solr, more like Lucene - which may very well be good enough for your use case. The index structures are stored in BoltDB (which stores in a flat file.) There are some issues, though. For example I think it's currently not possible to use the built-in query language to search Boolean values. So you might run into some…

Our biggest pain point using bleve is umlaut handling (our documents are in German). Other than that, I was pleasantly surprised by how well it fit into our static doc server that we shipped a binary around of.

We recently added an ASCII folding filter, which may help: https://github.com/blevesearch/bleve/pull/1070

Re: Bleve: Full-text search and indexing for Go

#48
post #30
post #23

Earlier quoted context omitted.

Dgraph (a graph database) also use Bleve for its full-text search indexing.

(author of Dgraph) We use specific libraries from Bleve to do, for e.g., full-text tokenization and such. But, we use our own indexing and storage mechanism, not Bleve's.

Thank you for your work!!

Re: Bleve: Full-text search and indexing for Go

#49
Really nice to see the Go ecosystem developing. The other day I was searching for a link/URL extraction library and the best one I could find was in Go: https://github.com/mvdan/xurls ("best" because it actually uses a list of TLDs, for example: https://github.com/mvdan/xurls/blob/master/tlds.go). Was an unusual experience not finding something as good for Java.

Re: Bleve: Full-text search and indexing for Go

#50
I'm looking at adding better search to our app soon, and I honestly don't really have knowledge of any systems out there. Answer to this basic question might help both me and others:

How would you deploy Bleve in a 12-factor app environment?

(Does Bleve directly support any persistence? Does it support distributed workloads? Could a "trained" model get passed to read-only nodes?)

Post reply on HN