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

MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

github.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#41

Post by jniedrauer »

dijit wrote: post #38
heipei wrote: post #20

I know the project doesn't claim it, but the title somewhat implies this: I honestly don't understand people claiming ElasticSearch is hard to operate, especially not at small scales. If anything, ElasticSearch for me has been one of the easiest pieces of infrastructure to operate, for me pretty much "zero-config". Let me elaborate: You can run ElasticSearch via Docker command-line, if you want a cluster you just sup…

Elasticsearch is easier than mongo in some ways and harder in others. I run a few 10TiB ES clusters (which, is not much to be fair) but infrequently find that I have to reindex or reshard the cluster because I can’t just add another node. There’s something to be said for understanding the index rotation too, and access patterns. It’s easy to make an ES cluster, it’s difficult to maintain one, it’s nearly impossible t…

> if you consider that “it’s slow” is what you have to debug.

This is exactly it. This is a problem you encounter with every database engine, but in most of them you can quickly find the bottleneck and fix it. With elasticsearch... it's a frustrating and expensive game of trial and error.

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#42

Post by ksec »

Kerollmops wrote: post #24
heipei wrote: post #20

I know the project doesn't claim it, but the title somewhat implies this: I honestly don't understand people claiming ElasticSearch is hard to operate, especially not at small scales. If anything, ElasticSearch for me has been one of the easiest pieces of infrastructure to operate, for me pretty much "zero-config". Let me elaborate: You can run ElasticSearch via Docker command-line, if you want a cluster you just sup…

MeiliSearch is "zero-config" compared to ElasticSearch in terms of setup to make it work for end-user instant and relevant search engine. Our engine follows the Algolia engine in terms of typo-tolerance, relevancy, and speed. Here is a little comparison to enlighten your questions: https://docs.meilisearch.com/resources/comparison_to_alterna... .

May be adding Vespa [1] to comparison?

[1] https://vespa.ai

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#43

Post by kstrauser »

dijit wrote: post #38
heipei wrote: post #20

I know the project doesn't claim it, but the title somewhat implies this: I honestly don't understand people claiming ElasticSearch is hard to operate, especially not at small scales. If anything, ElasticSearch for me has been one of the easiest pieces of infrastructure to operate, for me pretty much "zero-config". Let me elaborate: You can run ElasticSearch via Docker command-line, if you want a cluster you just sup…

Elasticsearch is easier than mongo in some ways and harder in others. I run a few 10TiB ES clusters (which, is not much to be fair) but infrequently find that I have to reindex or reshard the cluster because I can’t just add another node. There’s something to be said for understanding the index rotation too, and access patterns. It’s easy to make an ES cluster, it’s difficult to maintain one, it’s nearly impossible t…

That's approximately how large our clusters are. Fortunately, ours are read-only, so our admin story is:

- Hey, a node died! - Run Terraform to stand up a whole new cluster and restore it from a snapshot. - Update the app to point at the new cluster. - Run Terraform to delete the old cluster.

I'm pretty happy with this arrangement.

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#44

Post by tpayet »

rockwotj wrote: post #39
tpayet wrote: post #29

Earlier quoted context omitted.

We are working on both replication (for high availability and we may use the Raft consensus) and distribution (sharding to scale horizontally and keeping low latency)

Is there a point of contact for this work? A GitHub issue open? This is an area I'd be interested in.

