Live data from Hacker News

Meilisearch 1.0 – Open-source search engine built in Rust

blog.meilisearch.com

51–60 of 186 posts

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

#51
post #44

Earlier quoted context omitted.

Unfortunately, the comparison with Meilisearch is not up to date in this link. Also, we have to keep in mind that every comparison written by a company is always oriented.

I maintain that comparison page on the Typesense side. I just updated it as recently as yesterday, based on my observation. But let me know which ones need updating for Meilisearch. Happy to update. While we’re on the topic, reminder about some of the outdated information in your comparison pages: https://twitter.com/typesense/status/1620825236055932928?s=4...

I'd say that the bit where typesense can only work with data that fits in ram is actually a pretty big problem for a lot of use cases, as an aside. That feature alone would discount typesense for basically all of my personal projects. Might be a trade off I'd be willing to make on a professional project given the other features but it seems really wasteful.

Personally I find the meilisearch comparison to be more useful for the type of stuff I'm doing: https://docs.meilisearch.com/learn/what_is_meilisearch/compa...

Of course I'm not a large enterprise e-commerce site. I'm doing personal projects like web archiving, (dataset probably won't be anywhere near fitting in ram) or I'm using search engines on embedded devices (search needs to play well with others, not use all my ram).

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

#52
post #50

Earlier quoted context omitted.

Question is: do you realize that Rust's `unsafe` is still not as unsafe as C without bound checks, double `free`-s, and others? Point is, it's still an improvement. I am regularly amazed as to why that factually correct and (more and more) time-proven argument is always skipped when criticizing Rust.

Yes, but do you realize you don't have to write C code without bounds checks? You can add your own.

No, I never would have imagined. /s

Point is, many don't do it. And they don't tell anyone. And they deploy important software. And then we get unpleasantly surprised years (or decades) later.

Same argument as with C++: proponents say that the modern C++ is almost like Rust which is cool and I am happy for them, but there are literal hundreds of millions of C++ coding lines out there that will never get upgraded. Having a cop-out like "yeah but the modern version is better" doesn't help legacy code.

Rust on the other hand is super strict for a long time now. They did the right thing.

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

#53

My team tried to use Meilisearch for large datasets, unfortunately, it's impossible to plan the RAM usage. If you have very little searches, it consumed very little, but if you have a lot of search traffic, it may consume more than we could provision beforehand. This made it too unpredictable and too expensive, so we went with Manticore instead. I don't know if this has been addressed in 1.0, hopefully it has.

[deleted]

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

#54
post #7

We’ve been using a Meilisearch for the last six months or so and have been delighted with its performance and usability. It uses a fraction of the resources as Elasticsearch, and the language support is extensive and very active. That being said, our cluster is much smaller than other ones I’ve worked with in the past, so I can’t comment on its reliability at massive scale. I’ve also been very impressed with how acti…

This is the thing I find when people post "ElasticSearch Alternative". 80% of ElasticSearch's value add (wrt search anyway) is all the clustering and frame work that allows you to span the search over tens or hundreds of machines "easily". I think the same is true here. Probably the comparison should be with the underlying search libraries that ES sits on. I suppose this comparison makes sense in a world where most p…

> 80% of ElasticSearch's value add (wrt search anyway) is all the clustering

Or configurability. I looked at this again now that 1.0 is out, but besides the .NET client still being in an alpha state, it’s also very zero-configuration. There seems to be no configurability regarding tokenization strategies, for example.

Now, I certainly see the appeal, I barely understand my own ES code and meilisearch replicates probably 70% of it with no configuration at all, that’s impressive, but it also means that switching would mean giving up on those 30%.

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

#55
post #44

Earlier quoted context omitted.

Unfortunately, the comparison with Meilisearch is not up to date in this link. Also, we have to keep in mind that every comparison written by a company is always oriented.

I maintain that comparison page on the Typesense side. I just updated it as recently as yesterday, based on my observation. But let me know which ones need updating for Meilisearch. Happy to update. While we’re on the topic, reminder about some of the outdated information in your comparison pages: https://twitter.com/typesense/status/1620825236055932928?s=4...

We sent mails but we got no updates on them.

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

#57
post #11

How does Meilisearch compare to ElasticSearch from an operational point of view? I've experienced ElasticSearch to be quite painful to maintain, requiring lots of manual tweaking to balance shards and careful design of indices.

I've been using Meilisearch in production for quite some time now, and TBH it has been one of the easiest service to maintain (I mean, it's just a single statically linked binary) and with close to zero configuration.

Is it really "just a single statically linked binary"?

I'd love to use Meilisearch as you describe, but their so-called SDKs are just for clients, so you still need the Meilisearch server listening on localhost.

I would love to see something like SQLite based on Meilisearch (i.e. a fully self-contained search library like https://github.com/mchaput/whoosh). Do you know if such a thing exists?

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

#58

Congrats to the team, it's been interesting to watch the development of Meilisearch (and it's close competitor Typesense). Algolia has really paved the way here but it's nice to see the open-source options with more configurations and better default UX. There's also many search libraries if you want to embed search more deeply into your app. I have a list of modern search systems and libraries here: https://manigandh…

I will never understand who the target group of Algolia is besides a website where the number of records coincidentally is in the range of the number of queries. At least they got rid of the pricing per indexing transaction which made it even more absurd.

If Algolia would offer an instance based pricing on cpu, ram and storage they would be the clear winner imho.

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

#60

Earlier quoted context omitted.

I've been using Meilisearch in production for quite some time now, and TBH it has been one of the easiest service to maintain (I mean, it's just a single statically linked binary) and with close to zero configuration.

Is it really "just a single statically linked binary"? I'd love to use Meilisearch as you describe, but their so-called SDKs are just for clients, so you still need the Meilisearch server listening on localhost. I would love to see something like SQLite based on Meilisearch (i.e. a fully self-contained search library like https://github.com/mchaput/whoosh ). Do you know if such a thing exists?

I was referring to the server daemon, not the client libraries.

But ofc, it's a process not an embeddable library, so you can't just link it against your app like you would with SQLite or rocksdb.

Although it looks like it's build around their core library "milli" though (https://github.com/meilisearch/milli/), so probably something doable in the future?

Post reply on HN