4 ms·

Typesense follows a memory model similar to Redis - you need sufficient RAM to hold the entire dataset. I don't want to speak for the Meilisearch team, but fro

by jabo 4y ago

Typesense follows a memory model similar to Redis - you need sufficient RAM to hold the entire dataset. I don't want to speak for the Meilisearch team, but from observing user reports like this [1], it seems to me like you'd need at least X-2X RAM to run Meilisearch, if X is the size of your dataset, if you want it to not slow down as it swaps content from Disk to RAM. [1] https://news.ycombinator.com/item?id=34708658 https://news.ycombinator.com/item?id=34708658

traverseda 4y ago
I mean that user report is from me, and was about a very very early meilisearch version. Maybe wrong link? > if you want it to not slow down as it swaps content from Disk to RAM. Obviously it's going to be fastest to run with your entire dataset in RAM, that's never in doubt. 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. The whole things just sounds biased in a way that the meilisearch comparison doesn't. There are some killer features in typesense for sure, just my first impression of it is that it's very much aimed at someone other than me. >Typesense follows a memory model similar to Redis The difference is that redis is primarily being used as a cache, or for IPC, or as a task-queue. You're not loading a whole bunch of data into, and you expect that the data you have in it will either be short-lived (IPC, queue) or can be evicted with no issues (caching).
- jabo 4y ago
  > 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 Meilisearch, which I updated based on the Meilisearch team’s feedback… Edit: To your first point, I meant to link to the parent comment: https://news.ycombinator.com/item?id=34708352 https://news.ycombinator.com/item?id=34708352 I’ve also seen similar RAM recommendations from the Meilisearch team on GitHub to other users reporting similar performance issues.
  - traverseda 4y ago
    >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 production-grade highly-available setup. Seeing as meilisearch is your biggest competitor saying that they're not "production grade" sounds biased. "Production grade" is subjective, and I understand why it's written that way you define production grade to include high-availability multi-node configurations. I don't necessarily disagree but I think you need to drop "production grade" from that sentence and just say "high availability". Maybe add a row to your overview talking about high availability since it seems to be one of the factors you consider to be a significant differentiator. >Only supports a single-node setup, which creates a potential single point of failure and so is not production-ready, despite the v1.x versioning. This here is another spot where you seem biased. Remove the "despite v1.x versioning", it comes off as petty. I'd also remove the part where you say "is not production ready". You seem to have a very concrete idea of what production looks like, but for me one example of production looks like a raspberry pi in a school house in rural africa (internet in a box project). Under those constraints typesense isn't production ready. I get what you're saying about "production ready" but there must be another way to word it? The whole "production ready" line of reasoning comes off as arrogant and petty in general. >Runtime Dependencies [...] Recommends use of nginx, apache or the like as a reverse proxy in front Meilisearch is also a single self-contained binary with an embedded http server. I don't think either of you support https. Do you really not recommend the use of a reverse proxy? How do you route subdomains? I guess you're assuming it's running on a stand alone computer with a public facing IP and no SSL? Are you not providing a frontend/dashboard? 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. >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? This implication for this line seems to be that meilisearch isn't indexing on unicode, or something. Just weird, needs more detail probably. This user claims that meilisearch has better multi-language support: https://news.ycombinator.com/item?id=34708802 https://news.ycombinator.com/item?id=34708802 So what's the difference? >Number of Documents This is completely fine! Good job linking to the pertinent issue and everything. This is how you mention significant drawbacks without seeming biased or petty. # Target use case This also seems to be pretty firmly aimed at large enterprise clients. If that's not the impression you're going for, well change the memory model but there's some language in this comparison that can probably help. > CDN-like Geo-Distributed clusters Just sounds buzz-wordy to me. Might be fine if I didn't get the impression for the previous paragraphs that my use cases weren't "production ready (webscale?)" and that I'm using it wrong if it's not on a server with 24 TB of ram. This is more about who the intended customer is than about bias though, so I don't think it's really an issue. Your intended customer isn't some bloke running wordpress on a VPS, it's large scale enterprise and that's fine. If you want to soften that there's a few more things you'll need to change, but when combined with the above stuff about "production ready" it leaves a bit of a bad taste in my mouth, like you'd really rather I be paying you exorbitant rates to run this in your cloud than just using it.

