Is Rust that important that you have to place "built in Rust" in the title? Is this like a cult following that we only bet on traffic and interest coming from other evangelists where Rust is the only feature that matter? 4 months ago: " Meilisearch, open-source alternative to Algolia in Rust lands a $15M Series A" It's not the first time I see, there are at least 2-3 daily submissions reaching the FP in this manner s…
I’ve come to see it this way: If a set of users are using a product only because it is built in X, that user base is most likely the early adopter audience for X and it dangerously masks whether that product has product-market fit or not. So if a product markets itself as built in X, it is appealing to early adopters of X. The long-tail of users on the other hand, care more about what painful problem the product is s…
Meilisearch 1.0 – Open-source search engine built in Rust
141–150 of 186 posts
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#142Congrats! Question for the team as I see a possible discrepancy on the website. The "Comparisons" page says there is no limit for number of indices ( https://docs.meilisearch.com/learn/what_is_meilisearch/compa... ) However, the "Limitations" page says there is a limit of ~180 indices ( https://docs.meilisearch.com/learn/what_is_meilisearch/compa... ) Can you clarify what, if any, are the limitations of # indices?
I would like to know the use case for needing more than 200 indexes. We have handled multi-tenant with a single index and multi-tenant tokens. https://docs.meilisearch.com/learn/security/tenant_tokens.ht...
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#143Congrats! Question for the team as I see a possible discrepancy on the website. The "Comparisons" page says there is no limit for number of indices ( https://docs.meilisearch.com/learn/what_is_meilisearch/compa... ) However, the "Limitations" page says there is a limit of ~180 indices ( https://docs.meilisearch.com/learn/what_is_meilisearch/compa... ) Can you clarify what, if any, are the limitations of # indices?
Thanks! Indeed we now have a limit, but this limit depends on the OS you use. The limit is 200 on Linux. We found a way to remove this limit in the next version of Meilisearch (v1.1), which will be released in approximately two months. I would like to know the use case for needing more than 200 indexes. We have handled multi-tenant with a single index and multi-tenant tokens. https://docs.meilisearch.com/learn/securi…
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#144Great news! Been following along for a while and it's a great project. ElasticSearch needs some competition. For us, there are two things missing for us before we could make the switch: 1. Multi-index search; Standard use-case is searching across e.g. users and companies. Common in many SaaS-applications, where you want a single search field with type-ahead for e.g. contacts/organisations/tasks/events. 2. Decay funct…
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#145Earlier quoted context omitted.
Do you have any numeric definitions for few and lots?
Our index was aimed at handling 20 000 documents at total of 35MB of CSV, this would balloon into 0.7GB to 1GB of RAM and we expected at least 1000 of these indexes, which would require dedicated servers with 1TB of RAM. This was when Meili was at version 0.27. With manticore, we've tried to run into these issues in benchmarks, but the only problem we got was temporary high IO load when indexes need to be re-indexed…
And indeed, Meilisearch uses memory-mapping, which means that everything is on disk, and it will try to take as much memory as possible. For your information, we successfully ran a 115M documents dataset on a 1Gb RAM machine.
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#146Earlier quoted context omitted.
How is the startup time? Would be nice if you could check a query and then start the instance with an appropriate memory configuration.
Pretty much instant, it loads data from a memory-mapped file so having a fast SSD for that is a must.
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#147This looks very cool, nice work. Any plans to support ANN vector searches in the near future?
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#148compared to https://typesense.org/ ?
they are very similar. I've tested both intensively a few months ago, ended up w Typesense for performance reason. My test data set is 1.5M doc * 3-10 fields * 10-50 characters. Meilisearch has slightly better multi-language support, but typesense is much better on batch reindex speed and ram usage while a bit shy on supporting asian languages. The query speed is similar in light to medium load, I didn't stress test…
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#149Very early adopter of meilisearch and it’s pretty great. But bumpy as the team found their footing but overall very impressed with it.
Re: Meilisearch 1.0 – Open-source search engine built in Rust
#150Earlier quoted context omitted.
> Part of why I find the whole typesense comparison page disingenuous is that you're making the ability to swap to disk sound like an anti-feature. Didn’t intend it that way. In fact, we recommend that users configure swap space even in Typesense as a safety mechanism. May I know which part of the comparison table makes it sound like that? The one under Index location says: “Disk with Memory Mapped files” for Meilise…
>May I know which part of the comparison table makes it sound like that? Well a few things. Normally I'd try to coach these a bit kinder and all that, but I hope you don't mind if I just come out and talk about the issues. Keep in mind that these are just my interpretations after a quick read through. # Bias > Instant Search-as-you-type Experiences for up to a few hundred thousand records, that don't require a produc…
> but for me one example of production looks like a raspberry pi in a school house in rural africa (internet in a box project)
This is an interesting perspective, one that I hadn't considered before. You're saying that software can be run in a variety of different environments and that the definition of what a "production" environment looks like is context-dependent.
My definition of "production" in the context of server software is that you typically run this software on a server or set of servers in some datacenter (think Redis, Postgres, MySQL, MongoDB, etc). In this context, I've always defined "production-ready" as:
1. Can it withstand infrastructure failures?
2. Is the API stable?
So when I say Meilisearch is not "production-ready", it's in this specific context - it can only be run on a single node, and it cannot handle infrastructure failures natively. So it could become single point of failure.
> This here is another spot where you seem biased. Remove the "despite v1.x versioning", it comes off as petty.
Historically I've seen server software has fault tolerance built-in when they reach v1.0, and it's a common assumption that I've seen engineers make. So I wanted to call attention to it... The phrasing of it comes across as petty, now that you mention it. I'll remove that.
> I get what you're saying about "production ready" but there must be another way to word it?
I think "fault tolerance" is a better word to describe what I had in mind. I'll update this.
> I don't think either of you support https.
Typesense does support https natively.
> Do you really not recommend the use of a reverse proxy? ... I guess you're assuming it's running on a stand alone computer with a public facing IP... ? Are you not providing a frontend/dashboard?
Yes to all your questions, except that Typesense does support HTTPS natively.
> You've made this sound like a draw back, if you had of put "None. Self-contained binary" in front of it like you did for yourself that would be fine but for this you mention a feature that you have while ignoring what looks to me like the same feature in your competitor.
I was actually going to add "None. Self-contained binary" for Meilisearch. But then their docs explicitly recommend using a reverse proxy in front: https://docs.meilisearch.com/learn/cookbooks/running_product...
With Typesense, we use h2o as the http library, which for eg Fastly exposes directly to internet-bound traffic and it's specifically built for handling high-volume traffic. This is why we feel comfortable recommending not putting a reverse-proxy in front of Typesense.
> Language support... This is also a bit confusing, and I can't help but think it's probably not completely honest. What makes meilisearch different so that it doesn't support "all languages", but elasticsearch does? Meilisearch certainly claims to support all languages where words are seperated by spaces, do you support languages that don't have words separated by spaces?
Yes, we support all languages that are space-separated. We also added support for CJK languages recently (which are not space-separated). I picked the phrasing you see under the Meilisearch column, from their docs: https://docs.meilisearch.com/learn/what_is_meilisearch/langu... (it used to read slightly different previously).
> Meilisearch is multilingual, featuring optimized support for: > Any language that uses whitespace to separate words > Chinese > Japanese > Hebrew > Thai > We aim to provide global language support, and your feedback helps us move closer to that goal.
> This user claims that meilisearch has better multi-language support: https://news.ycombinator.com/item?id=34708802
We didn't support CJK languages in a GA release, until 2 weeks ago. So they are most likely talking about an earlier version of Typesense.