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

Meilisearch 1.0 – Open-source search engine built in Rust

blog.meilisearch.com

Post reply on HN
Print view View original

151–160 of 186 posts

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#151

Post by qdequelen »

drifteaur wrote: post #108
cies wrote: post #67

I think multi-lingual stemming is the point where I see this as a real ES competitor. Still they've come a long way, and burning too much RAM on ES is not the way fwd either.

I've had a great experience with Meilisearch, it was very easy to set up. But I'm not sure what's behind the claim that "it supports all languages", aside from handling unicode? Does it support stemming at all? Does it have customized stop words per language?

To answer your question precisely, we handle all the space-separated languages and have specific tokenizers for Chinese, Japanese, Korean, Thai, and Hebrew. We plan to add more languages in the future.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#154

Post by networked »

The most specific criticism I have read of Meilisearch is https://news.ycombinator.com/item?id=32940683. It has four points: (1) words beyond 65535 are silently ignored (this is documented in https://docs.meilisearch.com/learn/advanced/known_limitation... ); (2) the position of a matching word in a document non-optionally affects ranking; (3) to get the match information you must retrieve the entire attribute; (4) the meaning of PUT and POST is switched relative to RFC 7231.

Are points (2) through (4) true? Has any of the points been an issue for you in practice?

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#155

Post by UltimateEdge »

rockwotj wrote: post #39
curquiza wrote: post #16

Earlier quoted context omitted.

Hello! For me, "built in Rust" can be a real marketing argument. Indeed, Rust is a language that has proved its safety in the past. Building a technical product in Rust guarantees stability and safety (no memory issues in general) and performance (no garbage collector issue), so it brings more trust to the users.

FWIW milli does use unsafe in places. Also I would recommend not conflating no GC and performance. There are lots of reasons for Rust being fast and many have nothing to do with no GC. The main reasons a lot of languages with GC are slower is due to allocating on the heap as opposed to the stack, and in general Rust does a lot of static linking and the compiler has the full amount of information to optimize calls wit…

> Actually there are times when GC is more efficient than than automatically freeing memory because GC can batch cleanup work.

Where can I read about these details of software performance? Can you recommend a book?

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#156

Post by earthling8118 »

hu3 wrote: post #74
adamnemecek wrote: post #69

Earlier quoted context omitted.

Anything. Legit no language comes even close in terms of how easy it is to git clone something and get it to build.

I'd argue Go projects tend to be easier to build since they require nightly Go builds much less frequently (I don't even remember a project that ever required nightly Go tbh). https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I've had the absolute opposite luck with go. There's a lot of good things made in it but I prefer to not be involved in them. A nightly toolchail for rust is trivial to acquire to the point of it taking only a few seconds

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#157

Post by manigandham »

naiv wrote: post #106
manigandham wrote: post #66

Earlier quoted context omitted.

Why do the number of records and searches have to be similar? The current pricing is simple - you pay per "search unit" which scales in both dimensions. The vast majority of small/medium customers would rather pay-as-you-go than maintain a fixed cost instance, and it allows Algolia to efficiently pack them into a multitenant architecture instead of wasting resource overhead.

If you eg index geonames, you have 4 mio. records but you might only have 50.000 queries a month. you pay $4,000 for minimal compute resources, 4GB of RAM and 3 gigabytes of storage space. Would be less but algolia requires you to create a replica for each sort option separately. With 4 mio. records and 4 mio. queries I would pay the same. But then at least have 4 mio. queries. The other way around, if we would just…

Your usage seems to be in the "large" customer category where provisioned capacity is a better deal. Algolia does have volume discounts if you talk to them, but yes the other alternatives might be a better fit.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#158

Post by nickreese »

rsstack wrote: post #114
sandstrom wrote: post #111

Earlier quoted context omitted.

You could have a look at https://github.com/lucaong/minisearch/

Wow, this might fit our needs much better! Thanks!

Can vouch for minisearch. Amazing for relative small data that fits in memory.

The typeahead is great.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#159

Post by qdequelen »

muhammadusman wrote: post #153

how does this compare to Typesense? I'd like to see which one uses fewer resources for similar performance

Hey muhammadusman, I'm the Meilisearch's CEO. We have a complete comparison table. Note that it represents our point of view. https://docs.meilisearch.com/learn/what_is_meilisearch/compa...

Both Meilisearch and Typesense are really different regarding resource consumption and performance. I would say that where Typesense would have a better indexing performance (Meilisearch has recently improved indexation speed), Meilisearch will guarantee a much faster search performance while keeping impressive relevancy. Regarding the consumption, as Typesense is entirely on RAM and Meilisearch is using memory mapping, Meilisearch would take more disk space but less RAM.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#160

Post by Kerollmops »

networked wrote: post #154

The most specific criticism I have read of Meilisearch is https://news.ycombinator.com/item?id=32940683 . It has four points: (1) words beyond 65535 are silently ignored (this is documented in https://docs.meilisearch.com/learn/advanced/known_limitation... ); (2) the position of a matching word in a document non-optionally affects ranking; (3) to get the match information you must retrieve the entire attribute; (4) t…

What’s funny is that (1) doesn’t look like a real limit when you know that the first Harry Potter book is nearly 77000 words. The recommended way is to split your documents by paragraph to increase relevancy, this way you can see the exact part that match.

About (2) we will work on exposing two new ranking rules to be able to control that.

For (3) I thought it was fixed.

We decided to implement (4) the PUT and POST this way after looking how others were doing that.

Post reply on HN