If 2-word queries is all you need, why would you even consider elasticsearch? This benchmark is pure marketing IMHO.
Search Benchmarking: RediSearch vs. Elasticsearch
11–20 of 81 posts
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#12I've seen a lot of ES competitor posts pop up on HN lately, and I think they're missing the point of Elastic. If you only need very basic word search, ES is probably not worth the complexity in your stack, especially if you're already running a SQL database with decent plaintext search. Where elasticsearch shines is in complex queries: "Show me every match where this field contains 'extinction' within 10 words of 'im…
This. The best benchmarking for search engines is:
1. Does it return relevant results?
2. Can it handle complex queries?
1) is the main measure users care about, and in my experience is best evaluated by building a search in each system with the same corpus and giving to subject-matter experts.
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#13I've seen a lot of ES competitor posts pop up on HN lately, and I think they're missing the point of Elastic. If you only need very basic word search, ES is probably not worth the complexity in your stack, especially if you're already running a SQL database with decent plaintext search. Where elasticsearch shines is in complex queries: "Show me every match where this field contains 'extinction' within 10 words of 'im…
This. The best benchmarking for search engines is: 1. Does it return relevant results? 2. Can it handle complex queries? 2) is only required in specific use-cases, but when it's needed it's _really needed_. 1) is the main measure users care about, and in my experience is best evaluated by building a search in each system with the same corpus and giving to subject-matter experts.
Definitely. In my mind the very first questions you should ask when evaluating search are "Do i need faceted search?" "Do I need boolean logic? proximity? stemming?". Because the answers to those questions will cut the field way down.
That's why some of these benchmarks (redis and the go search engine posted last week) seem a little apples/oranges to me.
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#14I fail to see how the creation of 50K indices on elasticsearch is a meaningful benchmark, that's just not how it's supposed to be used.
Also as others said, testing a distributed system on a single node makes little sense... as it is a benchmark which is not reproducible as we don't know how the data was queried and indexed
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#15Is the RediSearch's aggregation comparable with ES's? Speed has lower priority when there are missing features.
PS: Crashes are never good though...
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#16I've seen a lot of ES competitor posts pop up on HN lately, and I think they're missing the point of Elastic. If you only need very basic word search, ES is probably not worth the complexity in your stack, especially if you're already running a SQL database with decent plaintext search. Where elasticsearch shines is in complex queries: "Show me every match where this field contains 'extinction' within 10 words of 'im…
> Where elasticsearch shines is in complex queries ...
If the "Multi-tenant indexing benchmark" is accurate it seems like it might be a robustness concern for ES. "Elasticsearch crashed after 921 indices and just couldn’t cope with this load." -- does that mean memory exhaustion or some other crash? If it's the latter, it seems like a quality problem more than a performance one.
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#17Someone needs to edit this article. There are misspellings and typos all over the place.
It's Friday, the task was to deliver the aritcle by the weekend :)
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#18I've seen a lot of ES competitor posts pop up on HN lately, and I think they're missing the point of Elastic. If you only need very basic word search, ES is probably not worth the complexity in your stack, especially if you're already running a SQL database with decent plaintext search. Where elasticsearch shines is in complex queries: "Show me every match where this field contains 'extinction' within 10 words of 'im…
> Where elasticsearch shines is in complex queries ... If the "Multi-tenant indexing benchmark" is accurate it seems like it might be a robustness concern for ES. "Elasticsearch crashed after 921 indices and just couldn’t cope with this load." -- does that mean memory exhaustion or some other crash? If it's the latter, it seems like a quality problem more than a performance one.
In a production setting, I wouldn't recommend doing ElasticSearch multi-tenancy in this manner. Indexes aren't free.
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#19I've seen a lot of ES competitor posts pop up on HN lately, and I think they're missing the point of Elastic. If you only need very basic word search, ES is probably not worth the complexity in your stack, especially if you're already running a SQL database with decent plaintext search. Where elasticsearch shines is in complex queries: "Show me every match where this field contains 'extinction' within 10 words of 'im…
Not to mention spelling correction, synonyms, nested taxonomies, etc. Search is incredibly complex, and I always snort when I see someone trying to create one from scratch.
Re: Search Benchmarking: RediSearch vs. Elasticsearch
#20In order for me to trust a benchmark, it needs to be a lot more transparent than this
- Show the code that runs the bench mark
- Give opportunities for everyone to recreate the benchmark
- Give opportunities for every technology to 'respond' and point out where the benchmark/tech configuration is wrong (ie "PRs welcome")
Otherwise, this just looks like cherry-picked data points, and even those I won't trust. Nor would I show this to any of my clients (whom I help select search engine technology). I dearly hope nobody makes real decisions based on this blog post until the code, and everything is opened up.