You might want to talk to kero (https://github.com/Kerollmops/). He is currently working on it !

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#46

Post by [deleted] »

computerex wrote: post #32
turdnagel wrote: post #19

Earlier quoted context omitted.

That would require configuration. This is zero-config.

It'd still be zero-config to provide it's primary function. I don't think anyone would say anything against MeiliSearch or not consider it zero-config had they decided to enable analytics off an env var rather than having analytics be sent by default.

[deleted]

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#47

Post by pqdbr »

I'm impressed.

I have a database with 15k documents, each with around 70 pages of text, HTML formatted.

I'm using ElasticSearch currently, with the Searchkick gem.

30 min playing with MeiliSearch. So far:

- Blazing fast to index, like 10x more performant than using ElasticSearch / Searchkick;

- Blazing fast to search, at least 3x faster in all my random tests so far;

- Literally zero config;

- Uses 140MB of RAM currently, while in my experience ElasticSearch would crash with anything less than 1GB, and needs at least 1.5GB to be usable in production.

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#48

Post by otterley »

tpayet wrote: post #28
otterley wrote: post #27

MeiliSearch appears to be more of an alternative to Lucene than it is to Elasticsearch. Lucene is the search engine that runs on a single instance; ES is the horizontally-scalable distribution and aggregation layer atop the instances. Absent a similar aggregation layer, MeiliSearch isn't "elastic" as the comparison implies.

Actually Lucene is the library for search that Elastic uses under the hood. Lucene does not provide any HTTP API, which Elastic does. Before using Lucene, you have to build the interface around it. In this way MeiliSearch is comparable to ES, especially for site search and app search working out of the box as standard with its http api. MeiliSearch does not offer distribution yet, but it is something the team is work…

My concern is that by comparing it to Elasticsearch, you implicitly minimize the amount of engineering effort required to go from single-node to a distributed system. It is a non-trivial exercise that you will undoubtedly realize once you get into the dirty details.

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#49

Post by rubyn00bie »

pqdbr wrote: post #47

I'm impressed. I have a database with 15k documents, each with around 70 pages of text, HTML formatted. I'm using ElasticSearch currently, with the Searchkick gem. 30 min playing with MeiliSearch. So far: - Blazing fast to index, like 10x more performant than using ElasticSearch / Searchkick; - Blazing fast to search, at least 3x faster in all my random tests so far; - Literally zero config; - Uses 140MB of RAM curre…

But... what happens if I need more than one instance? I'm genuinely curious. I hope this doesn't come off as an asshole comment. Isn't the whole point of ES versus just plain ol' lucene or solr the horizontal scalability of it?

Re: MeiliSearch: Zero-config alternative to Elasticsearch, made in Rust

#50

Post by pqdbr »

pqdbr wrote: post #47

I'm impressed. I have a database with 15k documents, each with around 70 pages of text, HTML formatted. I'm using ElasticSearch currently, with the Searchkick gem. 30 min playing with MeiliSearch. So far: - Blazing fast to index, like 10x more performant than using ElasticSearch / Searchkick; - Blazing fast to search, at least 3x faster in all my random tests so far; - Literally zero config; - Uses 140MB of RAM curre…

Since this got upvoted and I see the devs are replying to questions, here are some! I'm also going to point how ElasticSearch works for comparison.

- The docs state that `Only a single filter is supported in a query`. This is kind of a dealbreaker for my use case, since I need at least a `user_id` and a `status` filter. ElasticSearch can work with multiple filters. Also, don't understand why you call it `filters` instead of `filter` then. Are multiple filters in the roadmap?

- My search UI has a sort by ``, where you can choose, for instance, `last updated asc` or `last updated desc`, amongst others. In my understanding, that would be cumbersome with MeiliSearch, since it would require (1) a settings change to alter the ranking rules order beforehand [0], which would not even work in production due to race conditions or (2) maintain multiple indexes each with a pre-defined ranking rule order and switch between them depending on the UI criteria?

- As an extension of the last question, I see that a lot of what you call "search settings" are considered by ElasticSearch query parameters. For instance, I can easily query ES for the title or description fields just by setting that as a parameter. In MeiliSearch that would require a change in the index settings beforehand, right?

PS: The docs, specially in the Ruby SDK, could use some work in the filters section. It took me a while to understand I should pass a string, like index.search("query", filters: "user_id:3"). I was trying a hash like `filters: { user_id: 3 }`.

[0] https://docs.meilisearch.com/references/ranking_rules.html#u...

Post reply on HN