by jabo 4y ago

traverseda 4y ago

I mean that user report is from me, and was about a very very early meilisearch version. Maybe wrong link? > if you want it to not slow down as it swaps content from Disk to RAM. Obviously it's going to be fastest to run with your entire dataset in RAM, that's never in doubt. 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. The whole things just sounds biased in a way that the meilisearch comparison doesn't. There are some killer features in typesense for sure, just my first impression of it is that it's very much aimed at someone other than me. >Typesense follows a memory model similar to Redis The difference is that redis is primarily being used as a cache, or for IPC, or as a task-queue. You're not loading a whole bunch of data into, and you expect that the data you have in it will either be short-lived (IPC, queue) or can be evicted with no issues (caching).

jabo 4y ago
> 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 Meilisearch, which I updated based on the Meilisearch team’s feedback… Edit: To your first point, I meant to link to the parent comment: https://news.ycombinator.com/item?id=34708352 https://news.ycombinator.com/item?id=34708352 I’ve also seen similar RAM recommendations from the Meilisearch team on GitHub to other users reporting similar performance issues.
- traverseda 4y ago
  >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 production-grade highly-available setup. Seeing as meilisearch is your biggest competitor saying that they're not "production grade" sounds biased. "Production grade" is subjective, and I understand why it's written that way you define production grade to include high-availability multi-node configurations. I don't necessarily disagree but I think you need to drop "production grade" from that sentence and just say "high availability". Maybe add a row to your overview talking about high availability since it seems to be one of the factors you consider to be a significant differentiator. >Only supports a single-node setup, which creates a potential single point of failure and so is not production-ready, despite the v1.x versioning. This here is another spot where you seem biased. Remove the "despite v1.x versioning", it comes off as petty. I'd also remove the part where you say "is not production ready". You seem to have a very concrete idea of what production looks like, but for me one example of production looks like a raspberry pi in a school house in rural africa (internet in a box project). Under those constraints typesense isn't production ready. I get what you're saying about "production ready" but there must be another way to word it? The whole "production ready" line of reasoning comes off as arrogant and petty in general. >Runtime Dependencies [...] Recommends use of nginx, apache or the like as a reverse proxy in front Meilisearch is also a single self-contained binary with an embedded http server. I don't think either of you support https. Do you really not recommend the use of a reverse proxy? How do you route subdomains? I guess you're assuming it's running on a stand alone computer with a public facing IP and no SSL? Are you not providing a frontend/dashboard? 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. >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? This implication for this line seems to be that meilisearch isn't indexing on unicode, or something. Just weird, needs more detail probably. This user claims that meilisearch has better multi-language support: https://news.ycombinator.com/item?id=34708802 https://news.ycombinator.com/item?id=34708802 So what's the difference? >Number of Documents This is completely fine! Good job linking to the pertinent issue and everything. This is how you mention significant drawbacks without seeming biased or petty. # Target use case This also seems to be pretty firmly aimed at large enterprise clients. If that's not the impression you're going for, well change the memory model but there's some language in this comparison that can probably help. > CDN-like Geo-Distributed clusters Just sounds buzz-wordy to me. Might be fine if I didn't get the impression for the previous paragraphs that my use cases weren't "production ready (webscale?)" and that I'm using it wrong if it's not on a server with 24 TB of ram. This is more about who the intended customer is than about bias though, so I don't think it's really an issue. Your intended customer isn't some bloke running wordpress on a VPS, it's large scale enterprise and that's fine. If you want to soften that there's a few more things you'll need to change, but when combined with the above stuff about "production ready" it leaves a bit of a bad taste in my mouth, like you'd really rather I be paying you exorbitant rates to run this in your cloud than just using it.