I mean speed is nice, but it is not the primary thing I am concerned with in a search engine, as long as it is acceptable it is not in the list of requirements - things that would be on my list - not necessarily in this order but close

1. What human languages does it support.

2. In these human languages how does stemming and decompounding work in your implementation.

3. how is word importance determined in your index - TF-IDF? other algorithm? Are least important words automatically dropped from queries?

4. Do you have ability to rank on both the stemmed/decompounded query/results and exact matches? So something like raw field access.

5. Can I create my own semantics - I remember seeing a post on here recently where someone had created a search engine (in Rust I think) that was faster than ElasticSearch but from what I could see you couldn't create your own field names so you were stuck searching in title, description, body, creationDate and a couple other fields which really decreases the usefulness.

I mean these are the things that right away spring to mind to ask about when someone tells me they have a new search engine, and when they show me look at my speed benchmarks I'm thinking "what am I supposed to do with this?"

on edit: formatting

on second edit: So I guess as in most things I am interested in how the product actually fulfills what should be its primary functionality, so how does the search engine function as a search engine, I suppose my questions could be answered with quick - our search engine has feature parity with ElasticSearch / Solr where features A, B, and C are concerned - features D and E will be supported in the future.

The question in general is "Yes, RediSearch supports all of these features". You can read about it all in the docs https://redisearch.io

I also pointed bellow to the specific relevant area in the docs.

> 1. What human languages does it support. > 2. In these human languages how does stemming and decompounding work in your implementation.

https://oss.redislabs.com/redisearch/Stemming/

> 3. how is word importance determined in your index - TF-IDF? other algorithm? Are least important words automatically dropped from queries? >4. Do you have ability to rank on both the stemmed/decompounded query/results and exact matches? So something like raw field access.

https://oss.redislabs.com/redisearch/Overview/

Thanks, I guess I was more taken with answering on the link to benchmarks on the sub-thread which seemed not what I would consider pertinent. That said everything looks pretty nice.

You mean (SHOCK!) that the company that sells Redis thinks their product is better than a competitor!? Color me shocked!

I'd like to see actual independent feature and performance comparisons before I come to any actual conclusions.

That link is really well hidden in the article IMO. I read your comment and re-read the article and still had to ctrl+F to find it. (It's the 4th link under "blog posts")

Elastic search adds a huge overhead over Lucene. I suspect the same is true for RediSearch. The test is not testing the engine, but rather the implementation of its distributed aspect.

But RediSearch is not based on Lucene (as claimed here https://redislabs.com/blog/search-benchmarking-redisearch-vs... )

Of course. What I mean is that the performance of distributed FTS is mostly related to its distributed aspect, not FTS by itself.

If I were @aphyr, I would say that performance and correctness are competing, so a more performant distributed system is less correct, unless proved otherwise.

CAP theorem is a little bit more nuanced than "more performance is less correct", but I see what you're saying.

> I would say that performance and correctness are competing

What an interesting way to look at performance.

@murkt That's how I look at the performance benchmarks of distributed systems.

Color me skeptical anytime a company benchmarks their product against the competition.

I missed the link lol