From an information retrieval perspective, this is embarrassing, and the benchmarks aren’t close to being apples and oranges—it’s more like apples and Mack trucks. The linked benchmark is for a toy data set of 5.6GB, which we all know Redis will store in RAM; yet they don’t say whether they set “index.storage.type: memory” on ElasticSearch (guessing they didn’t).<p>At the same time, ElasticSearch/Lucene puts considerable effort into analysis at both indexing time and querying time that goes into ranking the search results. RediSearch’s ranking is “user provided”—how does that work exactly? What does that even mean? Ranking is at the heart of information retrieval—of what value is it to allow for 4x more queries to be run on a cluster when the result sets are terrible?<p>ElasticSearch could be better at scaling up on nodes to handle more query operations on a given cluster. However, if you care about full text search, this won’t do the job.
I’m trying to imagine why I would not use existing, mature search tech (Solr/Elastic) with existing mindshare I can hire.<p>Why would I pay to be off on an island very locked into a proprietary search tech? Even if it is a little faster with the redis brand attached to it? It doesn’t seem quite turnkey as Algolia or as deeply featured like Lucidworks Fusion...<p>Maybe I just don’t get the pitch yet...
I think it's not terrible - redis itself is just brilant !
But wow a search-redis ? I think they have a lotttt of ground to make up to compete in the search space. The amount of options/analysis/tokenization/other-search features you get out the box from anything Lucene based (solr,elastic) is just staggering.
Nice work, it’s pretty awesome to be able to plug a search engine as easily as adding a plugin. I just have one question about the recently published benchmarks, are the latency based on the two-word search "hello world"?
I was under the impression that Redis was intended for short-lived data, but a full text search suggests otherwise. Are people using Redis, with persisted storage, as their database?
I haven't followed Redis Modules so far, what's the best way to start the road towards prod usage if otherwise I rely on the AWS ElastiCache version?
I wish Redis would focus a bit more on the standard clustering options. Cluster has some real drawbacks and Sentinel is about the most brittle service I’ve seen. We run all of our peer discovery for Squawk[1] on Redis but recently made the switch to KeyDB and have been thrilled with the resiliency. We’re definitely not Redis experts so I’m sure we’re doing some things wrong, but for anyone else looking for a rock solid HA solution, I highly recommend it.<p>[1] Squawk - Walkie Talkie for Teams <a href="https://www.squawk.to" rel="nofollow">https://www.squawk.to</a>
> Cluster Support and Commercial Version: RediSearch has a distributed cluster version that can scale to billions of documents and hundreds of servers. However, it is only available as part of Redis Labs Enterprise.<p>This is a bummer because high availability is really important for many search uses cases. For e.g. think about e-commerce where search literally prints money.<p>EDIT: it seems like the open source version supports a read-only replica for failover but my overall thoughts about not crippling/compromising the clustering story in open source version still stands.<p>While I understand the rationale for this move, unfortunately not having HA in a non-starter.<p>I had a similar temptation when open-sourcing Typesense (<a href="https://github.com/typesense/typesense" rel="nofollow">https://github.com/typesense/typesense</a>) and thought long and hard about keeping clustering as part of a closed source commercial edition but eventually decided against it. I understand that commercialising certain features is a necessarily evil and trade-offs must be made. However, I think there are still many avenues to do that without keeping clustering closed source.<p>Apart from that, I am happy to see the search space heating up with a lot more interesting options.<p>Disclosure: I have stakes in the open source search eco-system (<a href="https://github.com/typesense/typesense" rel="nofollow">https://github.com/typesense/typesense</a>) but a genuine Redis fan.
Good for them on building a business around redis.<p>That said, fuck paying for some bolt-on approximation of a search engine with no real durability. I'll use elastic or solr.<p>They're free, and have massive communities and user-bases. Issues are surfaced quickly. Compatibility is a priority. And all the other benefits of network effects.
I am a bit dated but I dont have a high confidence of redis with persistent storage such as a typical ACID database. How does this fit into an architecture?<p>It seems painful to have to write code to reload the search db if it fails.<p>How long is redis search going to exist and be supported?<p>If this is delivered as a module, what guarantees do I have that the module interface wont break and leave redis search in a broken state?