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

11–20 of 116 posts

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

#11

Post by Bedon292 »

While this might be an alternative for that one specific use case (search bar), it does not feel like a viable alternative to ES. I am sure it is great at that specific case, and don't want to knock them on that. But, I have never used ES for a simple search like they are. when I use ES, I want to store billions of records redundantly and search them by text, time, and/or location. And then create visualizations with the results.

When I first read the title I thought it might be a Rust based Lucene engine or something, and thought that would be pretty cool. Though no idea how that would work. On its own, this is a pretty nifty little tool, however I think the framing as an ES alternative is what feels wrong to me, and apparently others in the comments as well.

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

#12

Post by seemslegit »

greendave wrote: post #10
seemslegit wrote: post #7

Hardly an "alternative to Elastic search" if only because the later is scalable beyond a single machine. This overhyped description coupled with on-by-default analytics suggests to me MeiliSearch should be dismissed regardless of potential usefulness or technical merit.

The analytics seem pretty benign. "We send events to our Amplitude instance to be aware of the number of people who use MeiliSearch. We only send the platform on which the server runs once by day. No other information is sent. If you do not want us to send events, you can disable these analytics by using the MEILI_NO_ANALYTICS env variable."

The practice itself is malignant, either explicitly ask upon first run or require a MEILI_YES_ANALYTICS env variable to enable it.

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

#13

Post by nicoburns »

Bedon292 wrote: post #11

While this might be an alternative for that one specific use case (search bar), it does not feel like a viable alternative to ES. I am sure it is great at that specific case, and don't want to knock them on that. But, I have never used ES for a simple search like they are. when I use ES, I want to store billions of records redundantly and search them by text, time, and/or location. And then create visualizations with…

https://github.com/tantivy-search/tantivy is a Rust based Lucene-alike.

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

#14

Post by ellimilial »

Bedon292 wrote: post #11

While this might be an alternative for that one specific use case (search bar), it does not feel like a viable alternative to ES. I am sure it is great at that specific case, and don't want to knock them on that. But, I have never used ES for a simple search like they are. when I use ES, I want to store billions of records redundantly and search them by text, time, and/or location. And then create visualizations with…

Seconding. Text searching is a horribly hairy problem. I know 2 businesses for which the main source of income is tuning ES/Solr to particular user needs. Starting from performance, through templating case-specific queries to custom plugins.

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

#15

Post by throw03172019 »

We use Algolia and use the public API keys with search filters encoded so they can only search their data (I.e. account_id:123)

Is there anything similar here? Otherwise all the queries need to go through our servers first to ensure the filter is present.

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

#16

Post by Kerollmops »

throw03172019 wrote: post #15

We use Algolia and use the public API keys with search filters encoded so they can only search their data (I.e. account_id:123) Is there anything similar here? Otherwise all the queries need to go through our servers first to ensure the filter is present.

The current API key system is a simple and temporary solution.

We will work on a more feature-full API key system including the one you are talking about. This is on our roadmap IIRC.

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

#18

Post by ghh »

I wanted to mention Sonic [1] as another lightweight document indexing alternative written in rust, when I found MeiliSearch to provide a thoughtful comparison page [2]

[1] https://github.com/valeriansaliou/sonic

[2] https://docs.meilisearch.com/resources/comparison_to_alterna...

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

#19

Post by turdnagel »

seemslegit wrote: post #12
greendave wrote: post #10

Earlier quoted context omitted.

The analytics seem pretty benign. "We send events to our Amplitude instance to be aware of the number of people who use MeiliSearch. We only send the platform on which the server runs once by day. No other information is sent. If you do not want us to send events, you can disable these analytics by using the MEILI_NO_ANALYTICS env variable."

The practice itself is malignant, either explicitly ask upon first run or require a MEILI_YES_ANALYTICS env variable to enable it.

That would require configuration. This is zero-config.

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

#20

Post by heipei »

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 supply IPs of the other nodes. Then you start indexing documents with simple HTTP calls. You can add or remove nodes at any time and don't have to do anything but to start another ElasticSearch instance. If you run out of space or performance just start another node. Everything needed for management, indexing, search is available through HTTP APIs, no tools needed.

Clustered ElasticSearch has been rock-solid for me and I've used it in anger many times. The level of maintenance needed is close to zero, both initially and long-term. Compare that with the abysmal experience of setting up a sharded MongoDB cluster for example...

Please enlighten me how ElasticSearch is "a lot of work to operate" (heard that one multiple times), and what you're comparing it to.

Post reply on HN