EDIT: I did read the article, though I overlooked the link to comparison with Elasticsearch.
EDIT: I did read the article, though I overlooked the link to comparison with Elasticsearch.
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.
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.
I'd like to see actual independent feature and performance comparisons before I come to any actual conclusions.
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.
What an interesting way to look at performance.
It seems Redis is moving a bit in the same direction - although not as complex as ES has done it.
Being able to run this inside a Redis instance is a big win, although I suspect few/none of the cloudproviders are willing to pay RedisLabs for the privelige of using the module.
Depending on what you're planning on using it for, make sure to review the documentation, and check the GitHub issues/discussions. For example, I've had to use workarounds to handle some lacking auth/permissions support, but they're currently working on improving it.
Best part by far is the performance. And memory requirements is completely reasonable, depending on the size of the database.