Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Search Benchmarking: RediSearch vs. Elasticsearch

redislabs.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#32

Post by yazaddaruvala »

wyldfire wrote: post #16
showerst wrote: post #6

I'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.

Yeah, anyone creating 921 indexes in the same cluster hasn't read the ES docs[0]. Utilizing aliases and possibly routing is a significantly better design.

I think we can all agree that misusing a tool, after appropriate documentation has been published, shouldn't be a considered a fault of the tool.

[0] https://www.elastic.co/guide/en/elasticsearch/guide/current/...

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#33

Post by Scaevolus »

> Dataset source: wikidump Date: Feb 7, 2019 docs: 5.6M size: 5.3 GB

"wikidump" links to https://dumps.wikimedia.org/enwiki/latest/ , which has thousands of files, none of which are 5GB and make sense. That's a very poor corpus link!

It says "Feb 7, 2019", so it probably means https://dumps.wikimedia.org/enwiki/20190120/ or https://dumps.wikimedia.org/enwiki/20190201/ ... maybe. They don't have any obvious 5.3GB files.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#34

Post by onlyrealcuzzo »

papito wrote: post #19
showerst wrote: post #6

I'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.

I was just going to ask: Will SQL work with spelling corrections?

I was under the impression that if you wanted to do auto-complete, you need to handle mis-spellings, and that ElasticSearch is one of the best options for this.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#35

Post by jstarfish »

gt565k wrote: post #24

WOW. Hahahaha. This is a massive misconfiguration of an elastic search cluster. 50k indices? 500 documents per index? 500 records per index at 5shards/index is 100 records per shard. Yeah, let's shard our data so much that we introduce tremendous amounts of disk i/o overhead!!! Author should learn how to properly configure an ES cluster before posting ridiculous benchmarks like this. What an utter pile of garbage ben…

Isn't that exactly what they're trying to demonstrate though? That all this arcana you have to invoke to get a stable ES cluster barely breaks a sweat on Redisearch?

The specific test deployment was multitenant anyway-- you can't account or optimize for what tenants are going to index.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#36

Post by onlyrealcuzzo »

bigodines wrote: post #11

If 2-word queries is all you need, why would you even consider elasticsearch? This benchmark is pure marketing IMHO.

RedisLabs seems to really be abusing Redis's popularity on HN.

I've seen a lot of posts like this easily make it to the front page only because a lot of HN-ers are Redis fanboys (rightfully so: Redis is great). But then you read the post and it _appears_ to be marketing garbage.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#38

Post by softwaredoug »

jchw wrote: post #31

>Component: Search Engine >RediSearch: Dedicated engine based on modern and optimized data-structures >ElasticSearch: 20 years old Lucene engine The implications made here make me actually angry.

Lucene: over 20 years has been battle tested, optimized, and improved to the point where it’s running search almost everywhere

RedisSearch: new shiny thing built on top of Redis that is used in a couple of niche places.

I’ll take Lucene please

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#39

Post by gt565k »

jstarfish wrote: post #35
gt565k wrote: post #24

WOW. Hahahaha. This is a massive misconfiguration of an elastic search cluster. 50k indices? 500 documents per index? 500 records per index at 5shards/index is 100 records per shard. Yeah, let's shard our data so much that we introduce tremendous amounts of disk i/o overhead!!! Author should learn how to properly configure an ES cluster before posting ridiculous benchmarks like this. What an utter pile of garbage ben…

Isn't that exactly what they're trying to demonstrate though? That all this arcana you have to invoke to get a stable ES cluster barely breaks a sweat on Redisearch? The specific test deployment was multitenant anyway-- you can't account or optimize for what tenants are going to index.

I'm not familiar with RediSearch, but I'm just trying to point out that you can't misconfigure ES and then benchmark against a misconfigured cluster. This is comparing apples to oranges. Not to mention I'm not sure of the feature difference between the 2 search engines, but I'd bet ES is much more feature rich, thus its use cases are vastly different. If you are just comparing text search, sure, maybe redis is faster. But at that point, so is a simple sql database, when compared to a misconfigured ES cluster.
Post reply on HN