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

71–80 of 81 posts

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#71

Post by speedplane »

From the article: "Here, we simulated a multi-tenant e-commerce application where each tenant represented a product category and maintained its own index. For this benchmark, we built 50K indices (or products), which each stored up to 500 documents (or items), for a total of 25 million indices. RediSearch built the indices in just 201 seconds, while running an average of 125K indices/sec. However, Elasticsearch crashed after 921 indices and clearly was not designed to cope with this load."

No sane elasticsearch engineer would make a new index for each product. They would just have a single index with a product_id field for each sub-item. If you needed product level information, you would create a second index for that. You'd use two indexes not O(#Product) indexes.

They just created a botched benchmark by using ES incorrectly. It's like driving a car backwards and then complaining it has poor max speed. ES could easily handle this type of problem if done correctly.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#72

Post by winrid »

anonu wrote: post #59
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…

What would be your go-to solution for a basic word search - lets say you only have a few MBs of data - not GBs...

Few mbs - just use lucene in memory if you're using Java.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#73

Post by misterman0 »

AznHisoka wrote: post #29
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…

This X 2. I feel all these people who feel anything else is a viable alternative to Elasticsearch have a dumb, simple, small-scale use case, where even full-text search over Postgres would suffice.

>> all these people who feel anything else is a viable alternative to Elasticsearch have a dumb, simple, small-scale use case

I have a search use case. I want to create a simple language model where each token in the lexicon gets a unique ID (or ordinal) that I can use to create a more sophisticated model where each document is represented as a vector as wide as there are unique tokens and use clustering and give each cluster a unique ID (or ordinal) so that I can create an even more sophisticated language model, one with built-in semantic understanding. A natural language data structure, if you will, with multiple layers. I want to store the entire WWW in such a model. So I'm building a language model framework that is not build on Lucene because I'm not obliged to use ES in that capacity.

I feel you are wrong to call my use case simple and small scale.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#74

Post by sandGorgon »

atombender wrote: post #58
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 that Elasticsearch is excellent for non-text search. One application I worked on indexes a Postgres database into Elasticsearch for live front-end queries. We index every single field, sometimes hundreds of fields in a single index. ES does this easily. Thanks to Lucene's quasi-columnar/quasi-LSM tree storage, new indexed fields aren't very expensive, and searches -- even fairly complicated ones -- are…

Could you talk about the usecase here ? This is very interesting from a db query tuning perspective. What kind of queries work well in scenarios like this ? I thought search engines are only useful in ranking based searches ...so you accept a degree of error margin wrt databases.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#75

Post by papito »

liveoneggs wrote: post #42
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.

You just say "artificial tests produce artificial results, bye".

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#76

Post by orthecreedence »

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…

> "Show me every match where this field contains 'extinction' within 10 words of 'impact crater' but NOT containing 'oceanic' and the publish date is > last month and one of the subjects is anthropology"

...and then aggregate into time-based buckets, and within each bucket split the results by this field, and then...

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#77

Post by atombender »

sandGorgon wrote: post #74
atombender wrote: post #58

Earlier quoted context omitted.

Not to mention that Elasticsearch is excellent for non-text search. One application I worked on indexes a Postgres database into Elasticsearch for live front-end queries. We index every single field, sometimes hundreds of fields in a single index. ES does this easily. Thanks to Lucene's quasi-columnar/quasi-LSM tree storage, new indexed fields aren't very expensive, and searches -- even fairly complicated ones -- are…

Could you talk about the usecase here ? This is very interesting from a db query tuning perspective. What kind of queries work well in scenarios like this ? I thought search engines are only useful in ranking based searches ...so you accept a degree of error margin wrt databases.

Any non-joining OLTP query will perform very well with ES. It is particularly effective with low-cardinality fields where in a traditional relational database you would not benefit from a B-tree index and a database like Postgres typically would revert to a sequential scan over the entire table. Column intersections in Lucene are extremely efficient, basically streaming sorted vectors of document IDs from RAM.

Where ES is not optimal is when you need joins. That said, doing left outer joins -- which is typical in web workloads where you may have something like an "articles" table that you want to query with filters and then join against "authors" and "categories" without filters to fetch connected data -- on the client side with some basic parallelization is surprisingly effective. Currently doing that in some apps where we get <100 millisecond performance even when fetching maybe 5-6 related objects per result.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#78

Post by sandGorgon »

atombender wrote: post #77
sandGorgon wrote: post #74

Earlier quoted context omitted.

Could you talk about the usecase here ? This is very interesting from a db query tuning perspective. What kind of queries work well in scenarios like this ? I thought search engines are only useful in ranking based searches ...so you accept a degree of error margin wrt databases.

Any non-joining OLTP query will perform very well with ES. It is particularly effective with low-cardinality fields where in a traditional relational database you would not benefit from a B-tree index and a database like Postgres typically would revert to a sequential scan over the entire table. Column intersections in Lucene are extremely efficient, basically streaming sorted vectors of document IDs from RAM. Where…

Do you do left outer join on elasticsearch...or do you do it in the client code ? I'm trying to figure out if elasticsearch supports these query types. It's something I never thought about.

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#79

Post by atombender »

sandGorgon wrote: post #78
atombender wrote: post #77

Earlier quoted context omitted.

Any non-joining OLTP query will perform very well with ES. It is particularly effective with low-cardinality fields where in a traditional relational database you would not benefit from a B-tree index and a database like Postgres typically would revert to a sequential scan over the entire table. Column intersections in Lucene are extremely efficient, basically streaming sorted vectors of document IDs from RAM. Where…

Do you do left outer join on elasticsearch...or do you do it in the client code ? I'm trying to figure out if elasticsearch supports these query types. It's something I never thought about.

In client code. ES doesn't do joins (ignoring a rather weak feature called "nested documents").

Re: Search Benchmarking: RediSearch vs. Elasticsearch

#80

Post by dvirsky »

orthecreedence wrote: post #76
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…

> "Show me every match where this field contains 'extinction' within 10 words of 'impact crater' but NOT containing 'oceanic' and the publish date is > last month and one of the subjects is anthropology" ...and then aggregate into time-based buckets, and within each bucket split the results by this field, and then...

RediSearch can do all of that.
Post reply on HN