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

41–50 of 81 posts

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#41

Post by alkz »

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 wouldn't call that "arcana", that's just ES and lucene basics

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#42

Post by liveoneggs »

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…

this is how comparison benchmarks are done when you need to reach certain results. I've even had it done to me at my job!

When you point out the flawed methodology you come across like a luddite or sour grapes or whatever else.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#43

Post by praseodym »

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.

This is exactly why Elasticsearch has a soft limit of 1000 shards per node since version 7.0: https://www.elastic.co/guide/en/elasticsearch/reference/7.0/...

This benchmark used 4605 shards (5 per index) on a single node, which is way above the recommended number.

Also, to prevent oversharding, the default number of shards per index has been changed to 1 in 7.0.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#44

Post by simpsond »

"Elasticsearch crashed after 921 indices" ... Shards: "20 for the multi-tenant benchmark".. 921 * 20 = 18420. Shards have state; they have overhead. Why wouldn't they pick one shard for that benchmark? It's either intentional misconfiguration, or poor understanding of sharding.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#46

Post by panarky »

I love plain old Redis, but I'm not thrilled with the extension modules from Redis Labs.

I experimented with RediSearch using 20 GB of Reddit posts and I was very underwhelmed.

First, 20 GB of raw data explodes into 75 GB once it's in RediSearch with zero fault tolerance. While I'd expect some expansion with inverted indexes and word frequencies by document, a 3.75 multiple seems high.

And since this is Redis, it's all in RAM, including indexes and raw documents, all uncompressed. That's not cheap. Add replicas for fault tolerance and the RAM needed for a decent sized cluster could be 10x the size of the raw data.

Then the tooling and documentation is very limited. Redis Labs provides a Python client, but it doesn't support basic features like returning the score with each document, even though RediSearch provides this capability if you query it directly.

Finally, I found stability issues with Redis when the RediSearch module is installed. Using the Python client provided by RedisLabs, certain queries would predictably crash every node in the cluster.

Redis itself is rock solid, but Redis with the RediSearch module feels fragile.

Overall, interesting concept but not ready for production use by any means.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#47

Post by _Codemonkeyism »

onlyrealcuzzo wrote: post #36
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.

From the license fiasco to this. RedisLabs tries hard to be the new Microsoft.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#48

Post by groestl »

alkz wrote: post #26
wyldfire wrote: post #16

Earlier quoted context omitted.

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

each ES shard is actually a lucene index, and it uses memory... why would anyone need thousand of indices on a single node?

What's the difference, memory-wise, between a single shard and two shards holding half the data each?

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#49

Post by itronitron »

showerst wrote: post #13
porker wrote: post #12

Earlier quoted context omitted.

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.

I'm not very familiar with Redis but wouldn't it shine at set-based operations like faceting? You could also pre-tokenize the input data to RediSearch with Lucene analyzers.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#50

Post by papito »

onlyrealcuzzo wrote: post #34
papito wrote: post #19

Earlier quoted context omitted.

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.

AFAIK, SQL engines will do a fairly reasonable full-text search, but if you need anything more, you have to upgrade to a full-featured search engine.
Post reply on HN